From nobody Sat Jan 2 13:32:55 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194021A6F97 for ; Sat, 2 Jan 2016 13:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 gAN5hPgEcxvy for ; Sat, 2 Jan 2016 13:32:52 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 019E01A6F99 for ; Sat, 2 Jan 2016 13:32:52 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 1DB3F9A4020; Sat, 2 Jan 2016 16:32:51 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id vm6jgm6PjQ0Z; Sat, 2 Jan 2016 16:31:42 -0500 (EST) Received: from [192.168.2.104] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 8E2179A4017; Sat, 2 Jan 2016 16:32:50 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-23-1016767621 From: Russ Housley In-Reply-To: <00e901d14435$0d92b950$28b82bf0$@ndzh.com> Date: Sat, 2 Jan 2016 16:32:49 -0500 Message-Id: References: <00e901d14435$0d92b950$28b82bf0$@ndzh.com> To: "Susan Hares" X-Mailer: Apple Mail (2.1085) Archived-At: Cc: 'Kathleen Moriarty' , secdir@ietf.org Subject: Re: [secdir] Early SecDir Reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2016 21:32:54 -0000 --Apple-Mail-23-1016767621 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sue: I believe that my comments have been addresses. I still see a great deal of overlap between Section 2.4 and requirements = SEC-REQ-09. Russ On Dec 31, 2015, at 8:37 PM, Susan Hares wrote: > Russ: > =20 > Just checking to see that all the issues you raised in for = draft-hares-i2rs-auth-trans on the SEC-DIR list: > http://www.ietf.org/mail-archive/web/secdir/current/msg05964.html > =20 > are answered in WG version of this draft: = draft-ietf-i2rs-protocol-security-requirements-01 > =20 > = https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-require= ments/ > =20 > I=92m ready to send this to the IESG for publication, but in checking = on the SEC-DIR list, > I did not see an OK. > =20 > Thank you for all your help to improve this draft on I2RS protocol = security. > =20 > Sue Hares =20 > =20 --Apple-Mail-23-1016767621 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Russ:
 
Just checking to see that all = the issues you raised in for draft-hares-i2rs-auth-trans on the SEC-DIR = list:
To: "'Russ Housley'" References: <00e901d14435$0d92b950$28b82bf0$@ndzh.com> In-Reply-To: Date: Sat, 2 Jan 2016 19:45:00 -0500 Message-ID: <006801d145bf$fd4df5f0$f7e9e1d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0069_01D14596.147AFB30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKUFkxonBTXeDmpyINqGwK33R98eAFpup72nVgFS8A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Kathleen Moriarty' , secdir@ietf.org Subject: Re: [secdir] Early SecDir Reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 00:45:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0069_01D14596.147AFB30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Russ: Thank you for letting me know your comments have been addressed. I will review the section 2.4 and SEC-REQ-09 to address the overlap. Sue Hares From: Russ Housley [mailto:housley@vigilsec.com] Sent: Saturday, January 02, 2016 4:33 PM To: Susan Hares Cc: 'Kathleen Moriarty'; 'Stephen Farrell'; secdir@ietf.org Subject: Re: [secdir] Early SecDir Reviews Sue: I believe that my comments have been addresses. I still see a great deal of overlap between Section 2.4 and requirements SEC-REQ-09. Russ On Dec 31, 2015, at 8:37 PM, Susan Hares wrote: Russ: Just checking to see that all the issues you raised in for draft-hares-i2rs-auth-trans on the SEC-DIR list: http://www.ietf.org/mail-archive/web/secdir/current/msg05964.html are answered in WG version of this draft: draft-ietf-i2rs-protocol-security-requirements-01 https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requireme nts/ I'm ready to send this to the IESG for publication, but in checking on the SEC-DIR list, I did not see an OK. Thank you for all your help to improve this draft on I2RS protocol security. Sue Hares ------=_NextPart_000_0069_01D14596.147AFB30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Russ:

 

Thank you for letting me know your comments have been = addressed.  I will review the section 2.4 and SEC-REQ-09 to address = the overlap.

 

Sue Hares

 

From:= = Russ Housley [mailto:housley@vigilsec.com]
Sent: Saturday, = January 02, 2016 4:33 PM
To: Susan Hares
Cc: = 'Kathleen Moriarty'; 'Stephen Farrell'; = secdir@ietf.org
Subject: Re: [secdir] Early SecDir = Reviews

 

Sue:

 

I = believe that my comments have been = addresses.

 

I = still see a great deal of overlap between Section 2.4 and requirements = SEC-REQ-09.

 

Russ

 

 

On = Dec 31, 2015, at 8:37 PM, Susan Hares wrote:



Russ:<= /o:p>

 =

Just = checking to see that all the issues you raised in for = draft-hares-i2rs-auth-trans on the SEC-DIR = list:

 =

are = answered in WG version of this draft: = draft-ietf-i2rs-protocol-security-requirements-01

 =

 =

I’m = ready to send this to the IESG for publication, but in checking on the = SEC-DIR list,

I did not = see an OK.

 =

Thank you = for all your help to improve this draft on I2RS protocol = security.

 =

Sue Hares =  

 =

 

------=_NextPart_000_0069_01D14596.147AFB30-- From nobody Mon Jan 4 05:25:29 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2743F1A88B2; Mon, 4 Jan 2016 05:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 bjsskQCwnTfa; Mon, 4 Jan 2016 05:25:24 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C831A88B1; Mon, 4 Jan 2016 05:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2424; q=dns/txt; s=iport; t=1451913924; x=1453123524; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=xGLiWQlTsAKZ/JUsv80fwK3q2I40G6DeZ7AMbOSSiJ4=; b=MbbVQqw+7cSIt+qSOE53b6yqiVc+GvBC98fwmE4d7s7q9YZM4Sxk/2ow 43M0c5tGQb7oyA6JvT8K/jBVvW09rvfNmH82EUfF3pUeVRILEAd/j7G/M ZCdhxDYliMrXR5VIhU1/VLSpFn+9nMKCZa5omUIs76GrSJ4uH1K9oZDVv A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQAEcopW/5hdJa1egzqBRYhTs3UBD?= =?us-ascii?q?YFkhi19OBQBAQEBAQEBgQqEOyMRVwEaCAImAgQwFQIQBAGIQa9EkRkBAQEBAQE?= =?us-ascii?q?BAwEBAQEBAR2BAYVVgg8IgmiHcy6BGwWXBgGIMIUggVyERohZjjkBIAEBQoQKh?= =?us-ascii?q?HqBCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,520,1444694400"; d="scan'208";a="223873651" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jan 2016 13:25:23 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u04DPNTk014858 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Jan 2016 13:25:23 GMT Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Jan 2016 07:25:22 -0600 Received: from xch-aln-004.cisco.com ([173.36.7.14]) by XCH-ALN-004.cisco.com ([173.36.7.14]) with mapi id 15.00.1104.009; Mon, 4 Jan 2016 07:25:23 -0600 From: "Klaas Wierenga (kwiereng)" To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-spring-problem-statement.all@tools.ietf.org" Thread-Topic: review of draft-ietf-spring-problem-statement-06 Thread-Index: AQHRRvNdX54wnez3UU6k7dgZ7LgM5g== Date: Mon, 4 Jan 2016 13:25:23 +0000 Message-ID: <98C9C83C-68AF-4593-A441-48C6EE7A9DA7@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.195.236] Content-Type: text/plain; charset="utf-8" Content-ID: <0168C46CBB4ED8439E498AF5B5ED4321@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [secdir] review of draft-ietf-spring-problem-statement-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 13:25:26 -0000 SGksDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3Vy aXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3Vt ZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3Jp dHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVj dG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBj b21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0KVGhpcyBk b2N1bWVudCBwcm92aWRlcyBhIHByb2JsZW0gc3RhdGVtZW50IGZvciBzb3VyY2UgYmFzZWQgdW5p Y2FzdCByb3V0aW5nIGFyY2hpdGVjdHVyZS4gVGhlIGRvY3VtZW50IGV4YW1pbmVzIGEgbnVtYmVy IG9mIHR5cGljYWwgdXNlIGNhc2VzIGluIG9yZGVyIHRvIGNvbWUgdXAgd2l0aCB0aGUgcmVxdWly ZW1lbnRzIGZvciB0aGUgdGFyZ2V0IGFyY2hpdGVjdHVyZS4NCg0KSSBiZWxpZXZlIHRoZSBkb2N1 bWVudCBpcyBjbGVhciBhbmQgd2VsbC13cml0dGVuIGFuZCByZWFkeSBmb3IgcHVibGljYXRpb24s IHdpdGggb25lIHNtYWxsIG5pdCwgc2VlIGJlbG93Lg0KDQpUaGUgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgc2VjdGlvbiBpcyBhIGxpdHRsZSBiaXQgbGlnaHQsIGJ1dCBpbiBsaW5lIHdpdGggdGhl IHJlc3Qgb2YgdGhlIGRvY3VtZW50LCBzbyBJIGJlbGlldmUgc3VmZmljaWVudCwgcHJvdmlkZWQg dGhhdCBhIG1vcmUgZGV0YWlsZWQgYW5hbHlzaXMgaXMgZG9uZSBpbiBmb3J0aGNvbWluZyBkb2N1 bWVudHMuIEkgaGF2ZSBvbmUgc21hbGwgbml0LCBpbiB0aGUgZG9jdW1lbnQgaXQgc2F5czoNCg0K 4oCUDQpUaGVyZSBpcyBhbiBhc3N1bWVkIHRydXN0IG1vZGVsIHN1Y2ggdGhhdCB0aGUgc291cmNl IGltcG9zaW5nIGFuDQogICBleHBsaWNpdCByb3V0ZSBvbiBhIHBhY2tldCBpcyBhc3N1bWVkIHRv IGJlIGFsbG93ZWQgdG8gZG8gc28uICBJdCBpcw0KICAgYXNzdW1lZCB0aGF0IHRoZSBkZWZhdWx0 IGJlaGF2aW9yIGlzIHRvIHN0cmlwIGFueSBpbnRlcm5hbCByb3V0aW5nDQogICBpbmZvcm1hdGlv biBmcm9tIHRoZSBwYWNrZXQgYmVmb3JlIHRoZSBwYWNrZXQgaXMgZm9yd2FyZGVkIG91dHNpZGUN CiAgIHRoZSBkb21haW4uICBJbiBzdWNoIGNvbnRleHQgdHJ1c3QgYm91bmRhcmllcyBTSE9VTEQg c3RyaXAgZXhwbGljaXQNCiAgIHJvdXRlcyBmcm9tIGEgcGFja2V0Lg0K4oCUDQoNCkl0IGlzIHVu Y2xlYXIgdG8gbWUgd2hldGhlciB0aGUgaWRlYSBpcyB0aGF0IGlmIHRoYXQgKm9ubHkgaW50ZXJu YWwqIGluZm8gaXMgc3RyaXBwZWQsIG9yICphbGwqLCBpLmUuIGlmIHRoZSBwcm92aWRlZCByb3V0 ZSBpcyB7aW50ZXJuYWwgaG9zdCAxLCBpbnRlcm5hbCBob3N0IDIsIGludGVybmFsIGhvc3QgMywg ZXh0ZXJuYWwgaG9zdCAxLCBleHRlcm5hbCBob3N0IDJ9LCBpcyB0aGUgaWRlYSB0aGF0IGF0IGVn cmVzcyB0aGUgd2hvbGUgc3BlY2lmaWMgcm91dGUgaXMgdHJpcHBlZCBvciB0aGF0IHdoYXQgcmVt YWlucyBpcyB7ZXh0ZXJuYWwgaG9zdCAxLCBleHRlcm5hbCBob3N0IDIpLCB3aXRoIGxlYXZpbmcg dXAgdG8gdGhlIHRyYW5zaXQgb3IgZGVzdGluYXRpb24gbmV0d29yayB0byBhcHBseSDigJxzdHJp cHBpbmcgcG9saWN54oCdIG9uIHRoZSByZW1haW5kZXIuIFBsZWFzZSBjbGFyaWZ5Lg0KDQpLbGFh cw== From nobody Mon Jan 4 08:27:44 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001D01A8A08; Mon, 4 Jan 2016 08:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8Q_ifgYBCrqu; Mon, 4 Jan 2016 08:27:35 -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 RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8593F1A89AE; Mon, 4 Jan 2016 08:27:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.20,521,1444687200"; d="asc'?scan'208,217";a="195528516" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jan 2016 17:27:32 +0100 From: Vincent Roca X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_779C5F10-1796-48F0-BBF2-428B089AB52F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 4 Jan 2016 17:27:31 +0100 Message-Id: To: IESG , secdir@ietf.org, draft-ietf-cdni-control-triggers@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [secdir] Secdir review of draft-ietf-cdni-control-triggers-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 16:27:41 -0000 --Apple-Mail=_779C5F10-1796-48F0-BBF2-428B089AB52F Content-Type: multipart/alternative; boundary="Apple-Mail=_57CC3254-247B-4FBF-B89D-4131EF64E1E9" --Apple-Mail=_57CC3254-247B-4FBF-B89D-4131EF64E1E9 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: not totally ready There are several topics I=E2=80=99d like to discuss: 1- Concerning the use of TLS to carry CI/T traffic, I see it is = mandatory to implement, but still optional to use (1st sentence of = Section 8.1). Is it still reasonable in current Internet? At a minimum I = would expect a =C2=AB MUST support =C2=BB / =C2=AB SHOULD use =C2=BB. 2- Section 8.1, please check the paragraph =C2=AB Note that in a =C2=AB = diamond =C2=BB configuration [=E2=80=A6] =C2=BB. This paragraph is = rather confusing to me. Confusion comes from: - the lack of description of the =C2=AB diamond configuration =C2=BB. = I understand there is one dCDN on top and multiple uCDN directly = connected below, am I right? - the notion of =C2=AB content acquired from a uCDN =C2=BB. If I = understand correctly, it means =C2=AB content that has been acquired = after a uCDN request to do so =C2=BB. I initially thought there were = some mistakes in the use of uCDN / dCDN=E2=80=A6 3- With this =C2=AB diamond configuration =C2=BB, since several uCDN can = act upon the same content, what happens if they behave in a non = coordinated manner (i.e., in the general case)? For instance let=E2=80=99s= imagine one of them asks the dCDN to delete the content or cancel the = initial command. What happens if another uCDN then asks the dCDN to = invalidate this content, providing the URL of the Trigger Status = Resource which (if I understand correctly) is no longer valid? This =C2=AB= diamond configuration =C2=BB can be a little bit tricky and no clear = guideline is provided in the document. 4- Concerning privacy aspects, I would be much more cautious than the = authors. For instance, I wouldn't claim "there are no privacy concerns = for End Users" because the CI/T protocol does not carry information = about individual End Users (section 8.3). The dCDN knows that there are = users interested (or at the opposite no user interested) by a certain = content in the region served by a uCDN. Therefore, the protocol only = provides k-anonymity, where k is the number of End Users in the region. = Depending on the content sensitivity and k value, this k-anonymity may = still raise privacy issues, even if the individual End User activity = logs are not available to the dCDN (I assume TLS is used to prevent = eavesdropping=E2=80=A6). Typo: ** Section 8.3: =C2=AB ... prevents parties other party..." Cheers, Vincent --Apple-Mail=_57CC3254-247B-4FBF-B89D-4131EF64E1E9 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: not totally ready


There are several topics I=E2=80=99d like to = discuss:

1- Concerning the use of TLS to carry CI/T traffic, I see it = is mandatory to implement, but still optional to use (1st sentence of = Section 8.1). Is it still reasonable in current Internet? At a minimum I = would expect a =C2=AB MUST support =C2=BB / =C2=AB SHOULD = use =C2=BB.


2- Section 8.1, please = check the paragraph =C2=AB Note that in a =C2=AB diamond =C2= =BB configuration [=E2=80=A6] =C2=BB. This paragraph is rather = confusing to me. Confusion comes from:
  - the = lack of description of the =C2=AB diamond configuration =C2=BB. = I understand there is one dCDN on top and multiple uCDN directly = connected below, am I right?
  - the notion of = =C2=AB content acquired from a uCDN =C2=BB. If I understand = correctly, it means =C2=AB content that has been acquired after a = uCDN request to do so =C2=BB. I initially thought there were some = mistakes in the use of uCDN / dCDN=E2=80=A6


3- = With this =C2=AB diamond configuration =C2=BB, since several = uCDN can act upon the same content, what happens if they behave in a non = coordinated manner (i.e., in the general case)? For instance let=E2=80=99s= imagine one of them asks the dCDN to delete the content or cancel the = initial command. What happens if another uCDN then asks the dCDN to = invalidate this content, providing the URL of the Trigger Status = Resource which (if I understand correctly) is no longer valid? This = =C2=AB diamond configuration =C2=BB can be a little bit tricky = and no clear guideline is provided in the document.


4- Concerning privacy aspects, I would be much more cautious = than the authors. For instance, I wouldn't claim "there are no privacy = concerns for End Users" because the CI/T protocol does not carry = information about individual End Users (section 8.3). The dCDN knows = that there are users interested (or at the opposite no user interested) = by a certain content in the region served by a uCDN. Therefore, the = protocol only provides k-anonymity, where k is the number of End Users = in the region. Depending on the content sensitivity and k value, this = k-anonymity may still raise privacy issues, even if the individual End = User activity logs are not available to the dCDN (I assume TLS is used = to prevent eavesdropping=E2=80=A6).


Typo:

** Section 8.3: =C2=AB ... prevents parties other = party..."


Cheers,

  Vincent
= --Apple-Mail=_57CC3254-247B-4FBF-B89D-4131EF64E1E9-- --Apple-Mail=_779C5F10-1796-48F0-BBF2-428B089AB52F 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWip10AAoJEHBYw8t72N4rL10QALUfmfUPxZdOEXd/JfB/qPIV /qdsQXggyveaTFOUEqMEsnYLzkenmndmt7b4MUjRgCqeLvRX5kub+Fk/DiZ+snbK w2n9hGzxgUJ8l1rC8FFv60VEOFiRJ6aKyycCPNjlzKf2YRJz9u60UWY4DQurr0BT Mxp4g6Ynd6p66aG2IeVMjAMixCO2XRn/4TI/iGydZTml0BcB7lw+iexQwWbII79/ DTfqQ6UOlncjcKvbBgwxr6Zyq59UNKe6+Sd4pHCAjTal/gl/xtzFBpGeHszhD/93 i8hcUxW9nQxgXvmsQ15TbviUixS8dgTqmMJbk0NxjZLdpZ7FnuQGOXCPPIFJaJvW /dyFtdGTcGcztKD5Ig+pynB2su+3UECSATYjaxtHbYJcQ5QNhx+9QFRhxTfha/QF yn4aRPv+oy5GsYi0GDNLkKdGpw5h5WrAL3r87yGy1ZH3EK6RWyBXmjwuc5MYeO5Z ewQoZkf9qyuvYuWC3rHMJldEF++QHA/KvhRViC4w4cm8Qm7RBpHx3T1/X2mwd60Y 1OsWYSZjwKoRj5rFq9qqqA9O67+ivr5vs14/n6xWo5gCmiP04Qw8u3l4Gi0liWlM eQdG2LxuUm69E582Nzek2Nt23d/6FwivYBOLwC69pBnwNfG6xTkZzXzGsnkzcrVZ fE9VjqMJ2wKYmTejfQIM =bKMi -----END PGP SIGNATURE----- --Apple-Mail=_779C5F10-1796-48F0-BBF2-428B089AB52F-- From nobody Mon Jan 4 10:30:15 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF38C1A0302; Mon, 4 Jan 2016 10:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Ffn2FzUd3_p8; Mon, 4 Jan 2016 10:30:11 -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 563BC1A02F1; Mon, 4 Jan 2016 10:30:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGI48577; Mon, 04 Jan 2016 18:30:07 +0000 (GMT) Received: from LHREML708-CAH.china.huawei.com (10.201.5.202) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 4 Jan 2016 18:30:06 +0000 Received: from SZXEML427-HUB.china.huawei.com (10.82.67.182) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 4 Jan 2016 18:30:06 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.252]) by szxeml427-hub.china.huawei.com ([10.82.67.182]) with mapi id 14.03.0235.001; Tue, 5 Jan 2016 02:30:00 +0800 From: Tina TSOU To: "Org Secdir@Ietf." , "draft-ietf-hip-rfc5205-bis.all@ietf.org" , "Org Iesg@Ietf." Thread-Topic: Secdir Review of draft-ietf-hip-rfc5205-bis-08 Thread-Index: AQHRRx3rdmz2/NeS50O5q3NB4825KA== Date: Mon, 4 Jan 2016 18:29:59 +0000 Message-ID: References: <568A94BF.4000004@si6networks.com> In-Reply-To: <568A94BF.4000004@si6networks.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.568ABA30.010D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.6.252, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0d68602873392bc2c3feb5a5c235de25 Archived-At: Subject: [secdir] Secdir Review of draft-ietf-hip-rfc5205-bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 18:30:13 -0000 RGVhciBhbGwsDQoNCkhhcHB5IE5ldyBZZWFyIDIwMTYhDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlz IGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRloa9zIG9uZ29pbmcg ZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRo ZSBJRVNHLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVu ZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYQ0KZGlyZWN0b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFu ZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3Ro ZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQoqKiBUZWNobmljYWwgKioNCg0KKiBTZWN0aW9uIDg6 DQoNCllvdSByZWZlciB0byBJUFNFQ0tFWSBSUiBbUkZDNDAyNV0gdG8gbm90ZSBzb21lIG9mIHRo ZSBwb3NzaWJsZSB0aHJlYXRzDQpmb3IgSElQIFJScy4gSSB0aGluayB5b3Ugc2hvdWxkIHNwZWxs IHRoZXNlIG91dCwgYW5kIGRpc2N1c3MgdGhlbQ0KZXhwbGljaXRseS4NCg0KDQoNCioqIEVkaXRv cmlhbCAqKg0KDQoqIFNlY3Rpb24gMywgcGFnZSA0Og0KPiAgSW4gdGhlIGZvbGxvd2luZywgd2Ug YXNzdW1lIHRoYXQgdGhlIEluaXRpYXRvciBmaXJzdCBxdWVyaWVzIGZvciBISVANCj4gIHJlc291 cmNlIHJlY29yZHMgYXQgdGhlIFJlc3BvbmRlciBGUUROLg0KDQpzL2F0L2Zvci8NCg0KDQoqIFNl Y3Rpb24gMywgcGFnZSA0Og0KPiBhbmQgZnVydGhlciBxdWVyaWVzIGZvciB0aGUgc2FtZSBvd25l ciBuYW1lIFNIT1VMRCBOT1QgYmUNCj4gIG1hZGUuDQoNCldoYXQncyBhbiAib3duZXIgbmFtZSI/ IE1heWJlIHRoaXMgc2hvdWxkIGJlICJkb21haW4gbmFtZSIsIGluc3RlYWQ/DQoNCg0KKiBTZWN0 aW9uIDMsIHBhZ2UgNToNCj4gIE5vdGUgdGhhdCBzdG9yaW5nIEhJUCBSUiBpbmZvcm1hdGlvbiBp biB0aGUgRE5TIGF0IGFuIEZRRE4gdGhhdCBpcw0KPiAgYXNzaWduZWQgdG8gYSBub24tSElQIG5v ZGUgbWlnaHQgaGF2ZSBpbGwgZWZmZWN0cyBvbiBpdHMgcmVhY2hhYmlsaXR5DQo+ICBieSBISVAg bm9kZXMuDQoNCnMvYS9hbi8NCg0KDQoqIFNlY3Rpb24gNC4yLCBwYWdlIDk6DQo+IFRoZSBSVlMN Cj4gIGluZm9ybWF0aW9uIG1heSBiZSBjb3BpZWQgYW5kIGFsaWduZWQgYWNyb3NzIG11bHRpcGxl IFJScywgb3IgbWF5IGJlDQo+ICBkaWZmZXJlbnQgZm9yIGVhY2ggb25lOyBhIGhvc3QgTVVTVCBj aGVjayB0aGF0IHRoZSBSVlMgdXNlZCBpcw0KPiAgYXNzb2NpYXRlZCB3aXRoIHRoZSBISSBiZWlu ZyB1c2VkLCB3aGVuIG11bHRpcGxlIGNob2ljZXMgYXJlDQo+ICBwcmVzZW50LiINCg0KVGhlcmUn cyBubyBtYXRjaGluZyBxdW90ZSBzaWduIGZvciB0aGlzIG9uZS4NCg0KDQpUaGFuayB5b3UsDQpU aW5hDQoNCg0K From nobody Tue Jan 5 08:36:39 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7BB1A8862; Tue, 5 Jan 2016 08:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8nHegz0G2Xeb; Tue, 5 Jan 2016 08:23:12 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C10151A8861; Tue, 5 Jan 2016 08:23:11 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 268CE6694081; Tue, 5 Jan 2016 16:23:07 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u05GN9nw031584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Jan 2016 17:23:09 +0100 Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.107]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 5 Jan 2016 17:23:09 +0100 From: "Murray, Rob (Rob)" To: Vincent Roca Thread-Topic: Secdir review of draft-ietf-cdni-control-triggers-11 Thread-Index: AQHRRwzfQRQykiwnh0mW9gDUEP6L557tC9uA Date: Tue, 5 Jan 2016 16:23:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151217 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-ID: <3CE4C68AF250A2439BE81ABD8DAEA03C@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 05 Jan 2016 08:36:34 -0800 Cc: "draft-ietf-cdni-control-triggers@tools.ietf.org" , IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-cdni-control-triggers-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 16:23:14 -0000 SGkgVmluY2VudCAtIG1hbnkgdGhhbmtzIGZvciB0aGUgcmV2aWV3LCByZXNwb25zZXMgaW5saW5l IGJlbG93Li4uDQoNCkNoZWVycywNClJvYi4NCg0KPiBGcm9tOiBWaW5jZW50IFJvY2EgPHZpbmNl bnQucm9jYUBpbnJpYS5mcj5EYXRlOiBNb25kYXksIDQgSmFudWFyeSAyMDE2IGF0IDE2OjI3DQo+ IFRvOiBJRVNHIDxpZXNnQGlldGYub3JnPiwgPHNlY2RpckBpZXRmLm9yZz4sIDxkcmFmdC1pZXRm LWNkbmktY29udHJvbC10cmlnZ2Vyc0B0b29scy5pZXRmLm9yZz4NCj4gQ2M6IFZpbmNlbnQgUm9j YSA8dmluY2VudC5yb2NhQGlucmlhLmZyPg0KPiBTdWJqZWN0OiBTZWNkaXIgcmV2aWV3IG9mIGRy YWZ0LWlldGYtY2RuaS1jb250cm9sLXRyaWdnZXJzLTExDQo+DQo+IEhlbGxvLA0KPg0KPiBJIGhh dmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3Rv cmF0ZeKAmXMgb25nb2luZw0KPiBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBi ZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNlDQo+IGNvbW1lbnRzIHdlcmUgd3JpdHRl biBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhDQo+IGRpcmVj dG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBj b21tZW50cyBqdXN0DQo+IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCj4NCj4g U3VtbWFyeTogbm90IHRvdGFsbHkgcmVhZHkNCj4NCj4NCj4gVGhlcmUgYXJlIHNldmVyYWwgdG9w aWNzIEnigJlkIGxpa2UgdG8gZGlzY3VzczoNCj4NCj4gMS0gQ29uY2VybmluZyB0aGUgdXNlIG9m IFRMUyB0byBjYXJyeSBDSS9UIHRyYWZmaWMsIEkgc2VlIGl0IGlzIG1hbmRhdG9yeQ0KPiB0byBp bXBsZW1lbnQsIGJ1dCBzdGlsbCBvcHRpb25hbCB0byB1c2UgKDFzdCBzZW50ZW5jZSBvZiBTZWN0 aW9uIDguMSkuIElzDQo+IGl0IHN0aWxsIHJlYXNvbmFibGUgaW4gY3VycmVudCBJbnRlcm5ldD8g QXQgYSBtaW5pbXVtIEkgd291bGQgZXhwZWN0IGENCj4gwqsgTVVTVCBzdXBwb3J0IMK7IC8gwqsg U0hPVUxEIHVzZSDCuy4NCg0KU2VjdGlvbiA4LjEgZ29lcyBvbiB0byBzYXkgLi4uDQoNCiAgIFsg Li4uIGRlc2NyaXB0aW9uIG9mIGJlbmVmaXRzIG9mIEhUVFBTIC4uLiBdDQoNCiAgIEluIGFuIGVu dmlyb25tZW50IHdoZXJlIGFueSBzdWNoIHByb3RlY3Rpb24gaXMgcmVxdWlyZWQsIG11dHVhbGx5 DQogICBhdXRoZW50aWNhdGVkIGVuY3J5cHRlZCB0cmFuc3BvcnQgTVVTVCBiZSB1c2VkIHRvIGVu c3VyZQ0KICAgY29uZmlkZW50aWFsaXR5IG9mIHRoZSBDSS9UIGluZm9ybWF0aW9uLiBUbyB0aGF0 IGVuZCwgVExTIE1VU1QgYmUNCiAgIHVzZWQgYnkgQ0kvVCwgaW5jbHVkaW5nIGF1dGhlbnRpY2F0 aW9uIG9mIHRoZSByZW1vdGUgZW5kLg0KDQouLi4gdGhlIEludGVybmV0IGlzIGNsZWFybHkgYW4g ZW52aXJvbm1lbnQgd2hlcmUgc3VjaCBwcm90ZWN0aW9uIGlzDQpyZXF1aXJlZCwgYW5kIGl0J2xs IG9mdGVuIGJlIHVzZWQgZm9yIHRoZXNlIGludGVyZmFjZXMgLSB3ZSBjb3VsZCBzdGF0ZQ0KdGhh dCBleHBsaWNpdGx5LCB3b3VsZCB0aGF0IGFkZHJlc3MgdGhlIGNvbmNlcm4/DQoNCkJ1dCwgQ0kv VCBjb3VsZCBhbHNvIGJlIGRlcGxveWVkIHRvIHJ1biBvdmVyIGEgVlBOIG9yIHByaXZhdGUgbmV0 d29yaw0KYmV0d2VlbiB0d28gaW50ZXJjb25uZWN0ZWQgQ0ROcywgaW4gc3VjaCBhbiBlbnZpcm9u bWVudCBIVFRQUyB0cmFuc3BvcnQNCndvdWxkIG5vdCBoYXZlIHRoZSBzYW1lIGJlbmVmaXRzLg0K DQoNCj4gMi0gU2VjdGlvbiA4LjEsIHBsZWFzZSBjaGVjayB0aGUgcGFyYWdyYXBoIMKrIE5vdGUg dGhhdCBpbiBhIMKrIGRpYW1vbmQgwrsNCj4gY29uZmlndXJhdGlvbiBb4oCmXSDCuy4gVGhpcyBw YXJhZ3JhcGggaXMgcmF0aGVyIGNvbmZ1c2luZyB0byBtZS4gQ29uZnVzaW9uDQo+IGNvbWVzIGZy b206DQo+IC0gdGhlIGxhY2sgb2YgZGVzY3JpcHRpb24gb2YgdGhlIMKrIGRpYW1vbmQgY29uZmln dXJhdGlvbiDCuy4gSSB1bmRlcnN0YW5kDQo+IHRoZXJlIGlzIG9uZSBkQ0ROIG9uIHRvcCBhbmQg bXVsdGlwbGUgdUNETiBkaXJlY3RseSBjb25uZWN0ZWQgYmVsb3csIGFtIEkNCj4gcmlnaHQ/DQoN ClllcywgdGhhdCdzIHJpZ2h0LiBUaGUgZHJhZnQgc2F5czoNCg0KICAgTm90ZSB0aGF0IGluIGEg ImRpYW1vbmQiIGNvbmZpZ3VyYXRpb24sIHdoZXJlIG9uZSB1Q0ROJ3MgY29udGVudCBjYW4NCiAg IGJlIGFjcXVpcmVkIHZpYSBtb3JlIHRoYW4gb25lIGRpcmVjdGx5LWNvbm5lY3RlZCB1Q0ROLA0K DQpXb3VsZCB0aGUgZm9sbG93aW5nIHJlYXJyYW5nZW1lbnQgaGVscD8gLi4uDQoNCiAgIEEgImRp YW1vbmQiIGNvbmZpZ3VyYXRpb24gaXMgb25lIHdoZXJlIGEgZENETiBjYW4gYWNxdWlyZSBhIHVD RE4ncw0KICAgY29udGVudCB2aWEgbW9yZSB0aGFuIG9uZSBkaXJlY3RseS1jb25uZWN0ZWQgdUNE Ti4gTm90ZSB0aGF0DQogICBpbiBhIGRpYW1vbmQgY29uZmlndXJhdGlvbiBbLi4uXQ0KDQoNCj4g LSB0aGUgbm90aW9uIG9mIMKrIGNvbnRlbnQgYWNxdWlyZWQgZnJvbSBhIHVDRE4gwrsuIElmIEkg dW5kZXJzdGFuZCBjb3JyZWN0bHksDQo+IGl0IG1lYW5zIMKrIGNvbnRlbnQgdGhhdCBoYXMgYmVl biBhY3F1aXJlZCBhZnRlciBhIHVDRE4gcmVxdWVzdCB0byBkbyBzbyDCuy4NCj4gSSBpbml0aWFs bHkgdGhvdWdodCB0aGVyZSB3ZXJlIHNvbWUgbWlzdGFrZXMgaW4gdGhlIHVzZSBvZiB1Q0ROIC8g ZENETuKApg0KDQpBIGRDRE4gd2lsbCBhbHdheXMgYWNxdWlyZSBjb250ZW50IGZyb20gYSB1Q0RO IGJlY2F1c2UgaXQncyBiZWVuIHJlcXVlc3RlZA0KdG8gZG8gc28gKHdpdGhvdXQgYSByZXF1ZXN0 IGl0IHdvbid0IGtub3cgdGhlIFVSTCBpbiB0aGUgdUNETikuDQoNClRoZSByZXF1ZXN0IGNhbiBi ZSBmcm9tIGFuIGVuZC1jbGllbnQgb3IgYSBmdXJ0aGVyLWRvd25zdHJlYW0gQ0ROLCBpbiB3aGlj aA0KY2FzZSB0aGUgY29udGVudCB3aWxsIGJlIGFjcXVpcmVkIG9uLWRlbWFuZCwgb3IgaXQgY2Fu IGJlIGEgQ0kvVA0KcHJlLXBvc2l0aW9uaW5nIHJlcXVlc3QgZnJvbSBhIHVDRE4uDQoNCkRvZXMg dGhhdCBoZWxwPyBJJ20gbm90IHN1cmUgd2hhdCBjaGFuZ2Ugb3IgY2xhcmlmaWNhdGlvbiB5b3Un cmUgYXNraW5nIGZvci4NCg0KDQo+IDMtIFdpdGggdGhpcyDCqyBkaWFtb25kIGNvbmZpZ3VyYXRp b24gwrssIHNpbmNlIHNldmVyYWwgdUNETiBjYW4gYWN0IHVwb24gdGhlDQo+IHNhbWUgY29udGVu dCwgd2hhdCBoYXBwZW5zIGlmIHRoZXkgYmVoYXZlIGluIGEgbm9uIGNvb3JkaW5hdGVkIG1hbm5l ciAoaS5lLiwNCj4gaW4gdGhlIGdlbmVyYWwgY2FzZSk/IEZvciBpbnN0YW5jZSBsZXTigJlzIGlt YWdpbmUgb25lIG9mIHRoZW0gYXNrcyB0aGUgZENETg0KPiB0byBkZWxldGUgdGhlIGNvbnRlbnQg b3IgY2FuY2VsIHRoZSBpbml0aWFsIGNvbW1hbmQuIFdoYXQgaGFwcGVucyBpZiBhbm90aGVyDQo+ IHVDRE4gdGhlbiBhc2tzIHRoZSBkQ0ROIHRvIGludmFsaWRhdGUgdGhpcyBjb250ZW50LCBwcm92 aWRpbmcgdGhlIFVSTCBvZiB0aGUNCj4gVHJpZ2dlciBTdGF0dXMgUmVzb3VyY2Ugd2hpY2ggKGlm IEkgdW5kZXJzdGFuZCBjb3JyZWN0bHkpIGlzIG5vIGxvbmdlciB2YWxpZD8NCj4gVGhpcyDCqyBk aWFtb25kIGNvbmZpZ3VyYXRpb24gwrsgY2FuIGJlIGEgbGl0dGxlIGJpdCB0cmlja3kgYW5kIG5v IGNsZWFyDQo+IGd1aWRlbGluZSBpcyBwcm92aWRlZCBpbiB0aGUgZG9jdW1lbnQuDQoNCkEgdHJp Z2dlciBzdGF0dXMgcmVzb3VyY2UgYmVsb25ncyB0byBvbmUgdUNETiBhbmQgY2Fubm90IGJlIGFj Y2Vzc2VkIG9yDQptYW5pcHVsYXRlZCBieSBhbnkgb3RoZXIgQ0ROLCBzZWN0aW9uIDMgcGFyYSAz IHNheXM6DQoNCiAgIFRyaWdnZXIgU3RhdHVzIFJlc291cmNlcyBiZWxvbmdpbmcgdG8gYSB1Q0RO IE1VU1QgTk9UDQogICBiZSB2aXNpYmxlIHRvIGFueSBvdGhlciBDRE4uIFRoZSBkQ0ROIGNvdWxk LCBmb3IgZXhhbXBsZSwgYWNoaWV2ZQ0KICAgdGhpcyBieSBvZmZlcmluZyBkaWZmZXJlbnQgY29s bGVjdGlvbiBVUkxzIHRvIGVhY2ggdUNETiwgYW5kL29yIGJ5DQogICBmaWx0ZXJpbmcgdGhlIHJl c3BvbnNlIGJhc2VkIG9uIHRoZSB1Q0ROIHdpdGggd2hpY2ggdGhlIEhUVFAgY2xpZW50DQogICBp cyBhc3NvY2lhdGVkLg0KDQpDb250ZW50IGFsd2F5cyBvcmlnaW5hdGVzIGZyb20gb25lIHVDRE4s IGJ1dCBpbiBhIGRpYW1vbmQgY29uZmlncmF0aW9uIHRoZXJlDQptYXkgYmUgbXVsdGlwbGUgcm91 dGVzICh2aWEgb3RoZXIgQ0ROcykgdG8gYSBnaXZlbiBkQ0ROLg0KDQpUaGUgbW9zdCBjb21tb24g c2NlbmFyaW8gbWF5IHdlbGwgYmUgdGhhdCB0aGUgdUNETiB3aWxsIGluaXRpYXRlIGFsbCBvZiB0 aGUNCkNJL1QgY29tbWFuZHMgcmVsYXRlZCB0byBpdHMgY29udGVudCwgYW5kIHRob3NlIGNvbW1h bmRzIHdpbGwgc2ltcGx5IGJlDQpmb3J3YXJkZWQgYnkgaW50ZXJtZWRpYXRlIENETnMuDQoNCkJ1 dCwgdGhlcmUncyBub3RoaW5nIHRvIHN0b3AgYW4gaW50ZXJtZWRpYXRlIENETiBpbml0aWF0aW5n IG9yIG1vZGlmeWluZw0KQ0kvVCBjb21tYW5kcyAtIGFuZCBzb21lIG1vZGlmaWNhdGlvbnMgb2Yg dGhlIGNvbW1hbmQgd2lsbCBiZSBuZWNlc3NhcnkNCihmb3IgZXhhbXBsZSwgbWV0YWRhdGEgVVJM cyB3aWxsIG5lZWQgdG8gYmUgY2hhbmdlZCkuDQoNCkJ5IGFuYWx5c2lzIG9mIGxvZyBmaWxlcyBp dCB3aWxsIHByb2JhYmx5IGJlIHBvc3NpYmxlIHRvIHdvcmsgb3V0IHdoaWNoDQp1Q0ROIGFuIGlu ZGl2aWR1YWwgY2FjaGUgaW4gdGhlIGRDRE4gYWNxdWlyZWQgZWFjaCBjYWNoZWQgcmVzb3VyY2Ug ZnJvbS4NCkJ1dCB0aGUgY2FjaGUgaXMgbm90IHJlcXVpcmVkIHRvIGtlZXAgYSBsaXZlIHJlY29y ZCBvZiB0aGF0LCBhbmQgaXQNCnByb2JhYmx5IHdvbid0LiBJbiB0aGF0IGNhc2UsIHdoZW4gaXQg cmVjZWl2ZXMgYSBDSS9UIGNvbW1hbmQgdG8gaW52YWxpZGF0ZQ0Kb3IgcHVyZ2UgY29udGVudCwg dGhlIGRDRE4gc2hvdWxkIGFwcGx5IHRoYXQgY29tbWFuZCB0byBhbnkgY29udGVudCBpdA0KbWF5 IGhhdmUgYWNxdWlyZWQgZnJvbSB0aGUgdUNETiBpdCBnb3QgdGhlIENJL1QgY29tbWFuZCBmcm9t Lg0KDQpTbyB0aGVyZSBpcyBzY29wZSBmb3IgYSBtYWxpY2lvdXMgaW50ZXJtZWRpYXRlIENETiB0 byBjYXVzZSBleHRyYSBwcm9jZXNzaW5nDQphbmQgYWNxdWlzaXRpb24gYnkgYSBkQ0ROIChhbmQg dGhhdCdzIG1lbnRpb25lZCBpbiBzZWN0aW9uIDgpLiBCdXQgYQ0KbWFsaWNpb3VzIENETiBpcyBs aWtlbHkgdG8gZmluZCBpdHNlbGYgcmVtb3ZlZCBmcm9tIHRoZSBDRE4gZmVkZXJhdGlvbiBmYWly bHkNCnF1aWNrbHkgLSB0aGVyZSB3aWxsIG5lY2Vzc2FyaWx5IGJlIGEgbGV2ZWwgb2YgdHJ1c3Qg YmV0d2VlbiBpbnRlcmNvbm5lY3RlZA0KQ0ROcy4NCg0KV291bGQgaXQgaGVscCB0byBzcGVsbCBv dXQgc29tZSBvZiB0aGF0IGluIHRoZSBkcmFmdD8gKFRoZSBzYW1lIG9yIHZlcnkNCnNpbWlsYXIg dGV4dCBoYXMgYmVlbiB1c2VkIGluIHNldmVyYWwgb2YgdGhlIENETkkgZHJhZnRzLikNCg0KDQo+ IDQtIENvbmNlcm5pbmcgcHJpdmFjeSBhc3BlY3RzLCBJIHdvdWxkIGJlIG11Y2ggbW9yZSBjYXV0 aW91cyB0aGFuIHRoZSBhdXRob3JzLg0KPiBGb3IgaW5zdGFuY2UsIEkgd291bGRuJ3QgY2xhaW0g InRoZXJlIGFyZSBubyBwcml2YWN5IGNvbmNlcm5zIGZvciBFbmQgVXNlcnMiDQo+IGJlY2F1c2Ug dGhlIENJL1QgcHJvdG9jb2wgZG9lcyBub3QgY2FycnkgaW5mb3JtYXRpb24gYWJvdXQgaW5kaXZp ZHVhbCBFbmQNCj4gVXNlcnMgKHNlY3Rpb24gOC4zKS4gVGhlIGRDRE4ga25vd3MgdGhhdCB0aGVy ZSBhcmUgdXNlcnMgaW50ZXJlc3RlZCAob3IgYXQNCj4gdGhlIG9wcG9zaXRlIG5vIHVzZXIgaW50 ZXJlc3RlZCkgYnkgYSBjZXJ0YWluIGNvbnRlbnQgaW4gdGhlIHJlZ2lvbiBzZXJ2ZWQNCj4gYnkg YSB1Q0ROLiBUaGVyZWZvcmUsIHRoZSBwcm90b2NvbCBvbmx5IHByb3ZpZGVzIGstYW5vbnltaXR5 LCB3aGVyZSBrIGlzIHRoZQ0KPiBudW1iZXIgb2YgRW5kIFVzZXJzIGluIHRoZSByZWdpb24uIERl cGVuZGluZyBvbiB0aGUgY29udGVudCBzZW5zaXRpdml0eSBhbmQNCj4gayB2YWx1ZSwgdGhpcyBr LWFub255bWl0eSBtYXkgc3RpbGwgcmFpc2UgcHJpdmFjeSBpc3N1ZXMsIGV2ZW4gaWYgdGhlDQo+ IGluZGl2aWR1YWwgRW5kIFVzZXIgYWN0aXZpdHkgbG9ncyBhcmUgbm90IGF2YWlsYWJsZSB0byB0 aGUgZENETiAoSSBhc3N1bWUNCj4gVExTIGlzIHVzZWQgdG8gcHJldmVudCBlYXZlc2Ryb3BwaW5n 4oCmKS4NCg0KSSBkb24ndCB0aGluayB0aGF0IGFuYWx5c2lzIGlzIGNvcnJlY3QuLi4NCg0KSXJy ZXNwZWN0aXZlIG9mIENJL1QsIHRoZSBkQ0ROIHdpbGwgYWx3YXlzIGtub3cgd2hvJ3MgYWNjZXNz aW5nIHRoZSBjb250ZW50LA0KY2xpZW50cyBhcmUgbWFraW5nIHRoZWlyIHJlcXVlc3RzIGRpcmVj dGx5IHRvIGl0Lg0KDQpUaGUgQ0kvVCBpbnRlcmZhY2UgaXMgb25seSBhIHNtYWxsIHBhcnQgb2Yg Q0ROIEludGVyY29ubmVjdGlvbi4gVGhlcmUgYXJlDQpvdGhlciBpbnRlcmZhY2VzIGZvciBkaXN0 cmlidXRpb24gb2YgbWV0YWRhdGEsIHJlcXVlc3Qgcm91dGluZywgYW5kIHJldHJpZXZhbA0Kb2Yg ZENETiBsb2cgZmlsZXMgYnkgdGhlIHVDRE4uDQoNClNpZ25pZmljYW50IHdvcmsgd2VudCBpbiB0 byB0aGUgQ0ROSSBsb2dnaW5nIGludGVyZmFjZSB0byBtYWtlIGl0IHBvc3NpYmxlDQp0byBhbm9u eW1pc2UvYWdncmVnYXRlIGVuZC1jbGllbnQgaW5mb3JtYXRpb24gYmVmb3JlIHNoYXJpbmcgaXQg d2l0aCBhDQp1Q0ROIC0gYnV0IHRoYXQncyBub3QgcmVsZXZhbnQgdG8gdGhlIENJL1QgaW50ZXJm YWNlLCB3aGljaCBkb2VzIG5vdCBjYXJyeQ0KYW55IGVuZC11c2VyIHNwZWNpZmljIGluZm9ybWF0 aW9uLg0KDQpUaGUgQ0kvVCBpbnRlcmZhY2UgZG9lcyBub3QgZXhwb3NlIGFueSBkQ0ROIGluZm9y bWF0aW9uIGFib3V0IGVuZC1jbGllbnRzIHRvDQp0aGUgdUNETi4NCg0KDQo+IFR5cG86DQo+DQo+ ICoqIFNlY3Rpb24gOC4zOiDCqyAuLi4gcHJldmVudHMgcGFydGllcyBvdGhlciBwYXJ0eS4uLiIN Cg0KV2lsbCBmaXgsIHRoYW5rcy4NCg0KDQo+IENoZWVycywNCj4NCj4gIFZpbmNlbnQNCg0K From nobody Wed Jan 6 00:27:45 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15231A89A0; Wed, 6 Jan 2016 00:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 oeqXJ_44L3Ln; Wed, 6 Jan 2016 00:27:40 -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 RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195781A8997; Wed, 6 Jan 2016 00:27:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.20,528,1444687200"; d="asc'?scan'208";a="195815698" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jan 2016 09:27:38 +0100 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CB7C5BBA-397B-4033-B4B8-357BB548950F"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Vincent Roca In-Reply-To: Date: Wed, 6 Jan 2016 09:27:37 +0100 Message-Id: References: To: "Murray, Rob (Rob)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "draft-ietf-cdni-control-triggers@tools.ietf.org" , IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-cdni-control-triggers-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 08:27:43 -0000 --Apple-Mail=_CB7C5BBA-397B-4033-B4B8-357BB548950F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Rob, > Hi Vincent - many thanks for the review, responses inline below=E2=80=A6= You=E2=80=99re welcome. >> There are several topics I=E2=80=99d like to discuss: >>=20 >> 1- Concerning the use of TLS to carry CI/T traffic, I see it is = mandatory >> to implement, but still optional to use (1st sentence of Section = 8.1). Is >> it still reasonable in current Internet? At a minimum I would expect = a >> =C2=AB MUST support =C2=BB / =C2=AB SHOULD use =C2=BB. >=20 > Section 8.1 goes on to say ... >=20 > [ ... description of benefits of HTTPS ... ] >=20 > In an environment where any such protection is required, mutually > authenticated encrypted transport MUST be used to ensure > confidentiality of the CI/T information. To that end, TLS MUST be > used by CI/T, including authentication of the remote end. >=20 > ... the Internet is clearly an environment where such protection is > required, and it'll often be used for these interfaces - we could = state > that explicitly, would that address the concern? >=20 > But, CI/T could also be deployed to run over a VPN or private network > between two interconnected CDNs, in such an environment HTTPS = transport > would not have the same benefits. Yes, that=E2=80=99s my point. Say explicitly that Internet is an example = of environment where such a protection is mandatory. >> 2- Section 8.1, please check the paragraph =C2=AB Note that in a =C2=AB= diamond =C2=BB >> configuration [=E2=80=A6] =C2=BB. This paragraph is rather confusing = to me. Confusion >> comes from: >> - the lack of description of the =C2=AB diamond configuration =C2=BB. = I understand >> there is one dCDN on top and multiple uCDN directly connected below, = am I >> right? >=20 > Yes, that's right. The draft says: >=20 > Note that in a "diamond" configuration, where one uCDN's content can > be acquired via more than one directly-connected uCDN, >=20 > Would the following rearrangement help? ... >=20 > A "diamond" configuration is one where a dCDN can acquire a uCDN's > content via more than one directly-connected uCDN. Note that > in a diamond configuration [=E2=80=A6] Yes, I prefer this version. However, can the same =C2=AB uCDN=E2=80=99s = content =C2=BB be available at several uCDNs in this diamond configuration? Said = differently, what about the following text: A =C2=AB diamond =C2=BB configuration is one where a dCDN can = acquire a given content via more than one directly-connected uCDN. Note that = [=E2=80=A6] >> - the notion of =C2=AB content acquired from a uCDN =C2=BB. If I = understand correctly, >> it means =C2=AB content that has been acquired after a uCDN request = to do so =C2=BB. >> I initially thought there were some mistakes in the use of uCDN / = dCDN=E2=80=A6 >=20 > A dCDN will always acquire content from a uCDN because it's been = requested > to do so (without a request it won't know the URL in the uCDN). >=20 > The request can be from an end-client or a further-downstream CDN, in = which > case the content will be acquired on-demand, or it can be a CI/T > pre-positioning request from a uCDN. >=20 > Does that help? I=E2=80=99m not sure what change or clarification = you're asking for. Forget my comment, I misunderstood the notion of uCDN=E2=80=A6 I should = have read RFC 6707 before! >> 3- With this =C2=AB diamond configuration =C2=BB, since several uCDN = can act upon the >> same content, what happens if they behave in a non coordinated manner = (i.e., >> in the general case)? For instance let=E2=80=99s imagine one of them = asks the dCDN >> to delete the content or cancel the initial command. What happens if = another >> uCDN then asks the dCDN to invalidate this content, providing the URL = of the >> Trigger Status Resource which (if I understand correctly) is no = longer valid? >> This =C2=AB diamond configuration =C2=BB can be a little bit tricky = and no clear >> guideline is provided in the document. >=20 > A trigger status resource belongs to one uCDN and cannot be accessed = or > manipulated by any other CDN, section 3 para 3 says: >=20 > Trigger Status Resources belonging to a uCDN MUST NOT > be visible to any other CDN. The dCDN could, for example, achieve > this by offering different collection URLs to each uCDN, and/or by > filtering the response based on the uCDN with which the HTTP client > is associated. I see=E2=80=A6 However, if multiple uCDNs can act on the same content = (what is said), even if each uCDN uses a different URL, will simultaneous CI/T commands = for the same content be managed correctly? This is not said in section 3 paragraph 3 either and this is a key point. > Content always originates from one uCDN, but in a diamond configration = there > may be multiple routes (via other CDNs) to a given dCDN. >=20 > The most common scenario may well be that the uCDN will initiate all = of the > CI/T commands related to its content, and those commands will simply = be > forwarded by intermediate CDNs. >=20 > But, there's nothing to stop an intermediate CDN initiating or = modifying > CI/T commands - and some modifications of the command will be = necessary > (for example, metadata URLs will need to be changed). >=20 > By analysis of log files it will probably be possible to work out = which > uCDN an individual cache in the dCDN acquired each cached resource = from. > But the cache is not required to keep a live record of that, and it > probably won't. In that case, when it receives a CI/T command to = invalidate > or purge content, the dCDN should apply that command to any content it > may have acquired from the uCDN it got the CI/T command from. >=20 > So there is scope for a malicious intermediate CDN to cause extra = processing > and acquisition by a dCDN (and that's mentioned in section 8). But a > malicious CDN is likely to find itself removed from the CDN federation = fairly > quickly - there will necessarily be a level of trust between = interconnected > CDNs. >=20 > Would it help to spell out some of that in the draft? (The same or = very > similar text has been used in several of the CDNI drafts.) Yes, this paragraph is worth being detailed a little bit. In your explanations you mention intermediate CDNs while original text = only mentions directly connected uCDNs. The notion of =C2=AB intermediate CDN = =C2=BB is only discussed in sections 2.3 and 4.8. Since malicious intermediate = CDNs are part of a valid attack model, it is worth to explain it (or give a = reference to another document). >> 4- Concerning privacy aspects, I would be much more cautious than the = authors. >> For instance, I wouldn't claim "there are no privacy concerns for End = Users" >> because the CI/T protocol does not carry information about individual = End >> Users (section 8.3). The dCDN knows that there are users interested = (or at >> the opposite no user interested) by a certain content in the region = served >> by a uCDN. Therefore, the protocol only provides k-anonymity, where k = is the >> number of End Users in the region. Depending on the content = sensitivity and >> k value, this k-anonymity may still raise privacy issues, even if the >> individual End User activity logs are not available to the dCDN (I = assume >> TLS is used to prevent eavesdropping=E2=80=A6). >=20 > I don't think that analysis is correct... >=20 > Irrespective of CI/T, the dCDN will always know who's accessing the = content, > clients are making their requests directly to it. >=20 > The CI/T interface is only a small part of CDN Interconnection. There = are > other interfaces for distribution of metadata, request routing, and = retrieval > of dCDN log files by the uCDN. >=20 > Significant work went in to the CDNI logging interface to make it = possible > to anonymise/aggregate end-client information before sharing it with a > uCDN - but that's not relevant to the CI/T interface, which does not = carry > any end-user specific information. >=20 > The CI/T interface does not expose any dCDN information about = end-clients to > the uCDN. My comment is also caused by my misunderstanding of uCDN in the = architecture. So yes, I agree with you that there=E2=80=99s no privacy issue here. In any case, thanks for your detailed answer. And sorry for my = misunderstanding of the architecture. Cheers, Vincent --Apple-Mail=_CB7C5BBA-397B-4033-B4B8-357BB548950F 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWjM/5AAoJEHBYw8t72N4rlB8P/3nG188/R0gAlDtK+oELM82P yBk+gfHDdzBKoEW8LTeW/6WD4/TnkN/LY3aWEDHB5Q++l7l14xfLhcQeGEsz7qes 4UBs828xjCHvougxIa5Uja6UB+ilQ+9H8kkqcRUccWdafvXNTgDLwYd7LGrCwLJG yLgblqWJcQ7Ot/bCq/koYqScG6SGGbwZBRi9FeBAtoJb4Xlq7vKXiV+zslWOyglP I1HS2ZUlKysYzMKv8eBXLM2enWveIWLvjYSBRSxa5pFL81fLomQPGL8NU/T0NHl2 zq4dw7i7BGTwdewz04WaSQ4MXIarlDCbTJtU0BHO1AHPoKLd2xfTOov0oweALWqk 6deUHMUccjasw1bsH2013QQRkMkfzyFhTDnkxFk3zIWgD8PI1g+HCfHXtBn+2JCF /mCHnIjGcW7vFR99Q4y3NXdiAOWdKIAgkLQXYE5+NtFp8XFXfFcW9dIIWbqllNwO H9Ymi5z0vUFPAnZW/SSBJQXgtRRG0UIU94O0ioJrnu3+R/jyBlORHA32bDx1HR3x AaJ9vqhegsRzaeNGEY48v59/6v8TgrNFEmo54e45AodNdoQJzI7G2kYJl57ic4qw wLIQtw38ZVYlCRRkmVkBtMr2sY5HgbrXC0qW34a0epM6MACihy5E9nmJYEOegCMW jFXn5wlYALetRZOHO3Ho =QW4a -----END PGP SIGNATURE----- --Apple-Mail=_CB7C5BBA-397B-4033-B4B8-357BB548950F-- From nobody Wed Jan 6 04:10:27 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260421ACD45 for ; Wed, 6 Jan 2016 00:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 OtCUWrH3XyjX for ; Wed, 6 Jan 2016 00:31:03 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::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 019A21ACCEC for ; Wed, 6 Jan 2016 00:31:02 -0800 (PST) Received: by mail-ig0-x235.google.com with SMTP id ik10so27869759igb.1 for ; Wed, 06 Jan 2016 00:31:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-type:content-transfer-encoding; bh=ghaVLOM4qseeuAytHfJVO/qm3cP/H8kAmkakq6mcmPA=; b=acNNCR7c1dkM9eWr/GyvLTAsgnNkd0cnHyLqPdXSL56PZUEl1wnBFUoNfyEdm4h1kM 5BsuAr8guqzaCzuGuyPbuaJjNw2lfJGpQdGTACcKtdMFkqwomF7eyyKmu0eAmUFniQIt 7Vi1JUNm+WgInQQby2cQ6o/OYvInzVsjbvYWk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type :content-transfer-encoding; bh=ghaVLOM4qseeuAytHfJVO/qm3cP/H8kAmkakq6mcmPA=; b=g0icQbSPv+SszQF9tGN6jAg3bl+684VaTnC60UTCsIaa0xBEBNFbhsCJN4ayL5kDZx iHSOAT5Dxv5XbJJ9FLeJgCJE7dj/tQQWTnPMzo5xyBnxowB66bmAUsMVfWc2VG7IaJ/v alVBdnJRAQjH3wLqyn2in1rHpYcYXmNh8ru8sydji9EVovo5d1Br/6qeHe9AGulKRRg5 yT8tJSvQyWk4s70Y2yWnlIPbh6O7Jj9Bv9p+x4A4QCLXMpUqyj3sfFyA7xdTiNN8nj3c kKOi9BydeQxa9j9rh4b060AB7qh5p3xWx5SKBx9N+G8mTZTze4LVMzwonL7UybHX2mUy zqDA== X-Gm-Message-State: ALoCoQlEw2bLxR8mIMTnqLvE9tG+uNLAIua2o8qjXtNsLmgTa/DSjluNNBes/AdXNKVhqrM60gOMVB0tg4iBwtbOY3vBlMq+yvLE/OzacCA8Xqt4N3ekyX0l2GHcQj54sGdHWtc1Zjm4FAk5rHCxNCV9w1gMLVIPsg== X-Received: by 10.50.128.198 with SMTP id nq6mr7992984igb.96.1452069061676; Wed, 06 Jan 2016 00:31:01 -0800 (PST) From: Karen Elisabeth Egede Nielsen References: <5674683F.30308@nostrum.com> In-Reply-To: <5674683F.30308@nostrum.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIPY17I5aUwGrMMl8p8hgIOJvXwg55x7j4A Date: Wed, 6 Jan 2016 09:31:00 +0100 Message-ID: <4abd43f956e62870df92d15cb8662b36@mail.gmail.com> To: Robert Sparks , secdir@ietf.org, iesg@ietf.org, draft-ietf-tsvwg-sctp-failover.all@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: X-Mailman-Approved-At: Wed, 06 Jan 2016 04:10:26 -0800 Subject: Re: [secdir] Secdir review: draft-ietf-tsvwg-sctp-failover-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 08:31:05 -0000 Hi Robert, Thanks a lot for your comments. Please find feedback inline below. BR, Karen > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: 18. december 2015 21:11 > To: secdir@ietf.org; iesg@ietf.org; > draft-ietf-tsvwg-sctp-failover.all@ietf.org > Subject: Secdir review: draft-ietf-tsvwg-sctp-failover-14 > > 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 for publication as Proposed Standard but with nits that > should be considered > > This document defines a set of new SCTP sender behaviors that lead to > quicker failover. The behaviors have an obvious security consideration (i= t > is > much easier for an attacker trigger failover, and potentially steer > traffic to the > most favorable of the available paths for the attacker's purposes). The > document makes this very clear, and has a reasonable discussion in the > Security Considerations section. > > The shepherd writeup notes that what is here is widely (if partially in > some > cases) implemented and deployed. > > There are a few places I suggest would benefit from more attention: > > There are several places in the text that allow (MAY) the sender to choos= e > not to behave in the manner this document is trying to standardize. See > item > B in section 3.2, and item C in section 4 for example. These seem out of > place > - if something is doing those things, you might as well say they're > implementing some other unstandardized extension for failover. Why do > you need to include these statements? [Karen Elisabeth Egede Nielsen] The motivation for including the statements is to motivate the SHOULD statements (and to qualify the usage of SHOULD opposed to MUST). We have understood that such clarification was desirable (?). However for clarity in the specification we would be very happy to follow your guidance and remove the MAY paragraphs in section 3.2 and in section 4. We would however not like to use MUSTs. Would this action address your concerns ? > They don't standardize whatever private "because I know better" behavior > the endpoints they are discussing are engaging in. Consider deleting them= , > or > restructuring the text to make this look less like protocol definition. > (It's > particularly odd that B in 3.2 uses MAY, but A does not use SHOULD). > [Karen Elisabeth Egede Nielsen] The reason A does not use a SHOULD is because the RFC4960 text does not use a capital SHOULD. But perhaps we coul= d use a capital SHOULD in SCTP-PF even if we are referring to text that uses a non-capital should in RC4960 ? > The third paragraph of section 4 has a "does not compromise the fault > tolerance" condition, leaving what would be considered a compromise very > vague. Again, an endpoint choosing a different dormant state operation > than > the one you're standardizing here isn't behaving in a standard way. > Why do you need this paragraph? If you're going to keep it, consider > pointing > to or providing more discussion on what you mean by the condition. > > There are many unusual phrases used in the text. These are harder to read > than they need to be, and will be even harder to translate. Please > consider > an editorial pass _before_ this is in the RFC Editor's hands. > Search for "compromisation", "at exceed of which", "failover to deploy", > and > "unequivocally information" to get a feel for what I'm pointing to. > > [Karen Elisabeth Egede Nielsen] Thanks. #1: Compromisation/compromise: We could use =E2=80=9Clower/lowering off/decrease=E2=80=9D to be more preci= se. Would you think this would resolve your concern ? #2: Exceed of which: The PFMR defines the new intermediate PF threshold on the destination address error counter at exceed of which the destination address is classified as PF. We can reformulate to: The PFMR defines the new intermediate PF threshold on the destination address error counter. When this threshold is exceeded, the destination address is classified as PF. Would you think this would resolve your concern ? #3: Failover to deploy: i When there is outbound data to send and the destination address presently used for data transmission is in PF state, the sender SHOULD choose a destination address in active state, if one exists, and failover to deploy this destination address for data transmission. We can reformulate: i When there is outbound data to send and the destination address presently used for data transmission is in PF state, the sender SHOULD choose a destination address in active state, if one exists and deploy this destination address for data transmission. Would you think this would resolve your concern ? #4: unequivocally information: This would go away if we removed the MAY statement as suggested above. > > > > From nobody Wed Jan 6 07:33:43 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712501A8776; Wed, 6 Jan 2016 07:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 L3E_gS9yT9KK; Wed, 6 Jan 2016 07:33:39 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 645631A8768; Wed, 6 Jan 2016 07:33:33 -0800 (PST) Received: from unnumerable.local (pool-96-226-213-187.dllstx.fios.verizon.net [96.226.213.187]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u06FXV5m024634 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Wed, 6 Jan 2016 09:33:32 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-96-226-213-187.dllstx.fios.verizon.net [96.226.213.187] claimed to be unnumerable.local To: Karen Elisabeth Egede Nielsen , secdir@ietf.org, iesg@ietf.org, draft-ietf-tsvwg-sctp-failover.all@ietf.org References: <5674683F.30308@nostrum.com> <4abd43f956e62870df92d15cb8662b36@mail.gmail.com> From: Robert Sparks Message-ID: <568D33CC.1010804@nostrum.com> Date: Wed, 6 Jan 2016 09:33:32 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <4abd43f956e62870df92d15cb8662b36@mail.gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] Secdir review: draft-ietf-tsvwg-sctp-failover-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 15:33:41 -0000 On 1/6/16 2:31 AM, Karen Elisabeth Egede Nielsen wrote: > Hi Robert, > > Thanks a lot for your comments. > Please find feedback inline below. > > BR, Karen > >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@nostrum.com] >> Sent: 18. december 2015 21:11 >> To: secdir@ietf.org; iesg@ietf.org; >> draft-ietf-tsvwg-sctp-failover.all@ietf.org >> Subject: Secdir review: draft-ietf-tsvwg-sctp-failover-14 >> >> 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 for publication as Proposed Standard but with nits that >> should be considered >> >> This document defines a set of new SCTP sender behaviors that lead to >> quicker failover. The behaviors have an obvious security consideration (it >> is >> much easier for an attacker trigger failover, and potentially steer >> traffic to the >> most favorable of the available paths for the attacker's purposes). The >> document makes this very clear, and has a reasonable discussion in the >> Security Considerations section. >> >> The shepherd writeup notes that what is here is widely (if partially in >> some >> cases) implemented and deployed. >> >> There are a few places I suggest would benefit from more attention: >> >> There are several places in the text that allow (MAY) the sender to choose >> not to behave in the manner this document is trying to standardize. See >> item >> B in section 3.2, and item C in section 4 for example. These seem out of >> place >> - if something is doing those things, you might as well say they're >> implementing some other unstandardized extension for failover. Why do >> you need to include these statements? > [Karen Elisabeth Egede Nielsen] The motivation for including the statements > is to motivate the SHOULD statements (and to qualify the usage of SHOULD > opposed to MUST). > We have understood that such clarification was desirable (?). > > However for clarity in the specification we would be > very happy to follow your guidance and remove the MAY paragraphs in section > 3.2 and in section 4. > We would however not like to use MUSTs. > > Would this action address your concerns ? The document should provide explanation when using a SHOULD to let implementers know what circumstances warrant not following the SHOULD. What are the risks? In this particular case, you're saying "The implementation SHOULD do this standard thing, but it MAY go do some nonstandard thing". That does not make sense. _WHY_ do you not want to use MUSTs? If its only so that someone can go do non-standard things, say MUST. Some implementations do proprietary things all the time - they're just not working in a standardized way. If its because you think some other document will come along later and define a different, but still standardized behavior, use MUST and have that document update this one when the time comes. > > > >> They don't standardize whatever private "because I know better" behavior >> the endpoints they are discussing are engaging in. Consider deleting them, >> or >> restructuring the text to make this look less like protocol definition. >> (It's >> particularly odd that B in 3.2 uses MAY, but A does not use SHOULD). >> > [Karen Elisabeth Egede Nielsen] The reason A does not use a SHOULD is > because the RFC4960 text does not use a capital SHOULD. Because 4960 is (implicitly) saying MUST. If you implement 4960, you do what 6.4.1 says. I think you're pointing to the "should try to send" inside 6.4.1 - you are not making the same statement in this document. As this sentence is written, this extension to SCTP says the implementation SHOULD follow the SCTP spec, which does not make sense. My preference would be that you remove B (as argued above), and simply say "When choosing amng multiple destination addresses in active state an SCTP sender will follow the guiding principles in section 6.4.1 of [RFC4960] of choosing most divergent source-destination pairs..." > But perhaps we could > use > a capital SHOULD in SCTP-PF even if we are referring to text that uses a > non-capital should in RC4960 ? > >> The third paragraph of section 4 has a "does not compromise the fault >> tolerance" condition, leaving what would be considered a compromise very >> vague. Again, an endpoint choosing a different dormant state operation >> than >> the one you're standardizing here isn't behaving in a standard way. >> Why do you need this paragraph? If you're going to keep it, consider >> pointing >> to or providing more discussion on what you mean by the condition. >> >> There are many unusual phrases used in the text. These are harder to read >> than they need to be, and will be even harder to translate. Please >> consider >> an editorial pass _before_ this is in the RFC Editor's hands. >> Search for "compromisation", "at exceed of which", "failover to deploy", >> and >> "unequivocally information" to get a feel for what I'm pointing to. >> >> > [Karen Elisabeth Egede Nielsen] > Thanks. I've responded to the instances below inline, but please note that I did not provide an exhaustive list - these were examples. Please look through the rest of the document for other opportunities to simplify the text. > > #1: Compromisation/compromise: > > We could use “lower/lowering off/decrease” to be more precise. > > Would you think this would resolve your concern ? Yes, you're on the right track. > > #2: Exceed of which: > > The PFMR defines > the new intermediate PF threshold on the destination address > error counter at exceed of which the destination address is > classified as PF. > > We can reformulate to: > > The PFMR defines > the new intermediate PF threshold on the destination address > error counter. When this threshold is exceeded, the destination > address is > classified as PF. > > Would you think this would resolve your concern ? yes > > #3: Failover to deploy: > > i When there is outbound data to send and the destination > address presently used for data transmission is in PF state, > the sender SHOULD choose a destination address in active > state, if one exists, and failover to deploy this destination > address for data transmission. > > We can reformulate: > > i When there is outbound data to send and the destination > address presently used for data transmission is in PF state, > the sender SHOULD choose a destination address in active > state, if one exists and deploy this destination > address for data transmission. > > Would you think this would resolve your concern ? instead of 'deploy' consider saying 'use'? > > #4: unequivocally information: > > This would go away if we removed the MAY statement as suggested above. ack. > >> >> >> From nobody Thu Jan 7 04:51:46 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5181A897E for ; Thu, 7 Jan 2016 04:51:44 -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 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 NbuURqslqLvs for ; Thu, 7 Jan 2016 04:51:42 -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 E506E1A8966 for ; Thu, 7 Jan 2016 04:51:41 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u07CpbHm018322 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 7 Jan 2016 14:51:37 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u07CpbEx016539; Thu, 7 Jan 2016 14:51:37 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22158.24409.570434.999060@fireball.acr.fi> Date: Thu, 7 Jan 2016 14:51:37 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 07 Jan 2016 12:51:44 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Tobias Gondrom is next in the rotation. For telechat 2016-01-07 Reviewer LC end Draft Steve Hanna T 2015-11-30 draft-ietf-dnsop-edns-tcp-keepalive-05 Chris Inacio T 2015-12-07 draft-ietf-dnsop-5966bis-05 Russ Mundy T 2015-12-21 draft-leiba-netmod-regpolicy-update-02 Joe Salowey TR2015-09-07 draft-josefsson-scrypt-kdf-04 Rich Salz T 2015-12-21 draft-ietf-isis-pcr-04 For telechat 2016-01-21 Alan DeKok T 2016-01-18 draft-ietf-nfsv4-rfc3530-migration-update-07 Shawn Emery T 2016-01-18 draft-ietf-tcpm-undeployed-03 Yoav Nir TR2015-12-14 draft-ietf-dnsop-cookies-08 Joe Salowey T 2015-12-21 draft-ietf-dnsop-edns-client-subnet-06 Carl Wallace T 2015-12-24 draft-ietf-ippm-active-passive-05 For telechat 2016-02-04 Daniel Kahn Gillmor T 2016-02-02 draft-mahesh-mef-urn-01 Last calls and special requests: Derek Atkins 2016-01-18 draft-ietf-dnsop-edns-chain-query-05 Shaun Cooley 2016-01-15 draft-ietf-lisp-threats-14 Donald Eastlake 2016-01-18 draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-01 Daniel Kahn Gillmor E None draft-ietf-rtcweb-security-08 Jeffrey Hutzelman 2015-12-04 draft-ietf-core-block-18 Eric Osterweil 2016-01-05 draft-campbell-art-rfc5727-update-02 Hannes Tschofenig 2015-12-28 draft-ietf-hip-rfc5204-bis-07 Brian Weis E None draft-ietf-cdni-uri-signing-06 Frank Xialiang E None draft-ietf-netconf-restconf-09 Tom Yu E None draft-ietf-netconf-yang-library-03 Dacheng Zhang E None draft-ietf-netconf-yang-patch-07 -- kivinen@iki.fi From nobody Thu Jan 7 06:31:38 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83BA1A8AB4; Thu, 7 Jan 2016 06:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 e4b1xERVeF27; Thu, 7 Jan 2016 06:31:35 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id BCEAA1A8AB6; Thu, 7 Jan 2016 06:31:35 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E4DDA433460; Thu, 7 Jan 2016 14:31:34 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id CEDB2433436; Thu, 7 Jan 2016 14:31:34 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1452177094; bh=U13zLyz4qmXVrFH6aUf4+CNmryKi/GZ4mNvggkbiboA=; l=993; h=From:To:Date:From; b=xY+tXMZb5VtQBcopyQs0FX1afifSl7Z2yKSXZw8Kj7KOJlTw5sHTedtQ/abW13e7w ypOfnwsDg65K6WS2OZ5Expo8+vGowUsa7d1YtjYJKph5lCtteywSjkf1JAFj348lBA tuXFnTDoEpxlQ651GSxZ6/aRPyQSLIZGusJz0dkQ= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id C35A52026; Thu, 7 Jan 2016 14:31:34 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 7 Jan 2016 06:31:34 -0800 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.1076.000; Thu, 7 Jan 2016 09:31:34 -0500 From: "Salz, Rich" To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-isis-pcr.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-isis-pcr Thread-Index: AdFJV2sZ6YNAx+82Rc2AGiyuIvBJ/g== Date: Thu, 7 Jan 2016 14:31:33 +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.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [secdir] Secdir review of draft-ietf-isis-pcr X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 14:31:37 -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. My view: Ready with issues, about the security considerations section. I know very little about IS-IS, or even the overall routing discipline. One nit is that this document cannot easily be read stand-alone. That is p= robably okay, but a pointer to background RFC's are a definition of terms (= e.g., sub-TLV) would be helpful. I do not understand how "reserving capacity" or "specifying capacity" canno= t be used as a denial of service attack. Perhaps that is related to the ab= ove paragraph? Is there authentication (perhaps out of band) between IS-IS= systems? Message integrity that prevents spoofing or modification? Thanks. From nobody Thu Jan 7 08:00:59 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560E21A87BF; Thu, 7 Jan 2016 00:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.215 X-Spam-Level: ** X-Spam-Status: No, score=2.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 snYSjH_Xb_Yc; Thu, 7 Jan 2016 00:33:41 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1851A87AC; Thu, 7 Jan 2016 00:33:40 -0800 (PST) Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com [209.85.160.175]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5BC9227812A; Thu, 7 Jan 2016 17:33:38 +0900 (JST) Received: by mail-yk0-f175.google.com with SMTP id v14so239146979ykd.3; Thu, 07 Jan 2016 00:33:38 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.129.46.208 with SMTP id u199mr74353754ywu.129.1452155616865; Thu, 07 Jan 2016 00:33:36 -0800 (PST) Received: by 10.129.147.5 with HTTP; Thu, 7 Jan 2016 00:33:36 -0800 (PST) In-Reply-To: <568D33CC.1010804@nostrum.com> References: <5674683F.30308@nostrum.com> <4abd43f956e62870df92d15cb8662b36@mail.gmail.com> <568D33CC.1010804@nostrum.com> Date: Thu, 7 Jan 2016 00:33:36 -0800 X-Gmail-Original-Message-ID: Message-ID: From: Yoshifumi Nishida To: Robert Sparks Content-Type: multipart/alternative; boundary=001a11408592b3bdda0528ba5301 Archived-At: X-Mailman-Approved-At: Thu, 07 Jan 2016 08:00:59 -0800 Cc: Karen Elisabeth Egede Nielsen , draft-ietf-tsvwg-sctp-failover.all@ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] Secdir review: draft-ietf-tsvwg-sctp-failover-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 08:33:43 -0000 --001a11408592b3bdda0528ba5301 Content-Type: text/plain; charset=UTF-8 Hi Robert, On Wed, Jan 6, 2016 at 7:33 AM, Robert Sparks wrote: > > > On 1/6/16 2:31 AM, Karen Elisabeth Egede Nielsen wrote: > >> Hi Robert, >> >> Thanks a lot for your comments. >> Please find feedback inline below. >> >> BR, Karen >> >> -----Original Message----- >>> From: Robert Sparks [mailto:rjsparks@nostrum.com] >>> Sent: 18. december 2015 21:11 >>> To: secdir@ietf.org; iesg@ietf.org; >>> draft-ietf-tsvwg-sctp-failover.all@ietf.org >>> Subject: Secdir review: draft-ietf-tsvwg-sctp-failover-14 >>> >>> 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 for publication as Proposed Standard but with nits that >>> should be considered >>> >>> This document defines a set of new SCTP sender behaviors that lead to >>> quicker failover. The behaviors have an obvious security consideration >>> (it >>> is >>> much easier for an attacker trigger failover, and potentially steer >>> traffic to the >>> most favorable of the available paths for the attacker's purposes). The >>> document makes this very clear, and has a reasonable discussion in the >>> Security Considerations section. >>> >>> The shepherd writeup notes that what is here is widely (if partially in >>> some >>> cases) implemented and deployed. >>> >>> There are a few places I suggest would benefit from more attention: >>> >>> There are several places in the text that allow (MAY) the sender to >>> choose >>> not to behave in the manner this document is trying to standardize. See >>> item >>> B in section 3.2, and item C in section 4 for example. These seem out of >>> place >>> - if something is doing those things, you might as well say they're >>> implementing some other unstandardized extension for failover. Why do >>> you need to include these statements? >>> >> [Karen Elisabeth Egede Nielsen] The motivation for including the >> statements >> is to motivate the SHOULD statements (and to qualify the usage of SHOULD >> opposed to MUST). >> We have understood that such clarification was desirable (?). >> >> However for clarity in the specification we would be >> very happy to follow your guidance and remove the MAY paragraphs in >> section >> 3.2 and in section 4. >> We would however not like to use MUSTs. >> >> Would this action address your concerns ? >> > The document should provide explanation when using a SHOULD to let > implementers know what circumstances warrant not following the SHOULD. What > are the risks? > > In this particular case, you're saying "The implementation SHOULD do this > standard thing, but it MAY go do some nonstandard thing". That does not > make sense. > > _WHY_ do you not want to use MUSTs? If its only so that someone can go do > non-standard things, say MUST. Some implementations do proprietary things > all the time - they're just not working in a standardized way. If its > because you think some other document will come along later and define a > different, but still standardized behavior, use MUST and have that document > update this one when the time comes. With regard to Section 3.2 and Section 4 case you mentioned, both cases have several possible destinations to send data. We provide rules to pick a destination, but it might not be the best one as the knowledge SCTP stack can have is limited. (so, this might be a risk) So, If users can leverage external knowledge, we tried to allow them to override the rules. But, I think we don't need to standardize this part as you point out. Removing it is fine for me. Thanks, -- Yoshi --001a11408592b3bdda0528ba5301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Robert,

On Wed, Jan 6, 2016 at 7:33 = AM, Robert Sparks <rjsparks@nostrum.com> wrote:


On 1/6/16 2:31 AM, Karen Elisabeth Egede Nielsen wrote:
Hi Robert,

Thanks a lot for your comments.
Please find feedback inline below.

BR, Karen

-----Original Message-----
From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 18. december 2015 21:11
To: secdir@ietf.org; iesg@ietf.org; draft-ietf-tsvwg-sctp-failover.all@ietf.org
Subject: Secdir review: draft-ietf-tsvwg-sctp-failover-14

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 Thes= e
comments were written primarily for the benefit of the security area
directors.=C2=A0 Document editors and WG chairs should treat these comments=
just like any other last call comments.

Summary: Ready for publication as Proposed Standard but with nits that
should be considered

This document defines a set of new SCTP sender behaviors that lead to
quicker failover. The behaviors have an obvious security consideration (it<= br> is
much easier for an attacker trigger failover, and potentially steer
traffic to the
most favorable of the available paths for the attacker's purposes). The=
document makes this very clear, and has a reasonable discussion in the
Security Considerations section.

The shepherd writeup notes that what is here is widely (if partially in
some
cases) implemented and deployed.

There are a few places I suggest would benefit from more attention:

There are several places in the text that allow (MAY) the sender to choose<= br> not to behave in the manner this document is trying to standardize. See
item
B in section 3.2, and item C in section 4 for example. These seem out of place
- if something is doing those things, you might as well say they're
implementing some other unstandardized extension for failover. Why do
you need to include these statements?
[Karen Elisabeth Egede Nielsen] The motivation for including the statements=
is to motivate the SHOULD statements (and to qualify the usage of SHOULD opposed to MUST).
We have understood that such clarification was desirable (?).

However for clarity in the specification we would be
very happy to follow your guidance and remove the MAY paragraphs in section=
3.2 and in section 4.
We would however not like to use MUSTs.

Would this action address your concerns ?
The document should provide explanation when using a SHOULD to let implemen= ters know what circumstances warrant not following the SHOULD. What are the= risks?

In this particular case, you're saying "The implementation SHOULD = do this standard thing, but it MAY go do some nonstandard thing". That= does not make sense.

_WHY_ do you not want to use MUSTs? If its only so that someone can go do n= on-standard things, say MUST. Some implementations do proprietary things al= l the time - they're just not working in a standardized way. If its bec= ause you think some other document will come along later and define a diffe= rent, but still standardized behavior, use MUST and have that document upda= te this one when the time comes.

With regar= d to Section 3.2 and Section 4 case you mentioned, both cases have several = possible destinations to send data.
We provide rules to pick a de= stination, but it might not be the best one as the knowledge SCTP stack can= have is limited. (so, this might be a risk)=C2=A0
So, If users c= an leverage external knowledge, we tried to allow them to override the rule= s. But, I think we don't need to standardize this part as you point out= . Removing it is fine for me.=C2=A0

Thanks,
<= div>--
Yoshi

--001a11408592b3bdda0528ba5301-- From nobody Fri Jan 8 19:48:16 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7B61A01F7 for ; Fri, 8 Jan 2016 19:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 UUw79ocE1VXy for ; Fri, 8 Jan 2016 19:48:13 -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 A7D561A01F4 for ; Fri, 8 Jan 2016 19:48:13 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u093mAZN016653 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 9 Jan 2016 03:48:11 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u093m9UY030295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 9 Jan 2016 03:48:09 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u093m8r8005973; Sat, 9 Jan 2016 03:48:08 GMT Received: from [10.159.78.186] (/10.159.78.186) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Jan 2016 19:48:08 -0800 Message-ID: <56908353.5050200@oracle.com> Date: Fri, 08 Jan 2016 20:49:39 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: secdir@ietf.org References: <56595640.5060206@oracle.com> In-Reply-To: <56595640.5060206@oracle.com> X-Forwarded-Message-Id: <56595640.5060206@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: draft-ietf-tcpm-undeployed.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-tcpm-undeployed-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 03:48:14 -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 draft designates a number of TCP related RFCs to Historic or Informational status. The corresponding RFCs have either been superseded, not widely adopted, or no longer recommended. The security considerations section does exist and states that this RFC does not introduce any new considerations. The section goes on to say that any security aspects of the RFC are applicable to the RFCs in question. I agree with these assertions. General comments: None. Editorial comments: s/which which describes/which describes/ Shawn. -- From nobody Mon Jan 11 04:14:44 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12F21A899B for ; Mon, 11 Jan 2016 04:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ra6NybIpl6LA for ; Mon, 11 Jan 2016 04:14:37 -0800 (PST) Received: from BLU004-OMC3S4.hotmail.com (blu004-omc3s4.hotmail.com [65.55.116.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9FC1A8992 for ; Mon, 11 Jan 2016 04:14:36 -0800 (PST) Received: from BLU437-SMTP97 ([65.55.116.73]) by BLU004-OMC3S4.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 11 Jan 2016 04:14:36 -0800 X-TMN: [EJ/fxmw9Su4bfQa2g7A7Aoh6qydwtCtp] X-Originating-Email: [zhang_dacheng@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_6EFF9368-5BCA-4040-9AC6-C3BDD25BCDD3" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dacheng In-Reply-To: <56908353.5050200@oracle.com> Date: Mon, 11 Jan 2016 20:14:16 +0800 References: <56595640.5060206@oracle.com> <56908353.5050200@oracle.com> To: secdir@ietf.org X-Mailer: Apple Mail (2.1878.6) X-OriginalArrivalTime: 11 Jan 2016 12:14:34.0489 (UTC) FILETIME=[A2130E90:01D14C69] Archived-At: Cc: draft-ietf-netconf-yang-patch.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-netconf-yang-patch-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 12:14:43 -0000 --Apple-Mail=_6EFF9368-5BCA-4040-9AC6-C3BDD25BCDD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="GB2312" I have reviewed this document as part of the security directorate=A1=AFs = 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 defines a media type for a YANG-based editing mechanism = that can be used with the HTTP PATCH method. I agree that this mechanism does not introduce any new security issues, = beyond what is described in [I-D.ietf-netconf-restconf]. So, this draft = is almost ready for publication.=20 A question: In Section 2.6 you mentioned 'The server will save the running = datastore to non-volatile storage' . Do you assume the severs supporting = your mechanism always have non-volatile storage? An editorial comment: page 15: The 'value' node will contain one instance of foo:-> The 'value' node = contains one instance of foo: Cheers Dacheng= --Apple-Mail=_6EFF9368-5BCA-4040-9AC6-C3BDD25BCDD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="GB2312" I have reviewed this document = as part of the security directorate=A1=AFs 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 defines a media type for a = YANG-based editing mechanism that can be used with the HTTP PATCH = method.

I agree that this mechanism does not = introduce any new security issues, beyond what is described in [I-D.ietf-netconf-restconf]. So, this = draft is almost ready for = publication. 

A question:

In Section 2.6  you = mentioned 'The server will save the running datastore to non-volatile = storage' . Do you assume the severs supporting your mechanism = always have non-volatile storage?

An editorial = comment:
page 15:
The 'value' node will contain one instance of =
foo:-> The 'value' node contains one instance of =
foo:

Cheers

Dacheng
= --Apple-Mail=_6EFF9368-5BCA-4040-9AC6-C3BDD25BCDD3-- From nobody Mon Jan 11 09:30:35 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B901A8AFD; Mon, 11 Jan 2016 09:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 z2m5_vkjceJ6; Mon, 11 Jan 2016 09:30:33 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8F21A8BAF; Mon, 11 Jan 2016 09:30:33 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B8770423792; Mon, 11 Jan 2016 17:30:31 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 7CC6842376E; Mon, 11 Jan 2016 17:30:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1452533431; bh=wDTedDHChGm4UneSaV5WCUnIf6wXf6G0EB/Ynq7tcS4=; l=4000; h=From:To:Date:References:In-Reply-To:From; b=yXgHmW63FPpZht2iRcyEU3Sm9oIFTyp118NSZ67vdNXB1pD+2osbJ2wufRg+iHplY XRrkrgN6OgJbjUJetJdmBAOFL3VwT4WOzFDZwI2JmT2IU+rUq23GPz0nzM33xuFWcJ Y3M1GLGREQqunaFA9E944V9tY8jYVW+M8pKIUee0= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 76BEA2036; Mon, 11 Jan 2016 17:30:31 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 11 Jan 2016 12:30:31 -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.1076.000; Mon, 11 Jan 2016 12:30:31 -0500 From: "Salz, Rich" To: =?Windows-1252?Q?J=E1nos_Farkas?= , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-isis-pcr.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-isis-pcr Thread-Index: AdFJV2sZ6YNAx+82Rc2AGiyuIvBJ/gDZ+skAAApqicA= Date: Mon, 11 Jan 2016 17:30:30 +0000 Message-ID: References: <5693E624.3030106@ericsson.com> In-Reply-To: <5693E624.3030106@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.233] Content-Type: multipart/alternative; boundary="_000_beb4af9487104caeb442989d1201b274usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-isis-pcr X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 17:30:35 -0000 --_000_beb4af9487104caeb442989d1201b274usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for the reply; I think this is READY /r$, who needs to learn much more about routing =85 -- Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz --_000_beb4af9487104caeb442989d1201b274usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Thanks for the reply; I t= hink this is READY

 <= /p>

    &= nbsp;           /r$, who = needs to learn much more about routing =85

 <= /p>

-- 

Senior Architect, Akamai = Technologies

IM: richsalz@jabber.at Tw= itter: RichSalz

--_000_beb4af9487104caeb442989d1201b274usma1exdag1mb1msgcorpak_-- From nobody Mon Jan 11 09:31:44 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EBA1A8AF8; Mon, 11 Jan 2016 09:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 fH5YQYPYRl8g; Mon, 11 Jan 2016 09:28:08 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3071A8BB0; Mon, 11 Jan 2016 09:28:07 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-9b-5693e625e8ee Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9B.89.05041.526E3965; Mon, 11 Jan 2016 18:28:05 +0100 (CET) Received: from [159.107.143.209] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.248.2; Mon, 11 Jan 2016 18:28:04 +0100 Message-ID: <5693E624.3030106@ericsson.com> Date: Mon, 11 Jan 2016 18:28:04 +0100 From: =?windows-1252?Q?J=E1nos_Farkas?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Salz, Rich" , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-isis-pcr.all@tools.ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080906050301070800050205" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM2K7q67qs8lhBou7ZCy+PX/NZjHjz0Rm i9k3VrFZXD/Szmjxf0sni8WHhQ9ZHNg8Jh9ZwOxx9uY/Fo8lS34yeXy5/JnN4+znhywBrFFc NimpOZllqUX6dglcGTcWcxYsNak43vecuYHxp2YXIweHhICJxIuG3C5GTiBTTOLCvfVsXYxc HEIChxklFj9awwzhrGWU2PV0HTNIFa+AtsSn1keMIDaLgKrEkycN7CA2m4CzxKOLvUwgtqhA lMTRJVfZIeoFJU7OfMICMkhE4ACjxP5P68GKhAUMJXa9u8sKcoWQQJDEww8FIGFOgWCJHZ9W sYHYzAJhEheeHwKbIySgJvHp7UP2CYz8s5CMnYWkbBbQJGYBe4kHW8sgwvIS29/OYYaw9SWu 37nPiiy+gJFtFaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgJBzc8ttqB+PB546HGAU4GJV4 eAseTQoTYk0sK67MPcQowcGsJMKrtn1ymBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeJJnGMCGB 9MSS1OzU1ILUIpgsEwenVANj7GNHE/aNAeaG1j/j97jNPBaj2HVNSN2F6YzU4cz9z7je5KgU eqqzfF5/eruEzrvJMV0JQrHOLxPMhCXLF4aoN/y3nH+mPLHw4S9rwdbrN29f/sz7QpvLu6bt 5+PDV3adD62qqbR5yG/fsedZoUXO5+hXtiZJ+x4E/rmWuYz5+KNXziecOT8rsRRnJBpqMRcV JwIAyudlkYACAAA= Archived-At: X-Mailman-Approved-At: Mon, 11 Jan 2016 09:31:43 -0800 Subject: Re: [secdir] Secdir review of draft-ietf-isis-pcr X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 17:28:09 -0000 --------------080906050301070800050205 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Hi Rich, Thank you very much for your review! Please find response to your questions in-line. On 1/7/2016 3:31 PM, Salz, Rich 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. > > My view: Ready with issues, about the security considerations section. > > I know very little about IS-IS, or even the overall routing discipline. > > One nit is that this document cannot easily be read stand-alone. That is probably okay, but a pointer to background RFC's are a definition of terms (e.g., sub-TLV) would be helpful. This document largely relies on the following IS-IS specifications: RFC6329 (IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging), RFC5305 (IS-IS Extensions for Traffic Engineering) and ietf-isis-te-metric-extensions, which are all normative references. Further pointers are given to the corresponding IEEE 802.1 specifications, which explain the use of the IS-IS sub-TLVs. We can give further references if there is anything in particular that is not clear. > > I do not understand how "reserving capacity" or "specifying capacity" cannot be used as a denial of service attack. Perhaps that is related to the above paragraph? Yes, this is pointed out in the penultimate paragraph of the security considerations. IS-IS PCR follows the PCE architecture specified by RFC4655. Therefore, the security considerations of RFC4655 are applicable here too, which I believe is stated in this paragraph. > Is there authentication (perhaps out of band) between IS-IS systems? Message integrity that prevents spoofing or modification? Yes, security solutions are available for IS-IS. The last paragraph of security considerations is intended to describe this. It first explains that IS-IS security considerations apply as IS-IS PCR is based on IS-IS. Furthermore, this paragraph also points out that the existing IS-IS security solutions are applicable for IS-IS PDUs between PCE and IS-IS System and among IS-IS Systems. This paragraph refers to RFC5310 (IS-IS Generic Cryptographic Authentication), which refers further to RFC 5304 (IS-IS Cryptographic Authentication); which can be used for IS-IS PCR. We can make updates to the text if you find anything missing. Please let us know. Regards, Janos --------------080906050301070800050205 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 7bit Hi Rich,

Thank you very much for your review!
Please find response to your questions in-line.

On 1/7/2016 3:31 PM, Salz, Rich 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.

My view: Ready with issues, about the security considerations section.

I know very little about IS-IS, or even the overall routing discipline.

One nit is that this document cannot easily be read stand-alone.  That is probably okay, but a pointer to background RFC's are a definition of terms (e.g., sub-TLV) would be helpful.
This document largely relies on the following IS-IS specifications: RFC6329 (IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging), RFC5305 (IS-IS Extensions for Traffic Engineering) and ietf-isis-te-metric-extensions, which are all normative references. Further pointers are given to the corresponding IEEE 802.1 specifications, which explain the use of the IS-IS sub-TLVs.
We can give further references if there is anything in particular that is not clear.


I do not understand how "reserving capacity" or "specifying capacity" cannot be used as a denial of service attack.  Perhaps that is related to the above paragraph?
Yes, this is pointed out in the penultimate paragraph of the security considerations. IS-IS PCR follows the PCE architecture specified by RFC4655. Therefore, the security considerations of RFC4655 are applicable here too, which I believe is stated in this paragraph.

Is there authentication (perhaps out of band) between IS-IS systems?  Message integrity that prevents spoofing or modification?
Yes, security solutions are available for IS-IS.
The last paragraph of security considerations is intended to describe this. It first explains that IS-IS security considerations apply as IS-IS PCR is based on IS-IS. Furthermore, this paragraph also points out that the existing IS-IS security solutions are applicable for IS-IS PDUs between PCE and IS-IS System and among IS-IS Systems. This paragraph refers to RFC5310 (IS-IS Generic Cryptographic Authentication), which refers further to RFC 5304 (IS-IS Cryptographic Authentication); which can be used for IS-IS PCR.

We can make updates to the text if you find anything missing. Please let us know.

Regards,
Janos

 --------------080906050301070800050205-- From nobody Mon Jan 11 11:49:23 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293A31A9098; Mon, 11 Jan 2016 11:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 N4sAKOek8KDn; Mon, 11 Jan 2016 11:49:20 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F201A00C3; Mon, 11 Jan 2016 11:49:19 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-22-5694073d69b2 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B8.95.02707.D3704965; Mon, 11 Jan 2016 20:49:17 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0248.002; Mon, 11 Jan 2016 20:49:17 +0100 From: Janos Farkas To: "Salz, Rich" , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-isis-pcr.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-isis-pcr Thread-Index: AdFJV2sZ6YNAx+82Rc2AGiyuIvBJ/gDPgJQA///v6gD//8iR0A== Date: Mon, 11 Jan 2016 19:49:17 +0000 Message-ID: <9CD5C257DEDA1E4C9DB416A2D6F02F733731BD13@ESESSMB209.ericsson.se> References: <5693E624.3030106@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_9CD5C257DEDA1E4C9DB416A2D6F02F733731BD13ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2K7tK4t+5QwgxWPjCy+PX/NZjHjz0Rm i/9bOlksPix8yOLA4jH5yAJmjyVLfjJ5fLn8mS2AOYrLJiU1J7MstUjfLoEr48fUVraCdToV X35INDB+V+9i5OSQEDCReHjpGwuELSZx4d56ti5GLg4hgcOMEhOe9TNBOIsZJX7vmccOUsUm oCcx9eYsdpCEiMABRon9n9YzgSSEBQwllry6CmaLCBhJ7H1/ixnCdpK41rUFzGYRUJV4NvUI 2DpeAV+Jd7tBakA27GWU+Hj0HytIglMgWOLnx9NgDYxAN30/tQZsKLOAuMStJ/OZIG4VkFiy 5zwzhC0q8fIxRK+EgJLEotufoerzJVatncAEsUxQ4uTMJywTGEVmIRk1C0nZLCRlEHEdiQW7 P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYOQd3PLb YAfjy+eOhxgFOBiVeHgLHk0KE2JNLCuuzD3EKMHBrCTCm8E4JUyINyWxsiq1KD++qDQntfgQ ozQHi5I4b5JMY5iQQHpiSWp2ampBahFMlomDU6qBMZFf3cfq8cQ+XTtJ/YNt1toztu/w9vo+ aZ7HlEBxRxe3P7PMWSJ0NkT9LxM7+/XEPNGYvGuF07/+X7Nnc/Q089M/N28zYrv3a6OXeXr6 3luT+R+6ZKREfnW8+H/RAlsnj7p9HBkztkfyWrhOvlnFq2K9Z17m/I1VCy/ciFAxKuV8IMrz 0nXvTiWW4oxEQy3mouJEAODFzBS4AgAA Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-isis-pcr X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 19:49:22 -0000 --_000_9CD5C257DEDA1E4C9DB416A2D6F02F733731BD13ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you! Janos From: Salz, Rich [mailto:rsalz@akamai.com] Sent: Monday, January 11, 2016 6:31 PM To: Janos Farkas; iesg@ietf.org; secdir@ietf.org; draft-ietf-isis-pcr.all@t= ools.ietf.org Subject: RE: Secdir review of draft-ietf-isis-pcr Thanks for the reply; I think this is READY /r$, who needs to learn much more about routing ... -- Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz --_000_9CD5C257DEDA1E4C9DB416A2D6F02F733731BD13ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you!

Janos

 <= /p>

From: Salz, Rich [mailto:rsalz@akamai.com]
Sent: Monday, January 11, 2016 6:31 PM
To: Janos Farkas; iesg@ietf.org; secdir@ietf.org; draft-ietf-isis-pc= r.all@tools.ietf.org
Subject: RE: Secdir review of draft-ietf-isis-pcr<= /p>

 

Thanks for the reply; I t= hink this is READY

 <= /p>

    &= nbsp;           /r$, who = needs to learn much more about routing …

 <= /p>

-- 

Senior Architect, Akamai = Technologies

IM: richsalz@jabber.at Twitter: RichS= alz

--_000_9CD5C257DEDA1E4C9DB416A2D6F02F733731BD13ESESSMB209erics_-- From nobody Tue Jan 12 00:28:22 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D9B1A1EF1; Tue, 12 Jan 2016 00:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 e4bOb4v_irRX; Tue, 12 Jan 2016 00:28:15 -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 094D81A1C06; Tue, 12 Jan 2016 00:28:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGS10806; Tue, 12 Jan 2016 08:28:10 +0000 (GMT) Received: from LHREML705-CAH.china.huawei.com (10.201.5.168) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 12 Jan 2016 08:28:09 +0000 Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 12 Jan 2016 08:28:10 +0000 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.185]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Tue, 12 Jan 2016 16:27:53 +0800 From: "Xialiang (Frank)" To: "draft-ietf-netconf-restconf.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-netconf-restconf-09 Thread-Index: AdFNEv/v0fWtOVGbSBOdzSCBJKdg7g== Date: Tue, 12 Jan 2016 08:27:53 +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_C02846B1344F344EB4FAA6FA7AF481F12AED7F4DSZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5694B91B.006D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.185, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8d0c2bc30af141861b8c9a8af925691f Archived-At: Cc: "iesg@ietf.org" , "secdir@ietf.org" Subject: [secdir] Secdir review of draft-ietf-netconf-restconf-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 08:28:19 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12AED7F4DSZXEMA502MBSchi_ 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 describes an HTTP-based protocol that provides a programmatic= interface for accessing data defined in YANG, using the datastores defined= in NETCONF. The document appears in reasonably good shape. In general, the RESTCONF is an application protocol layered on the HTTP pro= tocol. As mentioned in the document, just using the HTTPS (with TLS) can ad= dress most of the security issues such as confidentiality, integrity, etc. = In other words, RESTCONF is designed inherently based on a good security fo= undation. But there are still several security issues (TBDs) missing in the document = that need to be addressed before publication. Below is a series of my comments, questions for your consideration. Discussion: Section 2 Since this section is all about the security requirements to the RESTCONF t= ransport protocol, is it appropriate to combine it into the security consid= eration section directly? Questions: Section 4.3 What is the error handling if GET method is used to retrieve the operationa= l resources? Section 4.5 What is the error handing if PUT method does not include the message body? Generally, the similar problems like the above two appear several times in = the document, please double check them. Comments: Section 12 In the security considerations section, there are still some serious securi= ty issues not mentioned: 1. DDoS attack: One RESTCONF client is possible to communicate with a lot o= f RESTCONF servers, which potentially leads to the situation of DDoS attack= to itself or its link. How to avoid or mitigate it? 2. Replay attack: the attacker records a sequence of messages off the wire = and plays them back to the RESTCONF server/client. To protect against it, t= he common methods include using timestamp or sequence id. Questions: Section 12 1. "Security considerations for the content manipulated by RESTCONF can be = found in the documents defining data models.": which documents are mentione= d in this sentence for defining data models? 2. nits: "Implementors SHOULD provide a comprehensive authorization scheme = with...". Here, should "authorization" be "authentication"? Thank you. B.R. Frank --_000_C02846B1344F344EB4FAA6FA7AF481F12AED7F4DSZXEMA502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

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 pri= marily for the benefit of the security area directors.  Document editors and WG chairs should treat these comment= s just like any other last call comments.

 

 

This document describes an H= TTP-based protocol that provides a programmatic interface for accessing dat= a defined in YANG, using the datastores defined in NETCONF.

 

 

The document appears in reas= onably good shape.

 

In general, the RESTCONF is = an application protocol layered on the HTTP protocol. As mentioned in the d= ocument, just using the HTTPS (with TLS) can address most of the security i= ssues such as confidentiality, integrity, etc. In other words, RESTCONF is designed inherently based on a good secur= ity foundation.

 

But there are still several = security issues (TBDs) missing in the document that need to be addressed be= fore publication.

 

 

Below is a series of my comm= ents, questions for your consideration.

 

 

Discussion: Section 2

Since this section is all ab= out the security requirements to the RESTCONF transport protocol, is it app= ropriate to combine it into the security consideration section directly?

 

 

Questions:

Section 4.3

What is the error handling i= f GET method is used to retrieve the operational resources?

 

Section 4.5

What is the error handing if= PUT method does not include the message body?

 

Generally, the similar probl= ems like the above two appear several times in the document, please double = check them.

 

 

Comments: Section 12

In the security consideratio= ns section, there are still some serious security issues not mentioned:

1. DDoS attack: One RESTCONF= client is possible to communicate with a lot of RESTCONF servers, which po= tentially leads to the situation of DDoS attack to itself or its link. How = to avoid or mitigate it?

2. Replay attack: the attack= er records a sequence of messages off the wire and plays them back to the R= ESTCONF server/client. To protect against it, the common methods include us= ing timestamp or sequence id.

 

 

Questions: Section 12

1. "Security considerat= ions for the content manipulated by RESTCONF can be found in the documents = defining data models.": which documents are mentioned in this sentence= for defining data models?

2. nits: "Implementors = SHOULD provide a comprehensive authorization scheme with...". Here, sh= ould "authorization" be "authentication"?

 

 

Thank you.=

 

B.R.

Frank

 

--_000_C02846B1344F344EB4FAA6FA7AF481F12AED7F4DSZXEMA502MBSchi_-- From nobody Thu Jan 14 02:00:39 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC7D1B309F for ; Thu, 14 Jan 2016 02:00:38 -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 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 J2WE4-lcfg8V for ; Thu, 14 Jan 2016 02:00:36 -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 3DEFF1ACD13 for ; Thu, 14 Jan 2016 02:00:36 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u0EA0W2K020163 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 14 Jan 2016 12:00:32 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u0EA0VNu019106; Thu, 14 Jan 2016 12:00:31 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22167.29119.810344.837574@fireball.acr.fi> Date: Thu, 14 Jan 2016 12:00:31 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 14 Jan 2016 10:00:38 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Olafur Gudmundsson is next in the rotation. For telechat 2016-01-21 Reviewer LC end Draft Alan DeKok T 2016-01-18 draft-ietf-nfsv4-rfc3530-migration-update-07 Yoav Nir TR2015-12-14 draft-ietf-dnsop-cookies-09 Joe Salowey T 2015-12-21 draft-ietf-dnsop-edns-client-subnet-06 Carl Wallace T 2015-12-24 draft-ietf-ippm-active-passive-05 For telechat 2016-02-04 Daniel Kahn Gillmor T 2016-02-04 draft-mahesh-mef-urn-01 Sean Turner TR2015-09-01 draft-ietf-ntp-extension-field-06 Last calls and special requests: Derek Atkins 2016-01-18 draft-ietf-dnsop-edns-chain-query-05 Shaun Cooley 2016-01-15 draft-ietf-lisp-threats-14 Donald Eastlake 2016-01-18 draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-01 Daniel Kahn Gillmor E None draft-ietf-rtcweb-security-08 Tobias Gondrom 2016-01-27 draft-ietf-codec-oggopus-10 Jeffrey Hutzelman 2015-12-04 draft-ietf-core-block-18 Eric Osterweil 2016-01-05 draft-campbell-art-rfc5727-update-02 Hannes Tschofenig 2015-12-28 draft-ietf-hip-rfc5204-bis-07 Brian Weis E None draft-ietf-cdni-uri-signing-06 Tom Yu E None draft-ietf-netconf-yang-library-03 -- kivinen@iki.fi From nobody Sun Jan 17 10:45:11 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC981B3070 for ; Sun, 17 Jan 2016 10:45:08 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-rSDwye0w9Z for ; Sun, 17 Jan 2016 10:45:06 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::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 B02D41B306E for ; Sun, 17 Jan 2016 10:45:06 -0800 (PST) Received: by mail-qg0-x22f.google.com with SMTP id b35so413424818qge.0 for ; Sun, 17 Jan 2016 10:45:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware-com.20150623.gappssmtp.com; s=20150623; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version:content-type:content-transfer-encoding; bh=WwohYjZbrt8ME7FAbWepa/OMsC1hVJAh2PHGc/NZi0k=; b=0oWdCY79fPXYLoZt4Tm6f900wrlOhMS8lEawiena3C/btGe1CGX4MBbLBQ863OLqud lcBvJYEMID9jIB1uOIpaiay2mWi91n8LK+fSFdbpKSjmfdb8sesUkYu8xyskyTRMFf9s Mr6sb7ieFyfiSMIOb5vINudA308XcQieXQJtoBuSsAOOB9IK+CikRp4QsB79bjJI707J Z13NyaobFCkWAAUTC3z0yZQ3Wctdn74g7lwblvA0BxOdFDJrbR7/wNGpCXE/CvjQBk3a 8fCIrJ/3pzoEVkn0jLrlm4FEODP3ONlmn8tYWCjdtpX65qy5+KPrR0V1xLeLCQXfanK3 qeCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version:content-type:content-transfer-encoding; bh=WwohYjZbrt8ME7FAbWepa/OMsC1hVJAh2PHGc/NZi0k=; b=L5JWqlOA/tLFCtj5ABH7aJmW3Mgxki/GJiPGV569RzPlZQdRz1C49rb2QZslplob0K 4yr8n0KsKq5u3Leu+DmDnDGZj1savDv03Q4BNW8hdWimQgijR9ntpy5uUc5smBAT/lEp zyjFDNy6k2Z5aC9RjEtVNpm6UglDFIa+uTKck3o0JL2sVoXvYWgs84PEGFp107pDebiN uNuxpUYcDKOvoJwtFQKTJf1rCL5YA02p1p3TNjjzI26qVXyjGi2I3OopfI0LBXpDW0Ft CGhsqBHYb8rck/rZJiC355HwmwGMqJkj/X7Zyfe1jIxwGtYh2JCvC+rRIfpb8yNvpKCA YWAg== X-Gm-Message-State: ALoCoQnbZoGpfyHtziQ8+GVpxpvSnAwyzttP5/ZIsq0I9Ka2W+Q56S2NEzga4ztsAhltBZIyfMEts/Luc0B+QTgL8vYMChRWfQ== X-Received: by 10.140.25.149 with SMTP id 21mr27164948qgt.89.1453056305856; Sun, 17 Jan 2016 10:45:05 -0800 (PST) Received: from [192.168.2.27] (pool-173-66-90-83.washdc.fios.verizon.net. [173.66.90.83]) by smtp.gmail.com with ESMTPSA id e11sm8670073qkb.39.2016.01.17.10.44.55 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jan 2016 10:45:05 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.5.8.151023 Date: Sun, 17 Jan 2016 13:44:49 -0500 From: Carl Wallace To: Message-ID: Thread-Topic: secdir review of draft-ietf-ippm-active-passive-05 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Cc: "iesg@ietf.org" , "secdir@ietf.org" Subject: [secdir] secdir review of draft-ietf-ippm-active-passive-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 18:45:08 -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 draft aims to provide clear definitions for Active and Passive performance assessment as well as defining Hybrid methods and establishing means of evaluating new methods as they emerge. The document relies heavily on textual references to other specifications, which can at times be a bit tedious for the reader but I have no particular suggestions regarding this point and it's probably fine for a document that is aiming to corral various earlier concepts. The referenced security and privacy considerations were very good (if nearly as long as this spec itself). One minor point, section 4.2 might be better placed before the current section 4.1 to better set-up the ASCII art in section 4.1. From nobody Wed Jan 20 08:28:47 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5D31A90C5 for ; Wed, 20 Jan 2016 08:28:43 -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, SPF_PASS=-0.001] autolearn=ham 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 EMOqhdq5H_Ak for ; Wed, 20 Jan 2016 08:28:42 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d: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 14B281A90BB for ; Wed, 20 Jan 2016 08:28:42 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id s68so4988017qkh.3 for ; Wed, 20 Jan 2016 08:28:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=glS3oRojr+SADHR1a3C89wxo4UpV2E5UObpHL+wkJKw=; b=gVWcqhm/pnTtg8hSJmZyW8miffQ1h7bFJfu0zl+65mtDRFt+u2xQb4UktGrOAun/HF Vn5h6jAFa/qsFQMck1F0Gi5TdJGv5TpJTNv7yxXLNuyXyagzh9AMWyyVsUS1q+Gi7g6p AgbjmffTU7JeUCVHrMOTR8rJyNtj5Dmo0nfIA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=glS3oRojr+SADHR1a3C89wxo4UpV2E5UObpHL+wkJKw=; b=TYJ+UCafXlahN2y2yMDCwBLMn3XDtaeFXKa2hE4rda/CrBGbe5ycQiRxoqssw1N8Z9 0CCnoH4bOclXfnzeOpe2A0og9gCUB2cvlhE1NZJf6yhlDuCG6tEHTtdQOf7V2YGYyjnx z/rpxMZ6FDpjqtTshU1k3DMP1dSota3Eh6i5RBj5X8SGvBP6wHVrfIoyZblZx7het2Yw 0QRL2MKXOp/nGPC5rP+ZQw8IKj26nol+gtAYAwMFe+RAGhdhoEeJnz5HJUcdLnqptr38 sqXud7LU+rYQOVqkwTDhho6403puXv+luDUbND4f/UkuMQDhDa4Ckcq+X9wkOqTW8Rk2 IwnA== X-Gm-Message-State: ALoCoQlFiaA2v/+cjbneHQ3/aIVkX8LNWuHbVSQOCNhtjCCKlXWF9VI3suVpRJ7/+RPerC/Rgui4JDlot2IySFEyY/6xJtvk/A== X-Received: by 10.55.31.9 with SMTP id f9mr46746024qkf.5.1453307321230; Wed, 20 Jan 2016 08:28:41 -0800 (PST) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id f66sm14629159qkb.5.2016.01.20.08.28.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jan 2016 08:28:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Sean Turner In-Reply-To: <2205089A-4961-4582-824F-C21138775DC8@sn3rd.com> Date: Wed, 20 Jan 2016 11:28:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <86BDAD7D-485D-497F-B76A-6069D449F0AD@sn3rd.com> References: <20151101165448.18272.29225.idtracker@ietfa.amsl.com> <2205089A-4961-4582-824F-C21138775DC8@sn3rd.com> To: The IESG , draft-ietf-ntp-extension-field.all@ietf.org, secdir@ietf.org X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [secdir] secdir review of Re: I-D Action: draft-ietf-ntp-extension-field-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 16:28:43 -0000 Status: ready for launch Version 6 introduced additional text for the security considerations = section, which I like. spt > On Nov 02, 2015, at 03:52, Sean Turner wrote: >=20 > This version addresses my main concerns. >=20 > Not sure what you=E2=80=99re going to do with this though, but I guess = that another draft=E2=80=99s problem: >=20 >> On Sep 17, 2015, at 02:02, Danny Mayer = wrote: >>=20 >> We probably need to update the dgest field in RFC5905 to make it = clear >> that it can have multiple lengths depending on the algorithm used. On >> the other hand I would prefer to get rid of the MAC and turn it into = an >> extension field, assuming that the NTS/CMS scheme is not used. The >> advantages of that is obvious especially as no guessing would be >> required and we could specify the algorithm to use and you could have >> multiple MAC extension fields that would cover different parts of the >> packet. >=20 > spt From nobody Wed Jan 20 08:44:06 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8FC1A90FA; Wed, 20 Jan 2016 08:44:02 -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, SPF_PASS=-0.001] autolearn=ham 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 fGqiokCDFZ6q; Wed, 20 Jan 2016 08:44:00 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002: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 BB1421A90CA; Wed, 20 Jan 2016 08:44:00 -0800 (PST) Received: by mail-yk0-x22f.google.com with SMTP id x67so16282705ykd.2; Wed, 20 Jan 2016 08:44:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=thYvRdDEGKmaEx4yt+EWXnQ4abBjxVY/iYPCPK8aTPg=; b=YvdKdCGw3mVrEyhyhRNQFU07VaR53e7aE4PKmmDpBWRmlhugAhkf06mbMJEfuyDr8I 9EJbbQ+YUu9Cg7NA4tV30fnnv6pND6yrmldP5y4OYZpavwAyleTUgbCRgo+1E6PlxoS8 apSMcK/DCQLr1dySU9Yf6mh/cZjCqyI9GHlBmTGiK3V4kVpslEkyXxUZSmq1eczc1T8H 5r4E2Z5pxZwUnkM3G3QJ3eqxP2nUKc4hZx8f+V2sdxxf5yCM7Hfvy8DPd6F9WMxpHpa8 H2wb402ESUo21uotFgUsQrpSLqyI9xSk8KqQ/nwalZ5sfqzR4S0wKVDJ0MSWSsA/8KvO iTAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=thYvRdDEGKmaEx4yt+EWXnQ4abBjxVY/iYPCPK8aTPg=; b=No8gIyoCKvuKc5ma/He6Wj8cZSAuUkidAIngaxi2k6hf8dMKtMhcLR7jhCz/Pra6HI NzYJ60SNASu7nHgc7woJwaJzJLvt3swhB5qy/ymTH8D5yWpSAO6IwjX8c+mHb+J7rQrd UCnRp8mT3QrY/N62b+ySJidHOddLYukzDA9oYxyvipj8NdIev9vTtKsGTaHGBwEvzJ/s LDV26PmzMgvWRRa2hr4HLAOkPBHZIuo9hTZKKkdlMc0hnHdfuqhtp5QVQw/48PbIDHCc yAGrNqxWGAz9yq1eTOvrYF9fHVBbtfJpMpGB2U5BhNqJhM2bTSPVPfObbf8tFaQO0B1U RrnA== X-Gm-Message-State: ALoCoQmoj6kuUXkcsK6HIJeTdFLJ+vNyi6uovvGDZhjt3pT2vDZFQpyWnqedXoieqFOqvXIWxjkQV9jwP/OItkRc/FwhDa3H/A== MIME-Version: 1.0 X-Received: by 10.13.210.7 with SMTP id u7mr21120704ywd.100.1453308240054; Wed, 20 Jan 2016 08:44:00 -0800 (PST) Received: by 10.37.99.65 with HTTP; Wed, 20 Jan 2016 08:44:00 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Jan 2016 10:44:00 -0600 Message-ID: From: Spencer Dawkins at IETF To: Carl Wallace Content-Type: multipart/alternative; boundary=001a114e7e7865ed930529c6b1de Archived-At: Cc: "secdir@ietf.org" , draft-ietf-ippm-active-passive.all@tools.ietf.org, "iesg@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-ippm-active-passive-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 16:44:02 -0000 --001a114e7e7865ed930529c6b1de Content-Type: text/plain; charset=UTF-8 Hi, Carl, On Sun, Jan 17, 2016 at 12:44 PM, Carl Wallace 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 draft aims to provide clear definitions for Active and Passive > performance assessment as well as defining Hybrid methods and establishing > means of evaluating new methods as they emerge. The document relies > heavily on textual references to other specifications, which can at times > be a bit tedious for the reader but I have no particular suggestions > regarding this point and it's probably fine for a document that is aiming > to corral various earlier concepts. The referenced security and privacy > considerations were very good (if nearly as long as this spec itself). One > minor point, section 4.2 might be better placed before the current section > 4.1 to better set-up the ASCII art in section 4.1. > Thanks for the review! Could the authors let me know if the 4.1/4.2 section switch should happen? No need to submit a revision about that until after the telechat tomorrow, if the answer is "yes". Spencer --001a114e7e7865ed930529c6b1de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Carl,

On Sun, Jan 17, 2016 at 12:44 PM, Carl Wallace &= lt;carl@redh= oundsoftware.com> 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<= br> directors.=C2=A0 Document editors and WG chairs should treat these comments=
just like any other last call comments.

This draft aims to provide clear definitions for Active and Passive
performance assessment as well as defining Hybrid methods and establishing<= br> means of evaluating new methods as they emerge. The document relies
heavily on textual references to other specifications, which can at times be a bit tedious for the reader but I have no particular suggestions
regarding this point and it's probably fine for a document that is aimi= ng
to corral various earlier concepts. The referenced security and privacy
considerations were very good (if nearly as long as this spec itself). One<= br> minor point, section 4.2 might be better placed before the current section<= br> 4.1 to better set-up the ASCII art in section 4.1.
Thanks for the review!

Could the autho= rs let me know if the 4.1/4.2 section switch should happen? No need to subm= it a revision about that until after the telechat tomorrow, if the answer i= s "yes".

Spencer=C2=A0
=
--001a114e7e7865ed930529c6b1de-- From nobody Wed Jan 20 09:04:49 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03251A9121; Wed, 20 Jan 2016 09:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham 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 WzISw9FjIGJa; Wed, 20 Jan 2016 09:04:45 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 732271A8AEB; Wed, 20 Jan 2016 09:04:45 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id C98A412057F; Wed, 20 Jan 2016 12:05:31 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id 3DE4BE0118; Wed, 20 Jan 2016 12:00:30 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Wed, 20 Jan 2016 12:03:26 -0500 From: "MORTON, ALFRED C (AL)" To: Spencer Dawkins at IETF , Carl Wallace Date: Wed, 20 Jan 2016 12:03:24 -0500 Thread-Topic: secdir review of draft-ietf-ippm-active-passive-05 Thread-Index: AdFTodKWmjZaTNGiT5GxbyHbet1buQAAU8Ng Message-ID: <4AF73AA205019A4C8A1DDD32C034631D2E26B7CF97@NJFPSRVEXG0.research.att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4AF73AA205019A4C8A1DDD32C034631D2E26B7CF97NJFPSRVEXG0re_" MIME-Version: 1.0 Archived-At: Cc: "secdir@ietf.org" , "draft-ietf-ippm-active-passive.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-ippm-active-passive-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 17:04:47 -0000 --_000_4AF73AA205019A4C8A1DDD32C034631D2E26B7CF97NJFPSRVEXG0re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2FybCwgdGhhbmtzIGZvciB5b3VyIHJldmlldy4NCg0KQ2FybCBhbmQgU3BlbmNlciwNCg0K SSB0aGluayB0aGUgaXNzdWUgaXMgdGhhdCDigJxQRE3igJ0gYXBwZWFycyBpbiB0aGUNCihBU0NJ SSBBcnQpIEZpZ3VyZSBpbiBzZWN0aW9uIDQuMSwNCndpdGhvdXQgZXhwbGFpbmluZyB3aGF0IFBE TSBpcyAodGhhdCBoYXBwZW5zIGluIDQuMikuDQpUaGUgYWx0ZXJuYXRpdmUgaXMgdG8gZXhwYW5k IGEgYml0IG9uIFBETSBpbiB0aGUgZXhwbGFuYXRpb24NCm9mIHRoZSBGaWd1cmUgaW4gNC4xLiAg VGhpcyB3YXkgd2UgY2FuIGxlYXZlIGFsbCB0aGUNCm1ldGhvZHMgdG9nZXRoZXIgZm9sbG93aW5n IHRoZSA0LjEgR3JhcGhpY2FsIFJlcHJlc2VudGF0aW9uDQpzZWN0aW9uICh3aXRoIHRoZSBBU0NJ SSBhcnQpLg0KDQogICA0PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlw cG0tYWN0aXZlLXBhc3NpdmUtMDUjc2VjdGlvbi00Pi4gIERpc2N1c3Npb24gIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4PGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0tYWN0aXZlLXBhc3NpdmUtMDUjcGFnZS04Pg0K ICAgICA0LjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXBwbS1hY3Rp dmUtcGFzc2l2ZS0wNSNzZWN0aW9uLTQuMT4uICBHcmFwaGljYWwgUmVwcmVzZW50YXRpb24gIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWlwcG0tYWN0aXZlLXBhc3NpdmUtMDUjcGFnZS04Pg0KICAgICA0LjI8 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXBwbS1hY3RpdmUtcGFzc2l2 ZS0wNSNzZWN0aW9uLTQuMj4uICBEaXNjdXNzaW9uIG9mIFBETSAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWlwcG0tYWN0aXZlLXBhc3NpdmUtMDUjcGFnZS0xMD4NCiAgICAgNC4zPGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0tYWN0aXZlLXBhc3NpdmUtMDUjc2Vj dGlvbi00LjM+LiAgRGlzY3Vzc2lvbiBvZiAiQ29sb3JpbmciIE1ldGhvZCAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAxMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1p cHBtLWFjdGl2ZS1wYXNzaXZlLTA1I3BhZ2UtMTE+DQogICAgIDQuNDxodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHBtLWFjdGl2ZS1wYXNzaXZlLTA1I3NlY3Rpb24tNC40 Pi4gIEJyaWVmIERpc2N1c3Npb24gb2YgT0FNIE1ldGhvZHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXBwbS1hY3Rp dmUtcGFzc2l2ZS0wNSNwYWdlLTExPg0KDQpPaz8NCkFsDQoNCg0KRnJvbTogU3BlbmNlciBEYXdr aW5zIGF0IElFVEYgW21haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbV0NClNlbnQ6 IFdlZG5lc2RheSwgSmFudWFyeSAyMCwgMjAxNiAxMTo0NCBBTQ0KVG86IENhcmwgV2FsbGFjZQ0K Q2M6IGRyYWZ0LWlldGYtaXBwbS1hY3RpdmUtcGFzc2l2ZS5hbGxAdG9vbHMuaWV0Zi5vcmc7IGll c2dAaWV0Zi5vcmc7IHNlY2RpckBpZXRmLm9yZw0KU3ViamVjdDogUmU6IHNlY2RpciByZXZpZXcg b2YgZHJhZnQtaWV0Zi1pcHBtLWFjdGl2ZS1wYXNzaXZlLTA1DQoNCkhpLCBDYXJsLA0KDQpPbiBT dW4sIEphbiAxNywgMjAxNiBhdCAxMjo0NCBQTSwgQ2FybCBXYWxsYWNlIDxjYXJsQHJlZGhvdW5k c29mdHdhcmUuY29tPG1haWx0bzpjYXJsQHJlZGhvdW5kc29mdHdhcmUuY29tPj4gd3JvdGU6DQpJ IGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJl Y3RvcmF0ZSdzDQpvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJl aW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4NClRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBw cmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhDQpkaXJlY3RvcnMu ICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1l bnRzDQpqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0KVGhpcyBkcmFm dCBhaW1zIHRvIHByb3ZpZGUgY2xlYXIgZGVmaW5pdGlvbnMgZm9yIEFjdGl2ZSBhbmQgUGFzc2l2 ZQ0KcGVyZm9ybWFuY2UgYXNzZXNzbWVudCBhcyB3ZWxsIGFzIGRlZmluaW5nIEh5YnJpZCBtZXRo b2RzIGFuZCBlc3RhYmxpc2hpbmcNCm1lYW5zIG9mIGV2YWx1YXRpbmcgbmV3IG1ldGhvZHMgYXMg dGhleSBlbWVyZ2UuIFRoZSBkb2N1bWVudCByZWxpZXMNCmhlYXZpbHkgb24gdGV4dHVhbCByZWZl cmVuY2VzIHRvIG90aGVyIHNwZWNpZmljYXRpb25zLCB3aGljaCBjYW4gYXQgdGltZXMNCmJlIGEg Yml0IHRlZGlvdXMgZm9yIHRoZSByZWFkZXIgYnV0IEkgaGF2ZSBubyBwYXJ0aWN1bGFyIHN1Z2dl c3Rpb25zDQpyZWdhcmRpbmcgdGhpcyBwb2ludCBhbmQgaXQncyBwcm9iYWJseSBmaW5lIGZvciBh IGRvY3VtZW50IHRoYXQgaXMgYWltaW5nDQp0byBjb3JyYWwgdmFyaW91cyBlYXJsaWVyIGNvbmNl cHRzLiBUaGUgcmVmZXJlbmNlZCBzZWN1cml0eSBhbmQgcHJpdmFjeQ0KY29uc2lkZXJhdGlvbnMg d2VyZSB2ZXJ5IGdvb2QgKGlmIG5lYXJseSBhcyBsb25nIGFzIHRoaXMgc3BlYyBpdHNlbGYpLiBP bmUNCm1pbm9yIHBvaW50LCBzZWN0aW9uIDQuMiBtaWdodCBiZSBiZXR0ZXIgcGxhY2VkIGJlZm9y ZSB0aGUgY3VycmVudCBzZWN0aW9uDQo0LjEgdG8gYmV0dGVyIHNldC11cCB0aGUgQVNDSUkgYXJ0 IGluIHNlY3Rpb24gNC4xLg0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXchDQoNCkNvdWxkIHRoZSBh dXRob3JzIGxldCBtZSBrbm93IGlmIHRoZSA0LjEvNC4yIHNlY3Rpb24gc3dpdGNoIHNob3VsZCBo YXBwZW4/IE5vIG5lZWQgdG8gc3VibWl0IGEgcmV2aXNpb24gYWJvdXQgdGhhdCB1bnRpbCBhZnRl ciB0aGUgdGVsZWNoYXQgdG9tb3Jyb3csIGlmIHRoZSBhbnN3ZXIgaXMgInllcyIuDQoNClNwZW5j ZXINCg== --_000_4AF73AA205019A4C8A1DDD32C034631D2E26B7CF97NJFPSRVEXG0re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bh bi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVl IHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtj b2xvcjpibGFjayc+SGkgQ2FybCwgdGhhbmtzIGZvciB5b3VyIHJldmlldy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+Q2FybCBhbmQgU3BlbmNl ciwgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2sn PkkgdGhpbmsgdGhlIGlzc3VlIGlzIHRoYXQg4oCcUERN4oCdIGFwcGVhcnMgaW4gdGhlIDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+KEFTQ0lJIEFy dCkgRmlndXJlIGluIHNlY3Rpb24gNC4xLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijtjb2xvcjpibGFjayc+d2l0aG91dCBleHBsYWluaW5nIHdoYXQgUERNIGlzICh0aGF0 IGhhcHBlbnMgaW4gNC4yKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 Y29sb3I6YmxhY2snPlRoZSBhbHRlcm5hdGl2ZSBpcyB0byBleHBhbmQgYSBiaXQgb24gUERNIGlu IHRoZSBleHBsYW5hdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtj b2xvcjpibGFjayc+b2YgdGhlIEZpZ3VyZSBpbiA0LjEuwqAgVGhpcyB3YXkgd2UgY2FuIGxlYXZl IGFsbCB0aGUgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJs YWNrJz5tZXRob2RzIHRvZ2V0aGVyIGZvbGxvd2luZyB0aGUgNC4xIEdyYXBoaWNhbCBSZXByZXNl bnRhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFj ayc+c2VjdGlvbiAod2l0aCB0aGUgQVNDSUkgYXJ0KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+wqDCoCA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1pcHBtLWFjdGl2ZS1wYXNzaXZlLTA1I3NlY3Rpb24tNCI+NDwvYT4uwqAg RGlzY3Vzc2lvbsKgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC7CoMKgIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWlwcG0tYWN0aXZlLXBhc3NpdmUtMDUjcGFnZS04Ij44PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDCoMKgwqAgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtaXBwbS1hY3RpdmUtcGFzc2l2ZS0wNSNzZWN0aW9uLTQuMSI+ NC4xPC9hPi7CoCBHcmFwaGljYWwgUmVwcmVzZW50YXRpb27CoCAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuwqDCoCA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1pcHBtLWFjdGl2ZS1wYXNzaXZlLTA1I3BhZ2UtOCI+ODwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqDCoMKgIDxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0tYWN0aXZlLXBhc3NpdmUtMDUjc2VjdGlv bi00LjIiPjQuMjwvYT4uwqAgRGlzY3Vzc2lvbiBvZiBQRE0gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuwqAgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtaXBwbS1hY3RpdmUtcGFzc2l2ZS0wNSNwYWdlLTEwIj4xMDwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgIMKgwqDCoDxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0tYWN0aXZlLXBhc3NpdmUtMDUj c2VjdGlvbi00LjMiPjQuMzwvYT4uwqAgRGlzY3Vzc2lvbiBvZiAmcXVvdDtDb2xvcmluZyZxdW90 OyBNZXRob2QgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLsKgIDxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0tYWN0aXZlLXBhc3NpdmUtMDUjcGFnZS0x MSI+MTE8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz7CoMKgwqDC oCA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHBtLWFj dGl2ZS1wYXNzaXZlLTA1I3NlY3Rpb24tNC40Ij40LjQ8L2E+LsKgIEJyaWVmIERpc2N1c3Npb24g b2YgT0FNIE1ldGhvZHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLsKgIDxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0tYWN0aXZlLXBhc3NpdmUtMDUj cGFnZS0xMSI+MTE8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2Nv bG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 Y29sb3I6YmxhY2snPk9rPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtj b2xvcjpibGFjayc+QWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29s b3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtj b2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxi PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRG IFttYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb21dIDxicj48Yj5TZW50OjwvYj4g V2VkbmVzZGF5LCBKYW51YXJ5IDIwLCAyMDE2IDExOjQ0IEFNPGJyPjxiPlRvOjwvYj4gQ2FybCBX YWxsYWNlPGJyPjxiPkNjOjwvYj4gZHJhZnQtaWV0Zi1pcHBtLWFjdGl2ZS1wYXNzaXZlLmFsbEB0 b29scy5pZXRmLm9yZzsgaWVzZ0BpZXRmLm9yZzsgc2VjZGlyQGlldGYub3JnPGJyPjxiPlN1Ympl Y3Q6PC9iPiBSZTogc2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWlwcG0tYWN0aXZlLXBhc3Np dmUtMDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkhpLCBDYXJsLDxv OnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIFN1biwgSmFuIDE3LCAyMDE2IGF0IDEyOjQ0IFBN LCBDYXJsIFdhbGxhY2UgJmx0OzxhIGhyZWY9Im1haWx0bzpjYXJsQHJlZGhvdW5kc29mdHdhcmUu Y29tIiB0YXJnZXQ9Il9ibGFuayI+Y2FybEByZWRob3VuZHNvZnR3YXJlLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5JIGhhdmUgcmV2aWV3ZWQgdGhp cyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzPGJyPm9uZ29p bmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5 IHRoZSBJRVNHLjxicj5UaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0 aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYTxicj5kaXJlY3RvcnMuJm5ic3A7IERvY3Vt ZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHM8YnI+ anVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPGJyPjxicj5UaGlzIGRyYWZ0 IGFpbXMgdG8gcHJvdmlkZSBjbGVhciBkZWZpbml0aW9ucyBmb3IgQWN0aXZlIGFuZCBQYXNzaXZl PGJyPnBlcmZvcm1hbmNlIGFzc2Vzc21lbnQgYXMgd2VsbCBhcyBkZWZpbmluZyBIeWJyaWQgbWV0 aG9kcyBhbmQgZXN0YWJsaXNoaW5nPGJyPm1lYW5zIG9mIGV2YWx1YXRpbmcgbmV3IG1ldGhvZHMg YXMgdGhleSBlbWVyZ2UuIFRoZSBkb2N1bWVudCByZWxpZXM8YnI+aGVhdmlseSBvbiB0ZXh0dWFs IHJlZmVyZW5jZXMgdG8gb3RoZXIgc3BlY2lmaWNhdGlvbnMsIHdoaWNoIGNhbiBhdCB0aW1lczxi cj5iZSBhIGJpdCB0ZWRpb3VzIGZvciB0aGUgcmVhZGVyIGJ1dCBJIGhhdmUgbm8gcGFydGljdWxh ciBzdWdnZXN0aW9uczxicj5yZWdhcmRpbmcgdGhpcyBwb2ludCBhbmQgaXQncyBwcm9iYWJseSBm aW5lIGZvciBhIGRvY3VtZW50IHRoYXQgaXMgYWltaW5nPGJyPnRvIGNvcnJhbCB2YXJpb3VzIGVh cmxpZXIgY29uY2VwdHMuIFRoZSByZWZlcmVuY2VkIHNlY3VyaXR5IGFuZCBwcml2YWN5PGJyPmNv bnNpZGVyYXRpb25zIHdlcmUgdmVyeSBnb29kIChpZiBuZWFybHkgYXMgbG9uZyBhcyB0aGlzIHNw ZWMgaXRzZWxmKS4gT25lPGJyPm1pbm9yIHBvaW50LCBzZWN0aW9uIDQuMiBtaWdodCBiZSBiZXR0 ZXIgcGxhY2VkIGJlZm9yZSB0aGUgY3VycmVudCBzZWN0aW9uPGJyPjQuMSB0byBiZXR0ZXIgc2V0 LXVwIHRoZSBBU0NJSSBhcnQgaW4gc2VjdGlvbiA0LjEuPG86cD48L286cD48L3A+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+VGhhbmtzIGZvciB0aGUgcmV2aWV3ITxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPkNvdWxkIHRoZSBhdXRob3JzIGxldCBtZSBrbm93IGlmIHRoZSA0LjEvNC4y IHNlY3Rpb24gc3dpdGNoIHNob3VsZCBoYXBwZW4/IE5vIG5lZWQgdG8gc3VibWl0IGEgcmV2aXNp b24gYWJvdXQgdGhhdCB1bnRpbCBhZnRlciB0aGUgdGVsZWNoYXQgdG9tb3Jyb3csIGlmIHRoZSBh bnN3ZXIgaXMgJnF1b3Q7eWVzJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPlNwZW5jZXImbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rp dj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_4AF73AA205019A4C8A1DDD32C034631D2E26B7CF97NJFPSRVEXG0re_-- From nobody Wed Jan 20 09:10:49 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A271A916F for ; Wed, 20 Jan 2016 09:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 Rw81D1J4JQ9E for ; Wed, 20 Jan 2016 09:10:44 -0800 (PST) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (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 5BF5D1A916D for ; Wed, 20 Jan 2016 09:10:44 -0800 (PST) Received: by mail-qg0-x234.google.com with SMTP id e32so11195165qgf.3 for ; Wed, 20 Jan 2016 09:10:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware-com.20150623.gappssmtp.com; s=20150623; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-type; bh=vtceMqR7rt2w/feWNHSywNZzwSXV5Y91zw9BMNd4tbI=; b=iLfueJdpszFxR38KgocYaMoG2KzYqBxWmlXqkjBWHyD4Yj9DSS7liDHNFAqxNkxZ78 hrIVIGEjtaIbGSse9Zmcl8JvPAU3xrSoljVZQIe7F/S+I48rxGrJtTqZiyxxXw/UURtD Rle5lRoc9sZnxeu6ztfVoxrQViukWb0G/FRMgK2VgHYWVSyh4FZST+ZTeZCRO0rigkFR S0VQNB3BAo9UT3KrPHo3mBcd1Lu0/S+J9czckMvOA5CG5DlBRybjtqgAnWt/sjrfhLOO +nOfH7XUzQ28FMZYGHCMmYHU8ZLBTnNJ9V4j5+cCMcn/ckFDc2U7vLQyadzqgDa6Yqx5 oE+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type; bh=vtceMqR7rt2w/feWNHSywNZzwSXV5Y91zw9BMNd4tbI=; b=LS/q37LdtBmEZWCv0FBibVO7du6pzACd+gf5clbAtZXAQWYI1lr7rCfy20kOgVl4GO qzKBWCqQ6x54acc5bo+ikS8uNtcv4Pm2iN0ySEk+/d9LOpkXpBZ9+Mp545B7UpuU/hJO qr2nNilnPJaUmWtr8gcVMaXTBlhSHMrXp3PU8TQih/HK7E1SzIZF7FZnyx8pt3GstrUo GvWb8RkshZtvwINC+dDW4Yad5/2gFNxVleWISrvjj4xGxLYAw2By5TSYrViHu6WsUMPS AGrFhnrhzi8jqb6iJ4ML/0b4WZ9QmYWbITKjhGg5odUL1hfBOoRTWaFX004Ph7VqLdFR cRpA== X-Gm-Message-State: ALoCoQngEEZe7V7KDAxFr5tYpwXLN7ZfrUGsflPJlyZKp1gvpiAC2717XzHVd8OWqxgs4vzlntC4aYlDpR/IqH6yQamHsFyDUg== X-Received: by 10.140.132.212 with SMTP id 203mr47860370qhe.102.1453309843441; Wed, 20 Jan 2016 09:10:43 -0800 (PST) Received: from [172.24.81.185] ([38.104.28.110]) by smtp.gmail.com with ESMTPSA id 67sm14578973qht.14.2016.01.20.09.10.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jan 2016 09:10:42 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.5.8.151023 Date: Wed, 20 Jan 2016 12:10:25 -0500 From: Carl Wallace To: "MORTON, ALFRED C (AL)" , Spencer Dawkins at IETF Message-ID: Thread-Topic: secdir review of draft-ietf-ippm-active-passive-05 References: <4AF73AA205019A4C8A1DDD32C034631D2E26B7CF97@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D2E26B7CF97@NJFPSRVEXG0.research.att.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3536136637_22215561" Archived-At: Cc: "secdir@ietf.org" , "draft-ietf-ippm-active-passive.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-ippm-active-passive-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 17:10:48 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3536136637_22215561 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Works for me. From: "MORTON, ALFRED C (AL)" Date: Wednesday, January 20, 2016 at 12:03 PM To: Spencer Dawkins at IETF , Carl Wallace Cc: "draft-ietf-ippm-active-passive.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: RE: secdir review of draft-ietf-ippm-active-passive-05 > Hi Carl, thanks for your review. > =20 > Carl and Spencer, > =20 > I think the issue is that =E2=80=9CPDM=E2=80=9D appears in the > (ASCII Art) Figure in section 4.1, > without explaining what PDM is (that happens in 4.2). > The alternative is to expand a bit on PDM in the explanation > of the Figure in 4.1. This way we can leave all the > methods together following the 4.1 Graphical Representation > section (with the ASCII art). > =20 > 4 > . Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8 > > 4.1=20 > . > Graphical Representation . . . . . . . . . . . . . . . . 8 > > 4.2=20 > . > Discussion of PDM . . . . . . . . . . . . . . . . . . . . 10 > > 4.3=20 > . > Discussion of "Coloring" Method . . . . . . . . . . . . . 11 > > 4.4=20 > . > Brief Discussion of OAM Methods . . . . . . . . . . . . . 11 > > =20 > Ok? > Al > =20 > =20 >=20 > From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] > Sent: Wednesday, January 20, 2016 11:44 AM > To: Carl Wallace > Cc: draft-ietf-ippm-active-passive.all@tools.ietf.org; iesg@ietf.org; > secdir@ietf.org > Subject: Re: secdir review of draft-ietf-ippm-active-passive-05 > =20 >=20 > Hi, Carl, >=20 > =20 >=20 > On Sun, Jan 17, 2016 at 12:44 PM, Carl Wallace > 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 are= a > directors. Document editors and WG chairs should treat these comments > just like any other last call comments. >=20 > This draft aims to provide clear definitions for Active and Passive > performance assessment as well as defining Hybrid methods and establishin= g > means of evaluating new methods as they emerge. The document relies > heavily on textual references to other specifications, which can at times > be a bit tedious for the reader but I have no particular suggestions > regarding this point and it's probably fine for a document that is aiming > to corral various earlier concepts. The referenced security and privacy > considerations were very good (if nearly as long as this spec itself). On= e > minor point, section 4.2 might be better placed before the current sectio= n > 4.1 to better set-up the ASCII art in section 4.1. >=20 > =20 >=20 > Thanks for the review! >=20 > =20 >=20 > Could the authors let me know if the 4.1/4.2 section switch should happen= ? No > need to submit a revision about that until after the telechat tomorrow, i= f the > answer is "yes". >=20 > =20 >=20 > Spencer=20 --B_3536136637_22215561 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Works for me.

<= /div>
From: "MORTON, ALFRED C (AL)" <<= a href=3D"mailto:acmorton@att.com">acmorton@att.com>
Date: Wednesday, January 20, 2016 at 12:03 PM
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>= , Carl Wallace <carl@redhounds= oftware.com>
Cc: "draft-ietf-ippm-ac= tive-passive.all@tools.ietf.org" <draft-ietf-ippm-active-passive.all@tools.iet= f.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.= org>
Subject: RE: secdir re= view of draft-ietf-ippm-active-passive-05

Hi Carl, thanks for your rev= iew.

 

Carl and Spencer,

<= span style=3D"font-size: 11pt; font-family: 'Courier New'; color: black;"> 

I think the issue is that “P= DM” appears in the

(ASCII Art)= Figure in section 4.1,

without expla= ining what PDM is (that happens in 4.2).

The alternative is to expand a bit on PDM in the explanation<= /span>

of the Figure in 4.1.  This way we can leav= e all the

methods together following= the 4.1 Graphical Representation

= sec= tion (with the ASCII art).

 = ;

   4.  Discussion  . . .= . . . . . . . . . . . . . . . . . . . . . .   8=

     4.1.  Graphical Rep= resentation  . . . . . . . . . . . . . . . .   8<= /o:p>

     4.2.  Discussi= on of PDM . . . . . . . . . . . . . . . . . . . .  10

     4.3.  Discussion o= f "Coloring" Method . . . . . . . . . . . . .  11

     4.4.  Brief Discussion= of OAM Methods . . . . . . . . . . . . .  11=

 

Ok?=

Al

 

 

<= div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0p= t">

From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com]
= Sent: Wednesday, January 20, 2016 11:44 AM
To: Carl WallaceCc: draft-ietf-ippm-active-passive.all@tools.ietf.org; iesg@ietf.org; secdir@ietf= .org
Subject: Re: secdir review of draft-ietf-ippm-active-pass= ive-05

 

Hi, Carl,

 

On Sun, Jan 17, 2016 at= 12:44 PM, Carl Wallace <carl@redhoundsoftware.com> wrote:

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

This draft aims to= provide clear definitions for Active and Passive
performance assessment = as well as defining Hybrid methods and establishing
means of evaluating n= ew methods as they emerge. The document relies
heavily on textual referen= ces to other specifications, which can at times
be a bit tedious for the = reader but I have no particular suggestions
regarding this point and it's= probably fine for a document that is aiming
to corral various earlier co= ncepts. The referenced security and privacy
considerations were very good= (if nearly as long as this spec itself). One
minor point, section 4.2 mi= ght be better placed before the current section
4.1 to better set-up the = ASCII art in section 4.1.

 = ;

Thanks for the review!=

 

Could the authors let me know if the 4.1/4.2 section switch sho= uld happen? No need to submit a revision about that until after the telechat= tomorrow, if the answer is "yes".

 

Spencer =

--B_3536136637_22215561-- From nobody Thu Jan 21 05:12:47 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4C81B30F8; Thu, 21 Jan 2016 05:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 ew9T6zqimzpl; Thu, 21 Jan 2016 05:12:43 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338DE1B30F6; Thu, 21 Jan 2016 05:12:43 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id r129so171638081wmr.0; Thu, 21 Jan 2016 05:12:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=K4omoXovJEzeGfzZZ5YLcw9cEy19X5ID8l3xwZaT/3M=; b=ojhNzojVMFWYyVs3WdTaV4BjNLFD3efpMsJuQMsiaz1Jp7FVZRxeiJfn9+ZSaKaPoL TL9KddSVClObCuIqLNtb/Fv/e2c8N2A5uoU6PsF94MVH5gYxaI+zLbm6Hl/GRUFwO2uw 3fgVL4KnTwpHZ0/xHojXDWOS4KzgejsDmG2mzKvJfQT0TKkBJgb7KOY1IKhJHmtIhzfq zzihv0Z/TnGwwb5TUc2etudwcaqOMhO8ype0kKSGxMO2oN3Vn9YP54qlBQZmOD04Sv3f U/8ICAZgiTps1HudIm2FjAAf9PE+rGJyyF8xbg86LQHPpKzl48vCNkPpTVm9TAN0MLmc MxfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=K4omoXovJEzeGfzZZ5YLcw9cEy19X5ID8l3xwZaT/3M=; b=D9vgJ62w5AYM/PlsheG6NqaSPtCfJwtv8K8MnE18dhxT6/KvpKpfRWpvnJp1RWzYwy 36iBq+uXlSOgDDp7isVHPVqKCumsDWhlL9MPe79PZiac6HIymW8DUBKKP5cmvCb78EaA 1yLux6nqTeDxDuJDVUj9wKoAMzznKfOFD9iqBdcnaGnnH/tCzlZdLMOEZH36MLXydvgP IfoCnLfbvD5wv/R51CA9OXxEC8iiSTc0Sj2Kdn98ddQG6C1KSegP1YM7bCmnEevN8U4k m53vxl3LGqPOrBn+j5HhQLK1b9EF6srkqVXzPRzOs2roBofleVOazhkaG27XELCL2zEz Sa3A== X-Gm-Message-State: AG10YOSGE+g+9OqkChpCdBwsrTYudVEl2O9VejRfQLzjHWoMXpOnM1qSLtY3FIWmeGRn0w== X-Received: by 10.28.14.138 with SMTP id 132mr9555707wmo.25.1453381961735; Thu, 21 Jan 2016 05:12:41 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id l67sm29812637wmf.11.2016.01.21.05.12.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jan 2016 05:12:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <6FAFF2EB-0865-43B7-AAC9-2071B6297D16@gmail.com> Date: Thu, 21 Jan 2016 15:12:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <828B59D3-5684-42AC-BAF6-F8C3A7FCA66E@gmail.com> References: <6FAFF2EB-0865-43B7-AAC9-2071B6297D16@gmail.com> To: secdir , The IESG , draft-ietf-dnsop-cookies.all@ietf.org X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [secdir] SecDir Review of draft-ietf-dnsop-cookies-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 13:12:45 -0000 Version -09 looks good to me.=20 I still think they=E2=80=99re over-emphasizing how much this mechanism = is weak, but this is style, not substance. Yoav > On 8 Dec 2015, at 8:52 AM, Yoav Nir 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 authors, document editors, and WG chairs = should treat these comments just as they would any other IETF Last Call = comments. >=20 > Version reviewed: draft-ietf-dnsop-cookies-07 >=20 > Summary: has issues. >=20 > The draft describes a cookie mechanism (a little more complex than SYN = cookies or IKEv2 cookies) to prevent DoS, specifically amplification = attacks on the DNS, where an off-path attacker sends requests with = spoofed source to a DNS server, causing a lot of DNS traffic towards the = spoofed source. >=20 > ISSUES: >=20 > Section 5.5 describes what happens when a server rolls over its = secret. If the server receives a server cookie fitting the previous = server secret, it MUST reply with the new, correct, server cookie. This = is implied, but IMO should be stated explicitly, because it is = temptingly efficient to just copy the server cookie if it's valid (and a = cookie matching the previous secret is considered valid for a while) = into the response rather than re-calculating the server cookie before = sending. >=20 > An attacker could bypass the whole mechanism by not including the OPT, = and the way to deal with this is rate limiting on the server for clients = without valid cookies. I think this should be said explicitly in the = Security Considerations section. >=20 > Section 9.1 suggests as a cookie algorithm "HMAC-SHA256-64 [RFC6234]", = which I take to be SHA-256 truncated to 64 bits. There is no such = function (not any other truncation) in RFC 6234. Even shortened hashes = that do exist in other documents, such as SHA512-256 are not simple = truncations but also change the initialization vectors for the original = hash function, although shortened HMACs such as those used in IPSec = *are* simple truncations. >=20 > Same section, it is not clear what the criteria are for selecting an = algorithm. Specifically, I don't know what makes FNV strong enough = whereas something else (CRC?) is not. I don't think there's a practical = issue with FNV, but it would be better to state the goals. >=20 >=20 > NITS: >=20 > "To bypass the weak protection provided by using TCP requires, among = other things, that an off-path attacker guessing the 32-bit TCP sequence = number in use." > s/guessing/guess/ or s/that an off-path attacker guessing/an off-path = attacker to guess/ >=20 > The word "weak" is mentioned 18 times, in addition to related terms = such as "limited protection". The mechanism does what it does. Sure it = does not include 521-bit elliptic curve cryptography, but I don't think = this needs to be mentioned so often. >=20 > I think it should be mentioned that the cookie mechanism is stateless. = Of course all of DNS is stateless, but it should be mentioned that the = mechanism requires no per-client state on the *server*, but does require = per-server state on the *client*. >=20 > Section A.1: As mentioned above, I don't know the requirements for an = algorithm. But just looking at the following example, I don't like the = construction. So I set the secret to 0x3132333435363738, and considered = two IP addresses: 97.98.99.100 and 97.98.99.101. Running both through = FNV, I get the following: > FNV64("12345678abcd") =3D 0xb7fd1aee15822b05 > FNV64("12345678abce") =3D 0xb7fd1aee15822b04 >=20 > On the other hand, if we reverse the order of secret and IP address, = we get: > FNV64("abcd12345678") =3D 0x6c1e749e200cc845 > FNV64("abce12345678") =3D 0x5d17f5e450f9a52c > =09 > It seems like the FNV function is more sensitive to changes in earlier = bytes than to changes in later bytes. So placing the IP address first = makes this look more like a hash function. This is not a cryptographic = argument, but I believe it should be better to put the IP address first. >=20 From nobody Thu Jan 21 07:28:17 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 465561B3200 for ; Thu, 21 Jan 2016 07:28:15 -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 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 rB3s2IprMMlF for ; Thu, 21 Jan 2016 07:28:13 -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 DD87C1B31FD for ; Thu, 21 Jan 2016 07:28:12 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u0LFS9RV011554 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 21 Jan 2016 17:28:09 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u0LFS8I8015175; Thu, 21 Jan 2016 17:28:08 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22176.63752.805770.289365@fireball.acr.fi> Date: Thu, 21 Jan 2016 17:28:08 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 3 min X-Total-Time: 4 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 21 Jan 2016 15:28:15 -0000 When you are doing rereviews, please start a new thread in the secdir list when you post your review results for those too. I will only go through the new threads on the email archive when I mark reviews done, so if you have just replied to your previous review, I might not notice that. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Leif Johansson is next in the rotation. For telechat 2016-01-21 Reviewer LC end Draft Shaun Cooley T 2016-01-15 draft-ietf-lisp-threats-14 Alan DeKok T 2016-01-18 draft-ietf-nfsv4-rfc3530-migration-update-07 Joe Salowey T 2015-12-21 draft-ietf-dnsop-edns-client-subnet-06 For telechat 2016-02-04 Daniel Kahn Gillmor T 2016-02-04 draft-mahesh-mef-urn-01 Paul Hoffman T 2016-01-28 draft-ietf-ecrit-held-routing-04 Russ Housley T 2016-01-29 draft-ietf-rtgwg-mrt-frr-algorithm-08 Christian Huitema T 2016-01-29 draft-ietf-rtgwg-mrt-frr-architecture-09 Brian Weis TR2015-12-30 draft-ietf-isis-te-metric-extensions-09 Last calls and special requests: Derek Atkins 2016-01-18 draft-ietf-dnsop-edns-chain-query-06 Donald Eastlake 2016-01-18 draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-02 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Tobias Gondrom 2016-01-27 draft-ietf-codec-oggopus-10 Olafur Gudmundsson 2016-02-11 draft-holmberg-dispatch-pani-abnf-02 Phillip Hallam-Baker 2016-02-12 draft-ietf-behave-ipfix-nat-logging-06 Steve Hanna 2016-02-04 draft-ietf-dhc-dhcp-privacy-03 Sam Hartman 2016-02-04 draft-ietf-dhc-dhcpv6-privacy-03 Jeffrey Hutzelman 2015-12-04 draft-ietf-core-block-18 Chris Inacio 2016-02-02 draft-ietf-v6ops-ipv6-ehs-in-real-world-02 Eric Osterweil 2016-01-05 draft-campbell-art-rfc5727-update-02 Hannes Tschofenig 2015-12-28 draft-ietf-hip-rfc5204-bis-07 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-06 Tom Yu E 2016-02-01 draft-ietf-netconf-yang-library-03 -- kivinen@iki.fi From nobody Thu Jan 21 12:07:01 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDE51A90A5; Thu, 21 Jan 2016 12:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.7 X-Spam-Level: X-Spam-Status: No, score=-100.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_19=0.6, J_CHICKENPOX_36=0.6, USER_IN_WHITELIST=-100] autolearn=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 biUWc6Sc__pP; Thu, 21 Jan 2016 12:06:54 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 168B11A909E; Thu, 21 Jan 2016 12:06:54 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 55F799A4020; Thu, 21 Jan 2016 15:06:53 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id dTPSvtd7CUU3; Thu, 21 Jan 2016 15:05:45 -0500 (EST) Received: from [192.168.2.104] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id C17389A401F; Thu, 21 Jan 2016 15:06:52 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 21 Jan 2016 15:06:52 -0500 Message-Id: <3CA8F251-7482-4839-ACF1-39166B8DC905@vigilsec.com> To: draft-ietf-rtgwg-mrt-frr-algorithm.all@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IESG IESG , IETF SecDir Subject: [secdir] SecDir Review of draft-ietf-rtgwg-mrt-frr-algorithm-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 20:06:55 -0000 I reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Version reviewed: draft-ietf-rtgwg-mrt-frr-algorithm-08 I have a few comments. None of them are related to security, but since I read the document, I am passing these comment along. Summary: Ready (from a Security Directorate perspective) Major Concerns: None Minor Concern: I think the Abstract should be reworked so that it does not include a reference to an Internet-Draft filename. One solution is to replace it with an RFC number after the other document is published. Another solution is to add a sentence that explains MRT-FRR. Perhaps something like: MRT-FRR provides link-protection and node-protection with 100% coverage in any network topology that is still connected after the failure. Nits: The Introduction says that the MRT Lowpoint algorithm is required for implementation with the Default MRT profile. It should say this once in the first paragraph; it does not need repeating in several places. In the Introduction, please talk about Figure 1 before talking about Figure 2. I notice that both of these figures are already part of draft-ietf-rtgwg-mrt-frr-architecture, so it may be possible to summarize the point being made and then point to the architecture document for more details. The phrases "this draft" and "that draft" are used. I think it would be better to select words that anticipate publication as an RFC. Some of the figures contain algorithm pseudocode, but sometimes there are comments for explanation and sometimes the comments appear to be part of the code. For example, see Figure 12: Get the current node, s. Compute an ear(either through lowpoint inheritance or by following dfs parents) from s to a ready node e. (Thus, s is not e, if there is such ear.) if s is e for each node x in the ear that is not s x.localroot = s else for each node x in the ear that is not s or e x.localroot = e.localroot I think it would more clear is it looked something like: Get the current node, s. Compute an ear from s to a ready node e. // Compute either through lowpoint inheritance or // by following dfs parents. // Thus, s is not e, if there is such ear. if s is e for each node x in the ear that is not s x.localroot = s else for each node x in the ear that is not s or e x.localroot = e.localroot It would be event better if this pseudocode used the Construct_Ear function. From nobody Fri Jan 22 04:49:30 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233771A1BDF for ; Fri, 22 Jan 2016 04:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 r_NUt6jQZdAM for ; Fri, 22 Jan 2016 04:49:27 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EE221A1BD4 for ; Fri, 22 Jan 2016 04:49:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 904DCBEAA for ; Fri, 22 Jan 2016 12:49:25 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pA7719fObwW for ; Fri, 22 Jan 2016 12:49:25 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id ECB7ABDCA for ; Fri, 22 Jan 2016 12:49:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1453466965; bh=iZNXszTDb6nxoE7NQKax8xRslxFDAZltabyt4vZdk2w=; h=Subject:References:To:From:Date:In-Reply-To:From; b=vnco60RhcYW1pCocO5CvykyPECsZdCRwPjJoYQ5AYBKvJPnFdfXQlmyfTdcEksJgV ztQa3HfaE4wLnTRdv5E4FR869srbWeeV8gdKohAGpMOC22x2+qNS9orUO1v0bXNhPa r4E7nzoZxnGMK83YtSLX3GeCwSifJL6m5kw6UXgU= References: <56A1DB2D.40106@alvestrand.no> To: "secdir@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <56A1DB2D.40106@alvestrand.no> Message-ID: <56A22554.9000004@cs.tcd.ie> Date: Fri, 22 Jan 2016 12:49:24 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A1DB2D.40106@alvestrand.no> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [secdir] a different thing (was: Fwd: DISPATCH and strategies for standards maintenance) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 12:49:29 -0000 Hiya, Way down below, Harald says: " What the DISPATCH process fails to achieve is what a good directorate should have been doing: Taking a view of the whole area of the protocol suite, and noticing things like: " followed by a list of what Harald figures are bad things found in the RAI area. We don't tend to do anything like that in secdir, and I'm not sure how we could if we wanted to, or even if we should want to, but I suspect you'd be the folks involved if we ever did. So with no specific idea in mind, I wonder would (somehow) getting that kind of review be a good thing? And if so, any idea on how we might be able to do that? (Without us all using it to beat up on our least fav security technology:-) I'd be interested in what you think about that, on the list now and maybe for chatting at the secdir lunch for those of us who'll get to IETF95. Cheers, S. -------- Forwarded Message -------- Subject: DISPATCH and strategies for standards maintenance Date: Fri, 22 Jan 2016 08:33:01 +0100 From: Harald Alvestrand To: ietf@ietf.org Recently, in a response to a Last Call on , I wrote the following on the IETF list: Objection: I find the DISPATCH style of review to be a horribly broken idea. I also find the use of the term "working group", and the procedures of working groups, for what is effectively a permanent review panel and a standing BOF venue to be counterproductive and destructive of getting work done. This document proposes recommending this method as a generic tool that can be used in areas outside of the limited scope of SIP extensions - something I think is taking a bad idea and making it even more harmful. (RFC 5727 already said it would do that, but the RAI area has not followed up on this particular bad idea from RFC 5727, letting initiatives like WEBRTC flourish outside of the DISPATCH process, so the damage done by DISPATCH has been limited.) I therefore object to this document being published as a BCP. These words were rather harsh, and were commented on as such. It seems best for the community that I spend some words on describing why I came to this conclusion. When I came to deal with WebRTC and the assocated areas, I believed (not having examined the area too closely) that with the SIP suite, which uses SDP and RTP, we had achieved a reasonably functional and architecturally competent real time communications suite. I was wrong. It turned out that a number of fundamental problems existed, including: * A lack of clarity on the connection between SDP and RTP - the word “session” was used at both layers, but represented different things. * A lack of consensus on how one negotiated session properties that applied in one direction only. * An SDP architectural misfeature that led to a completely bogus requirement that differing media types be carried on different UDP ports * A number of issues with use of addresses in signalling - including the formulation of rules like the “SDP patch-up offer/answer” for making one set of addresses (in m-lines) match up with another set of addresses (in ICE) * A general acknowledgement that certain fairly absolute rules, like “always use RTCP”, were widely ignored in the industry and couldn’t be depended on * A number of rules around SSRCs that were based on an operating environment that doesn’t exist in practice (multicast groups) - in particular SSRC collisions - which have made these identifiers much less powerful than they might have been. * A number of long-standardized extension features (CAPNEG in particular) that are largely ignored by industry due to complexity, but are still used to block other efforts by saying “why can’t you use X instead”. * A number of unfinished products (EKT in particular) that seemed to be a good fit for some problem - but somehow never seemed to cross the finish line. This list is far from exhaustive. We have been chipping away at the issues that mattered to the WebRTC effort, while attempting to make sure the issues we were not addressing did not affect the effort (by not using the features they referenced). I observed the DISPATCH process for much of the time of my engagement. The DISPATCH process is reasonably efficient …. at solving the wrong problem. The ideal DISPATCH task is a proposal to address a small problem (or paper over some deficency in the protocol for a certain set of cases). It allows the ADs to delay such a proposal for 3 months without any controversy (“until the next IETF meeting”), and for 6 months if it turns out to need a WG (“first DISPATCH, then you write a charter, then you meet”). (Sometimes such delay is a good thing; some bad ideas just need the time to die.) Once the proposal reaches a DISPATCH meeting agenda, it gets some review, it gets some comments, it gets some recommendation (maybe) - and then it can move on, if the proposers still have energy for the push, and if any of the experts in the area have bought into the idea enough to give it the guidance it needs to achieve non-conflict with all the other small patches people are working on. What the DISPATCH process fails to achieve is what a good directorate should have been doing: Taking a view of the whole area of the protocol suite, and noticing things like: * SIP is largely non-interoperable. It’s useful to connect islands of a single product while claiming standards conformance, and it’s easier to wrangle into some semblance of interoperability than proprietary protocols - but it’s not “plug and play”. * SDP is a world picture that is not capable of representing a significant subset of the interesting ways in which people want to interconnect. This means that solutions that use SDP have to work around SDP, not with it. * RTP is showing its age. Security is a bolt-on, and RTCP is more of an extension platform than it is an useful set of features in the base spec. It’s clear that the industry needs a robust, interoperable, secure protocol suite for real time communication. It’s also clear that the IETF is the logical venue for that to happen. But DISPATCH isn’t the way to get there. -- Surveillance is pervasive. Go Dark. From nobody Sun Jan 24 14:53:25 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4D01B3448 for ; Sun, 24 Jan 2016 14:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553] autolearn=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 m7ucJQd035Gz for ; Sun, 24 Jan 2016 14:53:23 -0800 (PST) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 2AAF21B343D for ; Sun, 24 Jan 2016 14:53:23 -0800 (PST) Received: from [10.32.60.39] (50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110]) (authenticated bits=0) by hoffman.proper.com (8.15.2/8.14.9) with ESMTPSA id u0OMrLY0087918 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 24 Jan 2016 15:53:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110] claimed to be [10.32.60.39] From: "Paul Hoffman" To: secdir Date: Sun, 24 Jan 2016 14:53:21 -0800 Message-ID: <30D9039D-03F4-451B-9DE5-4EE25BA277C9@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Subject: [secdir] Secdir review of draft-ietf-ecrit-held-routing X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 22:53:23 -0000 Greetings. This document, "A Routing Request Extension for the HELD Protocol", updates the HELD protocol in a way that exposes a bit more privacy information than is already passed around in HELD. That is, it adds routing information to the location information already passed in HELD. The document's Privacy Considerations section covers the additional issues well. The Security Considerations section is a bit stubbish: "This document imposes no additional security considerations beyond those already described in [RFC5687] and [RFC6155]"; however, I could not see anything that should be added. --Paul Hoffman From nobody Mon Jan 25 11:56:03 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787BF1A00A8; Mon, 25 Jan 2016 11:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 F-RIzdRAW6Nb; Mon, 25 Jan 2016 11:55:58 -0800 (PST) Received: from smtp2.infineon.com (smtp2.infineon.com [217.10.52.18]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53CCA1A00B0; Mon, 25 Jan 2016 11:55:57 -0800 (PST) X-SBRS: None Received: from unknown (HELO mucxv003.muc.infineon.com) ([172.23.11.20]) by smtp2.infineon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jan 2016 20:55:55 +0100 Received: from MUCSE607.infineon.com (unknown [172.23.7.108]) by mucxv003.muc.infineon.com (Postfix) with ESMTPS; Mon, 25 Jan 2016 20:55:55 +0100 (CET) Received: from KLUSE612.infineon.com (172.28.156.138) by MUCSE607.infineon.com (172.23.7.108) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 25 Jan 2016 20:55:54 +0100 Received: from KLUSE610.infineon.com (172.28.156.137) by KLUSE612.infineon.com (172.28.156.138) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 25 Jan 2016 20:55:54 +0100 Received: from KLUSE610.infineon.com ([172.28.148.8]) by KLUSE610.infineon.com ([172.28.148.8]) with mapi id 15.00.1104.000; Mon, 25 Jan 2016 20:55:54 +0100 From: To: Thread-Topic: secdir review of draft-ietf-dhc-dhcp-privacy-03 Thread-Index: AdFXqEqgm+cNWUlLQ0Gb8Ueekql7fw== Date: Mon, 25 Jan 2016 19:55:53 +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.23.8.247] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22088.002 x-tm-as-result: No--39.262200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_d13d613b5e994c5eb1ba402a3d6aec07KLUSE610infineoncom_" MIME-Version: 1.0 Archived-At: Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-dhc-dhcp-privacy-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 19:56:00 -0000 --_000_d13d613b5e994c5eb1ba402a3d6aec07KLUSE610infineoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I reviewed this document as part of the Security Directorate's ongoing effo= rt to review all IETF documents being processed by the IESG. These comment= s were written primarily for the benefit of the Security Area Directors. D= ocument authors, document editors, and WG chairs should treat these comment= s just like any other IETF Last Call comments. Summary: Ready with issues I applaud the creation of this document. In today's environment, having a p= rivacy analysis of DHCPv4 is quite valuable. I am not a DHCP expert so I can't comment on any privacy issues that might = have been missed but the document seems to be quite thorough in this respec= t. I especially like the way that section 5 describes briefly how the privacy = vulnerabilities listed in section 4 could be exploited. The attack methods = listed here should motivate administrators and implementers to consider plu= gging them and even help folks convince their management that these issues = should be addressed. My only concern is that the Security Considerations section is not complete= . I would recommend adding a few more sentences to the Security Consideration= s section to point out that privacy flaws can substantially ease security a= ttacks. For example, a targeted attack can use information leaked through D= HCPv4 to determine the IP address of the targeted user or device. Then devi= ce type discovery or operating system discovery to identify the device type= and OS version, enabling attacks tailored to known vulnerabilities of this= device type and OS. Further, the last sentence in the Security Considerations section would ben= efit from becoming a separate paragraph with a bit more elaboration. What a= re the security implications of client privacy and perhaps anonymity? Does = this mean that client privacy has a downside? Or would clever attackers avo= id disclosing anything about their identity through DHCP and only innocent = users be the likely victims of DHCPv4 privacy problems? Thanks, Steve --_000_d13d613b5e994c5eb1ba402a3d6aec07KLUSE610infineoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I reviewed this document as part of the Security = Directorate's ongoing effort to review all IETF documents being processed b= y the IESG.  These comments were written primarily for the benefit of = the Security Area Directors.  Document authors, document editors, and WG chairs should treat these comments just = like any other IETF Last Call comments.

 

Summary: Ready with issues

 

I applaud the creation of this document. In today= ’s environment, having a privacy analysis of DHCPv4 is quite valuable= .

 

I am not a DHCP expert so I can’t comment o= n any privacy issues that might have been missed but the document seems to = be quite thorough in this respect.

 

I especially like the way that section 5 describe= s briefly how the privacy vulnerabilities listed in section 4 could be expl= oited. The attack methods listed here should motivate administrators and im= plementers to consider plugging them and even help folks convince their management that these issues should be = addressed.

 

My only concern is that the Security Consideratio= ns section is not complete.

 

I would recommend adding a few more sentences to = the Security Considerations section to point out that privacy flaws can sub= stantially ease security attacks. For example, a targeted attack can use in= formation leaked through DHCPv4 to determine the IP address of the targeted user or device. Then device type = discovery or operating system discovery to identify the device type and OS = version, enabling attacks tailored to known vulnerabilities of this device = type and OS.

 

Further, the last sentence in the Security Consid= erations section would benefit from becoming a separate paragraph with a bi= t more elaboration. What are the security implications of client privacy an= d perhaps anonymity? Does this mean that client privacy has a downside? Or would clever attackers avoid disclo= sing anything about their identity through DHCP and only innocent users be = the likely victims of DHCPv4 privacy problems?

 

Thanks,

 

Steve

 

--_000_d13d613b5e994c5eb1ba402a3d6aec07KLUSE610infineoncom_-- From nobody Wed Jan 27 03:07:14 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582471A6F6B; Wed, 27 Jan 2016 03:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=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 5wunD4rfxxNI; Wed, 27 Jan 2016 03:07:04 -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 294AC1A6F61; Wed, 27 Jan 2016 03:07:04 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3pr2FJ4DR9z3cY; Wed, 27 Jan 2016 12:07:00 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 QV-71y5CL0Yn; Wed, 27 Jan 2016 12:06:54 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 27 Jan 2016 12:06:54 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D2068600B884; Wed, 27 Jan 2016 06:06:52 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca D2068600B884 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CD4C22608E; Wed, 27 Jan 2016 06:06:52 -0500 (EST) Date: Wed, 27 Jan 2016 06:06:52 -0500 (EST) From: Paul Wouters To: Donald Eastlake In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: draft-ietf-dane-openpgpkey.all@tools.ietf.org, dane WG list , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-dane-openpgpkey-06 SECDIR Review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 11:07:08 -0000 Hi Donald, Thanks for the secdir review. I've incorporated your suggestions and hopefully resolved your issues in the -07 draft I just posted at https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-07 Comments inline below. > I think this draft is not ready for publication. It probably minimal > technical changes but there are significant wording problems with it. > > Security: > ------------ > > This document is "DANE for OpenPGP ..." but never says how what it > documents is a use of DANE or what DANE is. While there is a reference > to RFC 6698, at a minimum the DANE acronym should be expanded at first > use and/or in Section 1.2. Preferably two or three sentences should be > added to fix this gap. I added a sentence to the introduction: DNSSEC Authentication of Networked Entities ("DANE") is a method for publishing public keys and certificates in DNS. > I am concerned about the use of the words "validate" and "verify" in > this document in a wide variety of different ways, and in particular > their use in connection with OPENPGPKEY RRs. The ordinary and usual > meaning of these words, when they are not qualified in some way, is > that something is completely valid/verified for use and can be used > without further checking. But that isn't what seems to be meant in > this document. Here it just seems to sometimes mean that it has > validated under DNSSEC. It might also mean that it is of valid syntax > and a bit more -- the document is unclear on whether that is included. > But the use of these words for OPENPGPKEY RRs seems to exclude the > validation under the web of trust or human judgement even though that > step is mandated at a couple of places in the document. The term "verify" is in common use with OpenPPGP, for instance using the gnupg command where the command is "gpg --verify". I have made some changes to avoid possible confusion. I have changed the usage of validation or verification in the context of DNSSEC to consitently be "DNSSEC validation". I've also changed the word "verification" when used in a context that is not related to OpenPGP. (for instance by changing "source ip verification" to "source ip confirmation"). > Looking at Section 5, the "obtain or verify" in the first sentence > seems odd. Shouldn't it use "and" and be more like "obtain and DNSSEC > verify"? And in the following sentence, I would say "... ; if DNSSEC > validation reaches ..." Also, if you are going to start talking about > a specific DNSSEC state name as is done here, there should be a > reference to the specific DNSSEC RFC where that state name is defined. Changed to: The OPENPGPKEY record allows an application or service to obtain an OpenPGP public key and use it for verifying a digital signature or encrypting a message to the public key. The DNS answer MUST pass DNSSEC validation; if DNSSEC validation reaches any state other than "Secure" (as specified in RFC-4035), the DNSSEC validation MUST be treated as a failure. RFF-4035 has been added as a normative reference. > In Section 5.1, in the first sentence, I would say "to seek" rather > than "to discover". "discover" makes it sound like it will always > un-cover/find something; also I think it would be a bit better to say > "corresponding to" rather than "belongs to". Changed as suggested. > The last sentence in 5.1 > has too many confusing "this"s. Suggest, assuming I have correctly > understood what you want to say, replacing the current last sentence > with "An application whose attempt fails to retrieve a DNSSEC verified > OPENPGPKEY RR from the DNS should remember that failure for some time > to avoid sending out a DNS request for each email message the > application is sending out; such DNS requests constitute a privacy > leak". Changed. > I suggest changing the title of Section 5.2 to "Confirming that an > OpenPGP key is current" since that is what it is about, not about > general validity. Changed. > The third sentence of Section 5.2 ("If verifying ... > a failure") is unclear and not grammatical. Trying to re-write this > third sentence I come up with "If a locally stored OpenPGP public key > is found to be different from an OpenPGP retrieved from the DNS and > DNSSEC verified as described herein, then ...." But I don't understand > this and don't understand what the "..." should be. I have changed it to: If the locally stored OpenPGP public key is different from the DNSSEC validated OpenPGP public key currently published in DNS, the verification MUST be treated as a failure unless if the locally stored OpenPGP key signed the newly published OpenPGP public key found in DNS. > Can't there can be > multiple good OpenPGP keys for the same email address? Yes, there can be. But a locally stored OpenPGP public key must be considered more secure than a new one observed in DNS, until a human has confirmed the new key. Unless the old key has confirmed the new key. > What if one key > is stored locally and you retrieve two keys, one of which is equal to > the local key and one of which is different? Presumably it depends on > the local/user's policy what to do in such a case of different keys. What I tried to accomplish is that if you have a local key, any key update must be confirmed by the old key or the user. Switching keys without further confirmation is just too dangerous. > How is it helpful to say "the verification MUST be treated as a > failure"? (This certainly further confuses what "verification" means > in this document.) The presence of a new key might mean the old (locally stored) key was compromised. But the new key cannot just be trusted even if it passed DNSSEC validation. Unless the old key signed the new key, human intervention should be used to resolve the conflict. By saying "verification failure" it blocks the application from sending the data encrypted to either key - and require a user to resolve the situation. > It is not clear exactly what that means but if it > says that a DNSSEC verified OpenPGP key retrieved from the DNS should > be dropped/ignored, why is that always the right thing? I did not mean say drop or ignored. A conflict of keys should be resolved by the user. > In the second sentence of the first paragraph of Section 7, what does > the initial "It" stand for? Changed to: DANE for OpenPGP as specified in this document is a solution aimed to ease obtaining someone's public key. Without manual verification of the OpenPGP key obtained via DANE, this retrieved key should only be used for encryption if the only other alternative is sending the message in plaintext. > If you were faked-out and believed a false key so email was encrypted > to the bad guy and could not be read by the intended recipient, I > would say that was worse than plaintext. That really depends on the situation. If an attacker can replace OPENPGPKEY records, they can most likely also change MX records to just get everything. > This paragraph goes on to > talk about active attacks, which usually. in the email context, refers > to active attacks on the email on the wire, but I would guess this > text is actually talking about active attacks in the form of storing a > wrong key in the DNS... The active attacks refer to everything that can cause a third party to gain access to the unencrypted email content. > In re Section 7.5, why isn't the domain name included in the hash? It > seems to improve security a little and the effort is small. As stated in that section 7.5: The domain name part of the email address is not used as part of the hash so that hashes can be used in multiple zones deployed using DNAME [RFC6672] > Other: > -------- > > Section 1: > > The references for Secure DNS should be given when Secure DNS is first > mentioned on page 3. Done. > Section 1.1: > > I do not think there is such a thing as an "Experimental RRtype". It > would be better to say something like "This document specifies an > RRtype whose use is Experimental." Done. > I don't quite grok the use of "generality of" on page 4. Perhaps it > should be replaced with "diffuse support of" or something. Changed to "general application" > Section 2: > > As long as you are bothering to say that the OPENPGPKEY RR has no > special TTL requirements, you might as well say it has no special > Additional section retrieval requirements, since I think that is the > most common type of RR special processing. But I think the lack of > such special requirements is the default so you could probably just > leave these negative statements out. Done. > Section 2.3: > > "textual zone files" -> "master files [RFC1035]" and add [RFC1035] to > the normative references. Done. > Section 3: > > The following statement seems at least a little misleading: > The DNS does not allow the use of all characters that are supported > in the "local-part" of email addresses as defined in [RFC5322] and > [RFC6530]. > DNS is binary clean. What left hand side characters allowed in > [RFC5322] are now allowed in DNS? Seems to me that only international > text as such [RFC6530] is a problem for DNS. And the "." or a NULL. There is also the case sensitivity argument raised by some. > Probably the first bullet should be split in two. The first time I > read it, it seemed that the first sentence was talking about some > encodings. Then the second sentence talks about other encodings and > says they are hashed. So, of course, I thought that the encodings > talked about in the first sentence were not hashed. But the example > appears to show that the current text had conveyed the wrong thing to > me and that it is always hashes. I suggest that after "If it is > written in another encoding it should be converted to UTF-8" be > followed by a period and then there should be a new bullet item > talking about hashing, etc., to make it clear that the hashing, etc., Done. > apply to all encodings in the first bullet. Furthermore, I don't > understand why the text fragment I quote says "should" rather than > "must" or perhaps just replace "should be" with "is". Done (with "is") > Then we get to the truncation. "Truncation comes from the right-most > octets." is completely ambiguous. At a minimum, a word needs to be > added so it says "Truncation comes from using the right-most octets." > or "Truncation comes from dropping the right-most octets." > Alternatively some other non-ambiguous wording is needed. Actually I think the whole two sentence that start from this can be dropped. These add no new information. > Presumably it is believed that the probability of a hash collision is > small enough that it can be ignored. If so, it wouldn't hurt to say > so. Added to the security section: In theory, two different local-parts could hash to the same value. This document assumes that such a hash collision has a negliable chance of happening. > Section 7: > > The last paragraph of Section 7 seems to equate "Organizations" and > "mail servers". Suggest recasting the second sentence as "Mail servers > of such organizations MAY optionally re-encrypt a received message to > an individual's OpenPGP key.". Done. > Section 7.1: > > Again, I assume "indeterminate" and "bogus" are used in their DNSSEC > meaning. So there needs to be a reference here to the DNSSEC RFC that > explains those words. Done, Added pointer to RFC-4035 > Author's Address: > > I understand that many do not agree with me but I believe that first > page authors should normally list a postal address and a telephone > number to which a message could be sent or at which a message could be > left for them in addition to an email address. This section looks like > schlock corner cutting to me. I do not agree. Any address and phone number listed would be too ephemeral or too generic to be of value to anyone. > Trivia: > -------- > > "twart" -> "thwart" and "twarts" -> "thwarts" Fixed. > Section 6: "properties are not exported" -> "properties not be > exported" and in the following sentence "have" -> "has" Fixed. > Section 7: "direct" -> "ask" (a mail client has no power to order the > user to do anything) Fixed. Also changed "human" to "user" everywhere. > Section 7.1: 5th paragraph, "sent" -> "send" Fixed. Paul From nobody Wed Jan 27 13:31:48 2016 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 90B731AC40F; Wed, 27 Jan 2016 12:56:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1453928180; bh=tu0ardzuqR7I1UdiOWQRH3MI9ZV9JawrrqIkwusVuoI=; h=From:Message-Id:Date:To:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=WZ1OTg4Otcp7u5AJmgJVE7pYFjlaIH9pzSVcvU4p+WTBbuMSw3gT80A36Kwj/Uu8k Qa+ULs1ikRpJMUQFJjMWfU6TqgE1SXbMSgVgc0mvpJTOlfIuPVuW7OTibnhkvgOQMm RzgAnGrPEqGgfMh/v4vtvuYKknsd5ELcvdZKvwrY= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5588E1AC40F for ; Wed, 27 Jan 2016 12:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 iKMjftucN1DG for ; Wed, 27 Jan 2016 12:56:17 -0800 (PST) Received: from p3plsmtpa11-04.prod.phx3.secureserver.net (p3plsmtpa11-04.prod.phx3.secureserver.net [68.178.252.105]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A382E1AC40B for ; Wed, 27 Jan 2016 12:56:17 -0800 (PST) Received: from [10.0.1.7] ([50.158.195.176]) by p3plsmtpa11-04.prod.phx3.secureserver.net with id B8wG1s00Q3opgZu018wHnh; Wed, 27 Jan 2016 13:56:17 -0700 From: "pat.kinney@kinneyconsultingllc.com" Message-Id: Date: Wed, 27 Jan 2016 14:56:16 -0600 To: new-work@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 27 Jan 2016 13:31:48 -0800 Subject: [secdir] [new-work] New Project being reviewed in IEEE 802 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 20:56:20 -0000 SGVsbG8sIAoKSSB3b3VsZCBsaWtlIHRvIGluZm9ybSB5b3UgdGhlIG5ldy13b3JrIG1haWxpbmcg bGlzdCB0aGF0IHRoZSBJRUVFIDgwMi4xNSB3b3JrIGdyb3VwIChXRykgaGFzIGFwcHJvdmVkIHRo ZSBJRUVFIDgwMi4xNS4xMiBVcHBlciBMYXllciBJbnRlcmZhY2UgKFVMSSkgUHJvamVjdCBBdXRo b3JpemF0aW9uIFJlcXVlc3QgKFBBUikuICBUaGlzIGlzIGZvciBhbiBMMisgcHJvamVjdCB0aGF0 IG1heSBpbXBhY3QgSUVURiB3b3JrIGdyb3VwcyBzdWNoIGFzIDZ0aXNjaCwgYW5kIDZsbyAKCgpU aGUgbmV4dCBzdGVwIGZvciB0aGlzIHByb2plY3QgcHJvcG9zYWwgaXMgZm9yIHRoZSBJRUVFIDgw MiBXR3MgdG8gcmV2aWV3IHRoZSBQQVIgYW5kIHN1Z2dlc3QgY29ycmVjdGl2ZSBsYW5ndWFnZSBm b3IgZXJyb3JzIHRoYXQgdGhleSBjYXRjaC4gIFNob3VsZCB0aGV5IGFwcHJvdmUgaXQsIGl0IHdp bGwgdGhlbiBnbyB0byB0aGUgSUVFRSBOZXcgU3RhbmRhcmRzIENvbW1pdHRlZSAoTmVzQ29tKSBm b3IgZmluYWwgYXBwcm92YWwgYmVmb3JlIGl0IGJlY29tZXMgYSBmdWxseSBhcHByb3ZlZCBwcm9q ZWN0LiAgWW91IGNhbiBkb3dubG9hZCB0aGUgUEFSIGRvY3VtZW50OiAxNS0xNS0wNzYwLTA2ICho dHRwczovL21lbnRvci5pZWVlLm9yZy84MDIuMTUvZGNuLzE1LzE1LTE1LTA3NjAtMDYtMGxsYy04 MDItMTUtMTItcGFyLWRyYWZ0LmRvY3gpIGFuZCB0aGUgQ3JpdGVyaWEgZm9yIFN0YW5kYXJkcyBE ZXZlbG9wbWVudChDU0QpIGRvY3VtZW50OiAxNS0xNS0wNzY4LTA2IChodHRwczovL21lbnRvci5p ZWVlLm9yZy84MDIuMTUvZGNuLzE1LzE1LTE1LTA3NjgtMDYtMGxsYy04MDItMTUtMTItZHJhZnQt Y3NkLmRvY3gpLiAgSSBoYXZlIGluY2x1ZGVkIHRoZSBTY29wZSBvZiB0aGUgUEFSIGJlbG93IGZv ciB5b3VyIGNvbnZlbmllbmNlOgoKODAyLjE1LjEyIFNjb3BlOiBUaGlzIHN0YW5kYXJkIGRlZmlu ZXMgYW4gVXBwZXIgTGF5ZXIgSW50ZXJmYWNlIChVTEkpIHN1YmxheWVyIGluIExheWVyIDIgKEwy KSwgYmV0d2VlbiBMYXllciAzIChMMykgYW5kIHRoZSBJRUVFIDgwMi4xNS40IE1lZGlhIEFjY2Vz cyBDb250cm9sIChNQUMpIHN1YmxheWVyLiAgVGhlIFVMSSBwcm92aWRlcyBpbnRlcmZhY2VzIGZv ciBkYXRhLCBjb250cm9sLCBhbmQgbWFuYWdlbWVudCBpbmZvcm1hdGlvbi4gIFRoZSBVTEkgYWRh cHRzIEwzIHByb3RvY29scyBhbmQgcHJvdmlkZXMgb3BlcmF0aW9uYWwgY29uZmlndXJhdGlvbiBp bmNsdWRpbmcgbmV0d29yayBhbmQgcmVndWxhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIElFRUUg ODAyLjE1LjQgTUFDLiAgRnVydGhlcm1vcmUsIHRoZSBVTEkgaW50ZWdyYXRlcyB1cHBlciBMYXll ciAyIHN1Yi1sYXllciAoTDIrKSBmdW5jdGlvbmFsaXRpZXMgZm9jdXNlZCBvbiBpbnRlcmZhY2lu ZyB0byBJRUVFIFN0ZCA4MDIuMTUuNCBzdWNoIGFzIEtleSBNYW5hZ2VtZW50IFByb3RvY29scyAo S01QKSwgTDIgcm91dGluZyAoTDJSKSBwcm90b2NvbHMsIGFuZCBJbnRlcm5ldCBFbmdpbmVlcmlu ZyBUYXNrIEZvcmNlIChJRVRGKSA2VGlTQ0ggT3BlcmF0aW9uIFByb3RvY29sICg2VE9QKSBmb3Ig b3B0aW9uYWwgdXNlLiAgRmluYWxseSwgdGhlIFVMSSBwcm92aWRlcyBwcm90b2NvbCBkaWZmZXJl bnRpYXRpb24sIHVzaW5nIG1lY2hhbmlzbXMgc3VjaCBhcyBFdGhlclR5cGUsIHRvIHN1cHBvcnQg bXVsdGlwbGUsIGRpdmVyc2UgaGlnaGVyIGxheWVyIHByb3RvY29scy4gCgoKUGxlYXNlIHNlbmQg Y29tbWVudHMgdG8gc3Rkcy04MDItMTUtbGxjQGxpc3RzZXJ2LmllZWUub3JnLCB3aGljaCBpcyB0 aGUgcmVmbGVjdG9yIGZvciB0aGUgc3R1ZHkgZ3JvdXAgcmVzcG9uc2libGUgZm9yIHRoZSBwcm9q ZWN04oCZcyBQQVIgYW5kIENTRC4gSWYgeW91IHNob3VsZCBoYXZlIGFueSBxdWVzdGlvbnMgb3Ig bmVlZCBmdXJ0aGVyIGluZm9ybWF0aW9uLCBwbGVhc2UgY29udGFjdCBQYXQgS2lubmV5IDxwYXQu a2lubmV5QGtpbm5leWNvbnN1bHRpbmdsbGMuY29tPi4KClRoYW5rcywKUGF0IEtpbm5leQoKCktp bm5leSBDb25zdWx0aW5nIExMQwpJRUVFIDgwMi4xNSBXRyB2aWNlIGNoYWlyLCBTQyBjaGFpciwg ODAyLjE1LjEyIFNHIGNoYWlyCklTQTEwMCBjby1jaGFpciwgSVNBMTAwLjIwIGNoYWlyCk86ICsx Ljg0Ny45NjAuMzcxNQpwYXQua2lubmV5QGtpbm5leWNvbnN1bHRpbmdsbGMuY29tCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldy13b3JrIG1haWxpbmcg bGlzdApuZXctd29ya0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldy13b3JrCg== From nobody Thu Jan 28 03:15:16 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CE91B3BAA for ; Thu, 28 Jan 2016 03:15:14 -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 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 ZqhNM4GJwsb8 for ; Thu, 28 Jan 2016 03:15:12 -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 78AFD1B3BA5 for ; Thu, 28 Jan 2016 03:15:12 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u0SBF7J7024068 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 28 Jan 2016 13:15:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u0SBF7ea003252; Thu, 28 Jan 2016 13:15:07 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22185.63547.537417.727492@fireball.acr.fi> Date: Thu, 28 Jan 2016 13:15:07 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 Jan 2016 11:15:15 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Scott Kelly is next in the rotation. For telechat 2016-02-04 Reviewer LC end Draft Daniel Kahn Gillmor T 2016-02-04 draft-mahesh-mef-urn-01 Christian Huitema T 2016-01-29 draft-ietf-rtgwg-mrt-frr-architecture-09 Brian Weis TR2015-12-30 draft-ietf-isis-te-metric-extensions-09 For telechat 2016-03-03 Charlie Kaufman T 2016-02-18 draft-sparks-genarea-mailarch-improvements-02 Last calls and special requests: Derek Atkins 2016-01-18 draft-ietf-dnsop-edns-chain-query-06 Donald Eastlake 2016-01-18 draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-03 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Tobias Gondrom 2016-01-27 draft-ietf-codec-oggopus-10 Olafur Gudmundsson 2016-02-11 draft-holmberg-dispatch-pani-abnf-02 Phillip Hallam-Baker 2016-02-12 draft-ietf-behave-ipfix-nat-logging-06 Sam Hartman 2016-02-04 draft-ietf-dhc-dhcpv6-privacy-03 Jeffrey Hutzelman 2015-12-04 draft-ietf-core-block-18 Chris Inacio 2016-02-02 draft-ietf-v6ops-ipv6-ehs-in-real-world-02 Leif Johansson 2016-02-10 draft-ietf-dprive-edns0-padding-02 Simon Josefsson 2016-02-05 draft-ietf-netext-logical-interface-support-12 Benjamin Kaduk 2016-02-09 draft-ietf-tsvwg-circuit-breaker-11 Stephen Kent R2016-02-10 draft-ietf-i2rs-problem-statement-09 Eric Osterweil 2016-01-05 draft-campbell-art-rfc5727-update-02 Hannes Tschofenig 2015-12-28 draft-ietf-hip-rfc5204-bis-07 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-06 Tom Yu E 2016-02-01 draft-ietf-netconf-yang-library-03 -- kivinen@iki.fi From nobody Thu Jan 28 11:36:53 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A851B3601 for ; Thu, 28 Jan 2016 11:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 v7xTO9ZTiPGJ for ; Thu, 28 Jan 2016 11:36:50 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179451B35FD for ; Thu, 28 Jan 2016 11:36:50 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:34255 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aOsMl-000OzE-D5; Thu, 28 Jan 2016 14:36:27 -0500 To: secdir , akatlas@juniper.net, tnadeau@lucidvision.com, wardd@cisco.com, jhaas@pfrc.org, shares@ndzh.com, Deborah Brungard , Alvaro Retana From: Stephen Kent Message-ID: <56AA6DBA.8040306@bbn.com> Date: Thu, 28 Jan 2016 14:36:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------030605070703000805060701" Archived-At: Subject: [secdir] early review of draft-ietf-i2rs-problem-statement-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 19:36:52 -0000 This is a multi-part message in MIME format. --------------030605070703000805060701 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit SECDIR early review of draft-ietf-i2rs-problem-statement-09 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written with the intent of improving security requirements and considerations in IETF drafts.Comments not addressed in last call may be included in AD reviews during the IESG review.Document editors and WG chairs should treat these comments just like any other last call comments. This is a relatively short document describing the problem being addressed by the I2RS WG, and establishing some requirements for solutions. I reviewed the -04 version of this document in December 2014. This version is slightly longer and is improved. In my previous review I noted a coupe of typos that have been fixed in this version. I also suggested that the Security Considerations section be revised. Although this section is still only one paragraph, the authors have removed the odd language I cited and have provided a pointer to the I2RS arch document. Thus the section has been approved. I have a few suggested edits: The penultimate paragraph on page 2 contains a sentence that runs on for over 8 lines! Please break this into 2-3 sentences. colocated within -> co-located within re-organize the document so that Figure 1 fits on a single page must select the suitable protocol(s) -> must select suitable protocol(s) between the I2RS Clients and I2RS Agent -> between I2RS Clients and I2RS Agents must identify or define is a set -> must identify or define a set the last paragraph on page 5 flips between data model (singular) and data models (plural). Make this consistent. The example for recursion in Section 3 (paragraph 1 is confusing, at least to me). may also need to be -> also may need to be --------------030605070703000805060701 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

SECDIR early review of draft-ietf-i2rs-problem-statement-09

 

 

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving security requirements and considerations in IETF drafts.  Comments not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

 

This is a relatively short document describing the problem being addressed by the I2RS WG, and establishing some requirements for solutions. I reviewed the -04 version of this document in December 2014. This version is slightly longer and is improved.

 

In my previous review I noted a coupe of typos that have been fixed in this version. I also suggested that the Security Considerations section be revised. Although this section is still only one paragraph, the authors have removed the odd language I cited and have provided a pointer to the I2RS arch document. Thus the section has been approved.

 

I have a few suggested edits:

 

The penultimate paragraph on page 2 contains a sentence that runs
on for over 8 lines! Please break this into 2-3 sentences.

 

colocated within -> co-located within

 

re-organize the document so that Figure 1 fits on a single page

 

must select the suitable protocol(s) -> must select suitable protocol(s)

 

between the I2RS Clients and I2RS Agent -> between I2RS Clients and I2RS Agents

 

must identify or define is a set -> must identify or define a set

 

the last paragraph on page 5 flips between data model (singular) and data models (plural). Make this consistent.

 

The example for recursion in Section 3 (paragraph 1 is confusing, at least to me).

 

may also need to be -> also may need to be

 

 

--------------030605070703000805060701-- From nobody Thu Jan 28 14:17:22 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011071AC3A7; Thu, 28 Jan 2016 14:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 zCaRLandTJvP; Thu, 28 Jan 2016 14:17:18 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::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 9C9941AC3A6; Thu, 28 Jan 2016 14:17:18 -0800 (PST) Received: by mail-ob0-x231.google.com with SMTP id is5so48010908obc.0; Thu, 28 Jan 2016 14:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Xn6p2TgJsuBNttEW4ldqIPUbVQQ/gIA5ewzdmPkrDuU=; b=nmFZi0TtBw723SK/qAwcV2UbDSuXpK2qo1MRuiAE3sWkHkCmClspG+n1iH5NIdi4NU CGZsxTix3WvBeMRKgdHLJTuHGQneyb67GUQ0T6sBg+NxCXqAtmVle1p5mFv6myU/Fw9f ush2KOl+YBh/muOyYtwzz1mwDOgI55416PPOgw27C76jjX/TvUv+49SFJVXFljtdizBd sK2IC+BvEyXQGmshrPboLOjADEYv5maFLUhV7H3maTpdpC258m4rWokBMANgiCbGKkVp dJQlFGI6TuLFZm9zZmk/Ld6es4suJXx6c9d9BUFn+vuy7lE8/baMeYp/LVwDrf603Rdz 5DEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=Xn6p2TgJsuBNttEW4ldqIPUbVQQ/gIA5ewzdmPkrDuU=; b=A4+IK8tKJliGBl3kCMKN79GGkpuPZVAl9bf6veEd6QRid79ZjZol+0BVSsayClNTBc m6108RD5J7gI86qLLxH7pyUP286rfGSMJMaRQBRBiDQN6avhRL5jqzw6cz0KiY6yJmIl Zcq9YwRD3LgPR8plXSh+dXPoUnf3/uIr4/5McHyaXFYrRJIlvLUacKoUyEKe7N7Sekaa DwCCH4dZPAzMfLd6Ge93jJiCHvq4KC/WqVSM0fR5N7ppNy9Khr6yCcBi8MOmQTo25bfm +kAReOKSC0w3D9gWnOmnxu8S2skcRPrmuK/wr3V2YtnaaN+TlPFG/6qbst6EwslOwBgX kx0g== X-Gm-Message-State: AG10YORVK8rT9Q+vULqo/psGzktUtTgdnmq0mSDqNS3hUCQS6GX2eg2TWs9oSSPGtdoYphJ0GG9jHQC8nuDSBA== X-Received: by 10.182.79.103 with SMTP id i7mr4109265obx.41.1454019438033; Thu, 28 Jan 2016 14:17:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.157.161 with HTTP; Thu, 28 Jan 2016 14:17:03 -0800 (PST) From: Donald Eastlake Date: Thu, 28 Jan 2016 17:17:03 -0500 Message-ID: To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-opsawg-hmac-sha-2-usm-snmp-new.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-03 SECDIR review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 22:17:20 -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. Document editors and WG chairs should treat these comments just like any other last call comments. I think this document is pretty much Ready with nits. It is a replacement for RFC 7630 with the only change being, apparently, that the MIB MODULE-IDENTITY was incorrect in 7630. The Security Considerations Section looks good. Nits: The Abstract does not mention that this document obsoletes RFC 7630. I think it is a good practice to include that in the Abstract. The first paragraph of the Introduction seems odd to me It says "This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines additional authentication protocols ..." While I can't actually say this is actually wrong, the portion of the MIB it defines is trivial and it seems to me that the meat is in the specification of the additional authentication protocols. Certainly, those authentication protocol specifications don't appear in the MIB portion specified, only identifiers for them. Yet the wording of the Introduction (... defines a portion of the ... MIB.. In particular, ...) seems to imply that the definition of the additional authentication protocols is a subpart of the portion of the MIB. So I would say the Introduction should begin with something like: "This document specified additional authentication protocols ... In addition, it defines a portion of the Management Information Base (MIB) containing identifiers for these authentication protocols for use with network management protocols." Section 4.2, line 3: suggest replacing "defined" with "specified" so that "definition" and "defined" don't occur so close to each other. I think it reads a bit better with that change. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Thu Jan 28 21:48:40 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7CB1B3E5F for ; Thu, 28 Jan 2016 21:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 FMbcY3xkyTjF for ; Thu, 28 Jan 2016 21:48:35 -0800 (PST) Received: from xsmtp02.mail2web.com (xsmtp02.mail2web.com [168.144.250.215]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12911B39D9 for ; Thu, 28 Jan 2016 21:48:35 -0800 (PST) Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1aP1v4-0008PD-1w for secdir@ietf.org; Fri, 29 Jan 2016 00:48:34 -0500 Received: (qmail 9323 invoked from network); 29 Jan 2016 05:48:28 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 29 Jan 2016 05:48:28 -0000 From: "Christian Huitema" To: , , "'secdir'" Date: Thu, 28 Jan 2016 21:48:33 -0800 Message-ID: <015f01d15a58$b1a53070$14ef9150$@huitema.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0160_01D15A15.A3843A60" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdFaWFzsfFgj+Jo0RK++cct7ULABhQ== Content-Language: en-us Archived-At: Subject: [secdir] Secdir review of draft-ietf-rtgwg-mrt-frr-architecture-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 05:48:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0160_01D15A15.A3843A60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. The draft presents an architecture for quickly repairing routes after a = link=20 break or a node failure, in a network managed using OSPF or IS-IS. Classic solutions repair the routing after routing updates propagate = across=20 the network, but in the interim the routing can be imperfect, with the=20 possibility of micro loops causing local bouts of congestion. The = proposed=20 solution is to precompute two sets of "backup routes," to activate one = of=20 them immediately after failure, and to revert to shortest path routing when the routing protocol has converged again. The = architecture draft provide justification and guidelines for implementing that = solution. The main focus of my review was the security aspects of the solution. = From that point of view, the document is ready for publication.=20 On the other hand, I struggled with the prolific use of acronyms, some = of which=20 are not spelled out in the text. I wish this could be fixed. This is an architecture document, and the security considerations are = thus=20 somewhat abstract. They point two potential issues: an attacker crafting packet headers to send packets on the longer backup routes and thus=20 creating extra load on the network; and an attacker injecting false=20 "backup" information in the routing network to send some traffic through an unexpected route where it could be inspected by a third party. I = tried to come up with different attacks, but the worse I can think off is an attackers taking control of a router through a virus or a phishing = attack. Such attackers could certainly use the backup routing information in creative ways, but then they could also do lots of damage by = manipulating the regular OSPF or IS-IS data. In short, I don't think that the = addition of backup routes opens big new risks, apart from the two listed in the security considerations. The document is generally well written but the authors have an annoying=20 fondness for acronyms. Some of these acronyms, like the LDP in the = title, must be completely obvious for the WG members, but I had to actually do a lookup to understand that this was about the Label Distribution=20 Protocol used by MPLS. A bit later, I was really wondering what Forward Error Correction had to do with the problem, until I realized that FEC actually stood for Forward Equivalence Class. Most of the acronyms used are spelled out the first time they are used in the text, which is good, = but given the wide usage it would be even better if there was some kind of lexicon.=20 Also, it would be nice if there was some kind of "expected reading" at = or near the introduction, so the average reader could become familiar with=20 the problem and the vocabulary before studying this document. - -- Christian Huitema -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using gpg4o v3.5.53.6558 - http://www.gpg4o.com/ Charset: utf-8 iQEcBAEBAgAGBQJWqv0vAAoJELba05IUOHVQMUUH/jtChUOM9wZkBgDKATsufdpH do1g66lk8ZNfIufVRe8UVNm+668GJIbII4GDj6GUJHfbYMtVktSe3LPP0DG7hMl6 IFODITiycjgUmp0bA+ya63PA4Q4HgIqv4+ES2GZjoe2c0Kx1/qN2lNz2oIraqAJL PYB2IrUBrRvMADseXipcq3nDQs6qbGsWWG/QsdXW9vX54AbI0UdV1MbkqlquGdgu 0CCbcH1IbQKsTWv1kewW5S4gwW+9/ksCJZSMlPCN4/L4F8kazJLBTxp2ecZJJo5V /kS3aO/13l87mzpeBZsD5stCOVMZmW1g4V4MBlvpezol8JBXvdVyGXB82mrUE4w=3D =3D1a4k -----END PGP SIGNATURE----- ------=_NextPart_000_0160_01D15A15.A3843A60 Content-Type: application/octet-stream; name="934309B255C80D72_huitema@huitema.net.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="934309B255C80D72_huitema@huitema.net.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1 Comment: Using gpg4o v3.5.53.6558 - http://www.gpg4o.com/ mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEko OdXpvcOSHWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wd VxSr5d0alExVv/LOI/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG 9KRzSG0giaJWBfUFiGb4lvsyIaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/fo UUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZolpH8SUFUJbmi+zYRuUgcXgMZRmZFL1t u6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEBAAG0J0NocmlzdGlhbiBIdWl0 ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUCUhFfyAIbLwcLCQgH AwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6mVqGIp0Jc ZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LM ktngT/k36+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vg DLK3SuruG1CSHcR0D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9Bzq AidcY/EjTaoea46HXALk/eJd6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLR cl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTVCC9QiAf6QTIjW+lie5J44Ad++0k8gRgA NZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG5rc2E+ih6Dg61Y5PQakm9OwP IsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZbd3+EjFxSLIQogt2 9sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5oG+d0ZSp0 lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUC UhFfyAIbLgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlB B/94RsCJepNvmi/cYiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJM yYT2mp4IsirZHxz/5lqkw9AztcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8spp jtWur6Pm+wnAHp0mQ7GidhxHccFCl65wuT7S/ocb1MjrTgnAMiz+x87d48n1UJ7y IdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq4/HVgfurb4+fd74PV/CC/dmd 7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzzBeXm263lHh+kFxkh 2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrTu4gtdZAi hwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0 +G3nhKr7jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8U cVCGOEHXRP/aubiwNgawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8 h1UbdEOc4+TiYwY1TBuIKltY1cnrjgAWUh/Ucvr++/KbD9tD6C8= =7WkO -----END PGP PUBLIC KEY BLOCK----- ------=_NextPart_000_0160_01D15A15.A3843A60-- From nobody Fri Jan 29 02:23:32 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52031B2B95; Fri, 29 Jan 2016 02:23:30 -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 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 grlM51FlpYjt; Fri, 29 Jan 2016 02:23:29 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237551B2B94; Fri, 29 Jan 2016 02:23:28 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 219671A0108; Fri, 29 Jan 2016 11:23:27 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MGYTcvu-m0V2; Fri, 29 Jan 2016 11:23:26 +0100 (CET) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id 35F911A0106; Fri, 29 Jan 2016 11:23:26 +0100 (CET) Received: from [10.208.1.99] (10.208.1.99) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.266.1; Fri, 29 Jan 2016 11:23:23 +0100 To: Donald Eastlake , "iesg@ietf.org" , "secdir@ietf.org" , References: From: Johannes Merkle X-Enigmail-Draft-Status: N1110 Message-ID: <56AB3DAF.6010409@secunet.com> Date: Fri, 29 Jan 2016 11:23:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.99] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Subject: Re: [secdir] draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-03 SECDIR review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 10:23:30 -0000 > The Abstract does not mention that this document obsoletes RFC 7630. I > think it is a good practice to include that in the Abstract. That's a good hint. I will do that. > > The first paragraph of the Introduction seems odd to me It says > "This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols. In particular, it defines > additional authentication protocols ..." > While I can't actually say this is actually wrong, the portion of the > MIB it defines is trivial and it seems to me that the meat is in the > specification of the additional authentication protocols. Certainly, > those authentication protocol specifications don't appear in the MIB > portion specified, only identifiers for them. Yet the wording of the > Introduction (... defines a portion of the ... MIB.. In particular, > ...) seems to imply that the definition of the additional > authentication protocols is a subpart of the portion of the MIB. So I > would say the Introduction should begin with something like: > "This document specified additional authentication protocols ... In > addition, it defines a portion of the Management Information Base > (MIB) containing identifiers for these authentication protocols for > use with network management protocols." > Alternatively, the introduction could be rephrased in the line of that of RFC 3826, e.g., Within the Architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks [RFC3411], the User-based Security Model (USM) [RFC3414] for SNMPv3 is defined as a Security Subsystem within an SNMP engine. In RFC 3414, two different authentication protocols, HMAC-MD5-96 and HMAC-SHA-96, are defined based on the hash functions MD5 and SHA-1, respectively. This memo specifies new HMAC-SHA-2 authentication protocols for USM... IMHO that would be a better start. -- Johannes From nobody Sun Jan 31 09:50:25 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558B81B2B2D; Sun, 31 Jan 2016 09:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 OUEZp9uHnIDh; Sun, 31 Jan 2016 09:50:19 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F065C1B2B2C; Sun, 31 Jan 2016 09:50:18 -0800 (PST) Received: by mail-ob0-x233.google.com with SMTP id wb13so68590404obb.1; Sun, 31 Jan 2016 09:50:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wWgkBLR0QXK/1DL7JamSP5lTTzn9/wfeUJTuV00M5yA=; b=s8YZU6KDvd74vm7P3Hq2eagb+BxMGo/OCyy8IHYsGKMxC2U6V2gZ9d1vOk2ghb5s8e ikHOnaNjd33K3FJ2uWlMeuTSybJRVTbkuw5UtacEPA/U6cgZj055fLGSZpZzQFJ8S8wS 82U/Qu3SvWagPJomXTgno9IYW3JENMwBAcgwDo1h3Is+71Dfe3jiFXU8t4+1VMP5e1vg LDWMDHzS7aAr+sDv/DdRsrq/jrOa52UIB1Z5aBGvBvpABlGrHVgr/kuj/NlCOm34l8h1 k/ZGP2a0vtPm461PxdoIfvpdo/K/lFEsQ7qZNL2eLcf0pEsORJA28pBIHth76ieGKMb0 ZaXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wWgkBLR0QXK/1DL7JamSP5lTTzn9/wfeUJTuV00M5yA=; b=bS3nf3+JoN98FJJE/JLnHFsSkQgqTaiSyJw7pgncmddevzKE1jAV7VGiMT8nPRQ5MA KDVn8xv8QD/3X/t01Gg7g64h3b3xtI5pflgSaYi+4O91RDgl1u5vPpANS7+6mjKvtcsE gcv+oo9IyVSJi3gn0hnvhi3KGz8CWzekZByQFWPbfpDgD7RjdY/etnmYcKlJLhfmSxFE FoBbUTp6ZiP2Q8TfKUMHSqQAzeiEfxYs5xVgNzKMZsxb2QVawbrfl3dGjtu/Ifru92Gl +Kmerp19P07KZnbVzPkRpENsJajxEP2gID/MIlCuPjm9IE8eCL9zUKlSwvePaPhF9iYJ a7bg== X-Gm-Message-State: AG10YOS+t+kS4WGxkD33TES0cQfVvP1c9+121sT1T2bU5oENNhVxl73FHXzGwY6B9hc83kkHUjvg4dnmIlBAvg== MIME-Version: 1.0 X-Received: by 10.182.88.196 with SMTP id bi4mr14525570obb.56.1454262618344; Sun, 31 Jan 2016 09:50:18 -0800 (PST) Received: by 10.157.26.28 with HTTP; Sun, 31 Jan 2016 09:50:18 -0800 (PST) In-Reply-To: <000901d14157$7052a680$50f7f380$@nict.go.jp> References: <000901d14157$7052a680$50f7f380$@nict.go.jp> Date: Sun, 31 Jan 2016 09:50:18 -0800 Message-ID: From: Julien Laganier To: Takeshi Takahashi Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-hip-rfc523-bis.all@tools.ietf.org, The IESG , hip-chairs@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-hip-rfc5203-bis-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 17:50:21 -0000 Takahashi san, Thank you for reviewing the document, and my apologies for the belated reply. Please find my answers to your comments/questions inlined below: On Mon, Dec 28, 2015 at 2:06 AM, Takeshi Takahashi wrote: [...] > [overall feeling on this draft] > > ready, and good to proceed > > [overview] > > This draft updates RFC 5203 to cope with HIPv2 (RFC 7401). > RFC 5203 specifies a registration mechanism for HIPv1 (RFC 5201). > Likewiise, this draft specifies the mechanism for HIPv2. > > [questions] > > Below are simply clarification questions, and these do not block the further > process of this document. > I am not that familiar with HIP, so it would be helpful if you could provide > me some comments on them to deepen my understanding. > > 1. "If the requester has one or more suitable certificates, the host SHOULD > include them (or just the most suitable one)"(in section 3.3) > > I wonder whether it would be better to let the requester send only the most > suitable certificate. > The requester may send multiple certificates, but it would be helpful if the > requester sends only the most suitable certificate, I guess. (It is easy to > process from the standpoint of the receiver, isn't it?) > Would you explain why the draft encourages to send multiple certificates > rather than sending only the most suitable certificate? As the draft currently states, the suitability of certificates is likely to be application-specific, i.e., dependent on the specific service for which the requester seeks registration -- "How the suitability is determined and how the certificates are obtained is out of scope for this document." For example there may not be a strict ordering of certificates w.r.t. suitability to register, i.e., given two certificates A and B, there isn't necessarily one that is more suitable than the other. For example, a requester for a service may have certificates issued by two ISPs, such as a fixed wireline broadband ISP, and a mobile service provider. These may have brokered roaming agreements with various other parties to optimize topological closeness of the service registrar w.r.t. the requester's current access network. If the requester always include both certificates in its requests, this would avoid having to specify and implement complex certificate selection logic on the requester. > 2. "it SHOULD send the registration request without the CERT parameter to > test whether the registrar accepts the request based on the host's > identity." (in Section 3.3) > > In this situation, if a malicious party knows the identity of the reqester, > the party can get the access right. > Is the identity protected so that no malicious party can get it? The Host Identity is the public component of a public-private key pair, and since completion of the HIP exchange's mutual peer authentication requires knowledge of the private component of the key pair, an attacker knowing the public component would not be able to be granted any service registration based on that knowledge. > 3. "Other documents will define specific values for registration types. See > Section 7 for more information" (Section 4.3) > > I looked at Section 7 to understaind the types and values of Reg Type, but I > guess the section does not define any on them. > Are the types and values completely the same as the ones defined by RFC > 5203? The registration types are defined by the documents defining the service for which registration is being sought, and recorded in the relevant IANA registry. This document does not change the list of services currently being registered with IANA: > 4. "Insufficient resource" and "Invalid certificate" (in the table in > Section 7) > When a requester sends requests without sending CERT parameters, the > requester expects to be authenticated based on its identity. > But sometimes it fails. > In this case, which of the failor type will be used? "Insufficient > resources"? or "Invalid certificate"? or none of them? As the draft currently states: If the requester was not in the allowed list and the registrar requires the requester to authenticate, the registrar MUST check whether the packet also contains a CERT parameter. If the packet does not contain a CERT parameter, the registrar MUST reject the registrations requiring authentication with Failure Type 0 (Registration requires additional credentials). "Registration requires additional credentials" is allocated in the relevant IANA registry: Thanks again for the review. With best regards, --julien From nobody Sun Jan 31 09:52:22 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BBF1B2B34; Sun, 31 Jan 2016 09:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 ymsQGbRoFVBp; Sun, 31 Jan 2016 09:52:15 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14FB31B2B33; Sun, 31 Jan 2016 09:52:15 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id r14so76265751oie.0; Sun, 31 Jan 2016 09:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F4gnItYRGiw0ximKu+B/iA3ezw4xA5KOYv7Szn3z9A4=; b=O0HV8/4TyN6u/wow2V42u3lrLWRjzJhNNryTPsPu/Xa2IkvSPeTwQE74B0wliWUo0s NAwBWP58LZn4Qa3//8UoF7uo67TYAwzMaPDrBWBsUvVHVtDVSN3B1e05skbRiTerk5xq bJUvSNgn1OGTBao73BnpT76nAoEXjxe1I5JnK/IHS6LCLEsXwxP+HUZ0bmnP65rvKC3Q wV8KBX67U1mtS6TTYB4RxJc7C2TsTvxRjSw5knl8M0fps/ZehKsXp3U5TVGosbNN9MrS S4WpI5ziSdt3EqEh2mbZux1dgutJ0lgHL9u5rHwJ3GvJeN1L8O4O3SF7bR9SVqjkVv+k YKLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=F4gnItYRGiw0ximKu+B/iA3ezw4xA5KOYv7Szn3z9A4=; b=L37YyOB1rLCuuIkYs83lvBm60ySdn8a22WjaqCU3qiEGCJUuPnhH2FcrDVI3w6duo1 EPO2kHUqg5nct1QqiBXWDXkbT1Ji90CTGztI9UrPolUkepF0uMx4at+sUaQlTH6GLMLD GLpt7GutcewAPtteUlUrdeG4ZoYmubJpn3M+DvW5nruRaUAICVW4HBFZZKOt6rJ+5oEu P9cDR7eP0EFRGQQupEus9QrM4l9JtK5H7MjCyCAWSQwhnXqWZpoBDOYPDGZcuVf583De wwNusNXggtTDMA//LdSuSoqVqArZnHbFgwZef6k9FUNNTVxa+n2wC24gGo9pyxkJvKbj BVpg== X-Gm-Message-State: AG10YOQyx3n0yadmLEKrsVdUYQJMaUfXJGM6qsrQ+DUB6dUji6K50W0HNijyJAJsp7tK99RlLdk+/c/fE2abSQ== MIME-Version: 1.0 X-Received: by 10.202.76.193 with SMTP id z184mr12822843oia.92.1454262734515; Sun, 31 Jan 2016 09:52:14 -0800 (PST) Received: by 10.157.26.28 with HTTP; Sun, 31 Jan 2016 09:52:14 -0800 (PST) In-Reply-To: <000901d14157$7052a680$50f7f380$@nict.go.jp> References: <000901d14157$7052a680$50f7f380$@nict.go.jp> Date: Sun, 31 Jan 2016 09:52:14 -0800 Message-ID: From: Julien Laganier To: Takeshi Takahashi Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-hip-rfc5203-bis.all@ietf.org, The IESG , hip-chairs@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-hip-rfc5203-bis-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 17:52:17 -0000 [resending with corrected typo in the recipient list. apologies for the noise] Takahashi san, Thank you for reviewing the document, and my apologies for the belated reply. Please find my answers to your comments/questions inlined below: On Mon, Dec 28, 2015 at 2:06 AM, Takeshi Takahashi wrote: [...] > [overall feeling on this draft] > > ready, and good to proceed > > [overview] > > This draft updates RFC 5203 to cope with HIPv2 (RFC 7401). > RFC 5203 specifies a registration mechanism for HIPv1 (RFC 5201). > Likewiise, this draft specifies the mechanism for HIPv2. > > [questions] > > Below are simply clarification questions, and these do not block the further > process of this document. > I am not that familiar with HIP, so it would be helpful if you could provide > me some comments on them to deepen my understanding. > > 1. "If the requester has one or more suitable certificates, the host SHOULD > include them (or just the most suitable one)"(in section 3.3) > > I wonder whether it would be better to let the requester send only the most > suitable certificate. > The requester may send multiple certificates, but it would be helpful if the > requester sends only the most suitable certificate, I guess. (It is easy to > process from the standpoint of the receiver, isn't it?) > Would you explain why the draft encourages to send multiple certificates > rather than sending only the most suitable certificate? As the draft currently states, the suitability of certificates is likely to be application-specific, i.e., dependent on the specific service for which the requester seeks registration -- "How the suitability is determined and how the certificates are obtained is out of scope for this document." For example there may not be a strict ordering of certificates w.r.t. suitability to register, i.e., given two certificates A and B, there isn't necessarily one that is more suitable than the other. For example, a requester for a service may have certificates issued by two ISPs, such as a fixed wireline broadband ISP, and a mobile service provider. These may have brokered roaming agreements with various other parties to optimize topological closeness of the service registrar w.r.t. the requester's current access network. If the requester always include both certificates in its requests, this would avoid having to specify and implement complex certificate selection logic on the requester. > 2. "it SHOULD send the registration request without the CERT parameter to > test whether the registrar accepts the request based on the host's > identity." (in Section 3.3) > > In this situation, if a malicious party knows the identity of the reqester, > the party can get the access right. > Is the identity protected so that no malicious party can get it? The Host Identity is the public component of a public-private key pair, and since completion of the HIP exchange's mutual peer authentication requires knowledge of the private component of the key pair, an attacker knowing the public component would not be able to be granted any service registration based on that knowledge. > 3. "Other documents will define specific values for registration types. See > Section 7 for more information" (Section 4.3) > > I looked at Section 7 to understaind the types and values of Reg Type, but I > guess the section does not define any on them. > Are the types and values completely the same as the ones defined by RFC > 5203? The registration types are defined by the documents defining the service for which registration is being sought, and recorded in the relevant IANA registry. This document does not change the list of services currently being registered with IANA: > 4. "Insufficient resource" and "Invalid certificate" (in the table in > Section 7) > When a requester sends requests without sending CERT parameters, the > requester expects to be authenticated based on its identity. > But sometimes it fails. > In this case, which of the failor type will be used? "Insufficient > resources"? or "Invalid certificate"? or none of them? As the draft currently states: If the requester was not in the allowed list and the registrar requires the requester to authenticate, the registrar MUST check whether the packet also contains a CERT parameter. If the packet does not contain a CERT parameter, the registrar MUST reject the registrations requiring authentication with Failure Type 0 (Registration requires additional credentials). "Registration requires additional credentials" is allocated in the relevant IANA registry: Thanks again for the review. With best regards, --julien On Mon, Dec 28, 2015 at 2:06 AM, Takeshi Takahashi wrote: > Hello, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security area > directors. > Document editors and WG chairs should treat these comments just like any > other last call comments. > > [overall feeling on this draft] > > ready, and good to proceed > > [overview] > > This draft updates RFC 5203 to cope with HIPv2 (RFC 7401). > RFC 5203 specifies a registration mechanism for HIPv1 (RFC 5201). > Likewiise, this draft specifies the mechanism for HIPv2. > > [questions] > > Below are simply clarification questions, and these do not block the further > process of this document. > I am not that familiar with HIP, so it would be helpful if you could provide > me some comments on them to deepen my understanding. > > 1. "If the requester has one or more suitable certificates, the host SHOULD > include them (or just the most suitable one)"(in section 3.3) > > I wonder whether it would be better to let the requester send only the most > suitable certificate. > The requester may send multiple certificates, but it would be helpful if the > requester sends only the most suitable certificate, I guess. (It is easy to > process from the standpoint of the receiver, isn't it?) > Would you explain why the draft encourages to send multiple certificates > rather than sending only the most suitable certificate? > > 2. "it SHOULD send the registration request without the CERT parameter to > test whether the registrar accepts the request based on the host's > identity." (in Section 3.3) > > In this situation, if a malicious party knows the identity of the reqester, > the party can get the access right. > Is the identity protected so that no malicious party can get it? > > 3. "Other documents will define specific values for registration types. See > Section 7 for more information" (Section 4.3) > > I looked at Section 7 to understaind the types and values of Reg Type, but I > guess the section does not define any on them. > Are the types and values completely the same as the ones defined by RFC > 5203? > > 4. "Insufficient resource" and "Invalid certificate" (in the table in > Section 7) > When a requester sends requests without sending CERT parameters, the > requester expects to be authenticated based on its identity. > But sometimes it fails. > In this case, which of the failor type will be used? "Insufficient > resources"? or "Invalid certificate"? or none of them? > > Thank you for your kind contributions. > Take > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Sun Jan 31 13:50:43 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6831B2DA8; Sun, 31 Jan 2016 13:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 0zfPeu_yElSf; Sun, 31 Jan 2016 13:50:41 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::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 EA9781B2D97; Sun, 31 Jan 2016 13:50:40 -0800 (PST) Received: by mail-ob0-x229.google.com with SMTP id ba1so104209815obb.3; Sun, 31 Jan 2016 13:50:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Uv89NBXUdjwhcsC+dDl12EVVC0JTZmrdlX9LBeR6Tbg=; b=omrTbLBg0RKPfGFB7iuSnnbiwUj808Qar5plNNJr5Zv+KdtiVtm75TAsmBQAPQmfyA Le4dOntdpZncsLgifB4K5X4ejSONJOE7BT86DaGbD0mwK5GafGuhxAJsBCPWKwjn1zGG GHwlaQIj6+xDpOniYc8aasmIPMAvXD2wx7gM726blhfsfeTKCZC7ebD5mrreU2kJlLxe nOFEstVJT8TrP1/XReCOkxw3jKWS5O71jdji3B3km97UG5/VosGNQRxF3nKX9MKknxhm /R4hXC+K8rZkcM0VM7N3vHR2YKmT6h/kWsXzSTgAKpsvyKQPYJFrRFsQarQBzy6AF+Ue ky4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Uv89NBXUdjwhcsC+dDl12EVVC0JTZmrdlX9LBeR6Tbg=; b=AJkbsAiLo1DvZU+5pzSsZndAjZ4mnk8bdVCoVM8+/2DmKG5JBKNvwZO7MnN3EQO9rL FhLFh6kcbIX8WyFJYcsz6tjWgqIblg8q6uPS6dXWRYTdy69dc+vg5ZbroIK2DfV1RagK 3/fkZqVqD7oc9izfcKTi2oji+5ElD0VjhBzja9Dgrkync/y7qzxT14m8bBpGIGgN56dt Rpueyw+z7be5MCDWFhR2xsbPdMVUgaLGx7YsSDS9ZFn2N6Bg6QuTHQx7hWXrdhSiMDNr VMF0rJzfnfUSiXiScBWx2hhVpp4y60CaEge4v32+FonfoqekqkBToHGcgF0BdeVV85Yl 7Z+g== X-Gm-Message-State: AG10YOSxGOyF9Ana2ekcvJzLJFigTFckW6x1vv8nMaGuSxOoIOXvPtdqofyj5bdCvV8ygKhHWCtH9rDREJphCw== X-Received: by 10.182.225.132 with SMTP id rk4mr14791687obc.68.1454277040344; Sun, 31 Jan 2016 13:50:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.157.161 with HTTP; Sun, 31 Jan 2016 13:50:25 -0800 (PST) In-Reply-To: <56AB3DAF.6010409@secunet.com> References: <56AB3DAF.6010409@secunet.com> From: Donald Eastlake Date: Sun, 31 Jan 2016 16:50:25 -0500 Message-ID: To: Johannes Merkle Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-opsawg-hmac-sha-2-usm-snmp-new.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-03 SECDIR review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 21:50:42 -0000 Hi Johannes, On Fri, Jan 29, 2016 at 5:23 AM, Johannes Merkle wrote: > >> The Abstract does not mention that this document obsoletes RFC 7630. I >> think it is a good practice to include that in the Abstract. > > That's a good hint. I will do that. > >> >> The first paragraph of the Introduction seems odd to me It says >> "This memo defines a portion of the Management Information Base (MIB) >> for use with network management protocols. In particular, it defines >> additional authentication protocols ..." >> While I can't actually say this is actually wrong, the portion of the >> MIB it defines is trivial and it seems to me that the meat is in the >> specification of the additional authentication protocols. Certainly, >> those authentication protocol specifications don't appear in the MIB >> portion specified, only identifiers for them. Yet the wording of the >> Introduction (... defines a portion of the ... MIB.. In particular, >> ...) seems to imply that the definition of the additional >> authentication protocols is a subpart of the portion of the MIB. So I >> would say the Introduction should begin with something like: >> "This document specified additional authentication protocols ... In >> addition, it defines a portion of the Management Information Base >> (MIB) containing identifiers for these authentication protocols for >> use with network management protocols." >> > > Alternatively, the introduction could be rephrased in the line of that of RFC 3826, e.g., > > Within the Architecture for describing Simple Network Management > Protocol (SNMP) Management Frameworks [RFC3411], the User-based > Security Model (USM) [RFC3414] for SNMPv3 is defined as a Security > Subsystem within an SNMP engine. In RFC 3414, two different > authentication protocols, HMAC-MD5-96 and HMAC-SHA-96, are defined > based on the hash functions MD5 and SHA-1, respectively. > > This memo specifies new HMAC-SHA-2 authentication protocols for USM... > > > IMHO that would be a better start. That alternative text looks fine to me. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > -- > Johannes From nobody Sun Jan 31 16:31:11 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AFC1A6FDA; Sun, 31 Jan 2016 16:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 UNZPivpRz3p8; Sun, 31 Jan 2016 16:31:07 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::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 947971A6FD8; Sun, 31 Jan 2016 16:31:07 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id r14so79545475oie.0; Sun, 31 Jan 2016 16:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CbojxUlO/kI50ti4Xrt35fr03QBebrjwkJ1pHnOlEPM=; b=vbS7jH37G1tsSHCBt5KOD5ayIWfPl7WIT0mNNXJl35Xrlr3pgn1bMTRj7+aZl9MyFa j8WopVUin9LJaRfUWsIzgv4uE4fCwi9Pkmd4WLSNElsweVnJCGtWL8CcYvWzdww5vwWM 2Iu/Q9WEsXzxphyykWyFwEjqt5bNtIid6MFAjtRQZqhUsnhJy/BbIe5LHiD8ZMBkcoj+ 6v4YAfCB+94LOZzjKMnPI3eORG1ovifPahMu3YdlGE5KPK3QQrbu9BWmtum4cgFnEqjD oizECZmR3S0+IQqIEDbyOMfUEhKoAlVx43r/3LOgqpqpR8liP5QydVcix4G0CjmZ0g7b utXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CbojxUlO/kI50ti4Xrt35fr03QBebrjwkJ1pHnOlEPM=; b=I6cwrkdUl7it0wo5CL+/dZ/IBTG4+SLRDeALjuvKcfFj1rYM6ulgYxCAZG++QIaQs+ xIqJdvDzGSsvvF/nYObsjm/5Tul2Q4kIMvPpMPDyklNkzGESypGpR2Fvf0h0RHpqJsTL i+TXmMDjC/ZcZq4vdtYl0434GzRrINT/7gJGcD3u2w4ZXHdUgjArcjovkpoGyrkwMluK jwB5mlR/9WdU4UBY5p27+XZqDugexN8wi3Y6fbGy3mtCbOL9+mbKHr7ZJ8HY6qYR8Wju jVQ04xrqyrDJABi9cWJJWBHGWYQDpQL6xB/XC373u9QQjMtUl/juu0TGlhtSXqFdMmUn Iojg== X-Gm-Message-State: AG10YOTRIwL21cgFbVrsJQsJK7f13CP+8DJSjNtZorYlAB+5ro8FD4hiLEJfcY5kIWZs7U+8TytawrKzcmWZkA== MIME-Version: 1.0 X-Received: by 10.202.195.18 with SMTP id t18mr15154994oif.80.1454286666985; Sun, 31 Jan 2016 16:31:06 -0800 (PST) Received: by 10.157.26.28 with HTTP; Sun, 31 Jan 2016 16:31:06 -0800 (PST) In-Reply-To: References: <568A94BF.4000004@si6networks.com> Date: Sun, 31 Jan 2016 16:31:06 -0800 Message-ID: From: Julien Laganier To: Tina TSOU Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "draft-ietf-hip-rfc5205-bis.all@ietf.org" , "Org Iesg@Ietf." , "Org Secdir@Ietf." Subject: Re: [secdir] Secdir Review of draft-ietf-hip-rfc5205-bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 00:31:10 -0000 Tina, Happy new year, and thank you for reviewing the draft. My apologies for the belated reply. Please find my answers to your comments inlined below: On Mon, Jan 4, 2016 at 10:29 AM, Tina TSOU wrote: > [...] > ** Technical ** > > * Section 8: > > You refer to IPSECKEY RR [RFC4025] to note some of the possible threats > for HIP RRs. I think you should spell these out, and discuss them > explicitly. The intent was to provide an informative statement regarding the broad similarity between threats applying to the IPSECKEY RR and threats applying to the HIP RR. The remainder of the section does explicitly discuss the threats pertaining to the HIP RR. I have clarified the text such that the intent is communicated more clearly: In a manner similar to the IPSECKEY RR [RFC4025], the HIP DNS Extension allows for the provision of two HIP nodes with the public keying material (HI) of their peer. These HIs will be subsequently used in a key exchange between the peers. Hence, the HIP DNS Extension is subject, as the IPSECKEY RR, to threats stemming from attacks against unsecured HIP RRs, as described in the remainder of this section. > ** Editorial ** > > * Section 3, page 4: >> In the following, we assume that the Initiator first queries for HIP >> resource records at the Responder FQDN. > > s/at/for/ The use of "at" is consistent with the language found in RFC1035, e.g.: The first step a resolver takes is to transform the client's request, stated in a format suitable to the local OS, into a search specification for RRs _at_ a specific name which match a specific QTYPE and QCLASS. Thus I believe no change need to be made. > * Section 3, page 4: >> and further queries for the same owner name SHOULD NOT be >> made. > > What's an "owner name"? Maybe this should be "domain name", instead? As per RFC1035, a DNS RR is defined as containing a NAME which is defined as "an owner name, i.e., the name of the node to which this resource record pertains.", thus I believe no change need to be made. > * Section 3, page 5: >> Note that storing HIP RR information in the DNS at an FQDN that is >> assigned to a non-HIP node might have ill effects on its reachability >> by HIP nodes. > > s/a/an/ If you're referring to the "a" in "a non-HIP node", I believe that this is the correct spelling since the "non" syllable begins with a consonant onset "n". > * Section 4.2, page 9: >> The RVS >> information may be copied and aligned across multiple RRs, or may be >> different for each one; a host MUST check that the RVS used is >> associated with the HI being used, when multiple choices are >> present." > > There's no matching quote sign for this one. Good catch. I fixed that. Thanks again for the review, and best regards. --julien