From fred@cisco.com Sun Sep 1 14:55:53 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE21411E8263; Sun, 1 Sep 2013 14:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ETxSCzHBOEh; Sun, 1 Sep 2013 14:55:47 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 89C6511E8252; Sun, 1 Sep 2013 14:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3610; q=dns/txt; s=iport; t=1378072547; x=1379282147; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=vUeBn4o3K3dbEocATBjQUtmkC3EDLIwl9ceamp+UACk=; b=fE7J+FZx6digRiXnc4aTqxfphyafkFYIxEa5/MnyXNfAVHljzlheC8ht XPMWeCWdxjFMJjKr3j6s1CF4KCVPkgFe5MJCrrS2ZKMVb/TS+nO9Kchin PGAkpMkJvAiZ78PQ3tg4oEvsV/Ak1qZSsBomxIPX2rPsbin8KlDNI90ni U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAM22I1KrRDoJ/2dsb2JhbABbgwfBc4EeFnSCJAEBAQMBeQULC0ZXGYd8BbkRj38HFoMHgQADiTWGbodSkWaDQBw X-IronPort-AV: E=Sophos;i="4.89,1003,1367971200"; d="asc'?scan'208";a="90816814" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 01 Sep 2013 21:55:46 +0000 Received: from sjc-vpn1-751.cisco.com (sjc-vpn1-751.cisco.com [10.21.98.239]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r81Lrmwv001482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Sep 2013 21:55:45 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_A2ECCDDF-A037-481A-A258-6B386A170966"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Fred Baker In-Reply-To: <20130831232125.19f0ceb6@latte.josefsson.org> Date: Sun, 1 Sep 2013 14:54:56 -0700 Message-Id: <9845B0E6-61E5-4AB8-8639-543226B58432@cisco.com> References: <20130831232125.19f0ceb6@latte.josefsson.org> To: draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org X-Mailer: Apple Mail (2.1508) Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-v6ops-mobile-device-profile-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 21:55:53 -0000 --Apple-Mail=_A2ECCDDF-A037-481A-A258-6B386A170966 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Wearing shepherd hat... I assume you'll have an updated document posted soon. Please work with = Simon and make sure he's satisfied with the updates. On Aug 31, 2013, at 2:21 PM, Simon Josefsson = wrote: > 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. >=20 > This (informational) document list a set of features a 3GPP device is > supposed to be compliant with. The document contain pointers to other > protocols/specifications which contains the real security > considerations for those protocols. As such, I don't think there = could > be any significant security issue with this document. Hence my take > is that the document is Ready with nits (see below). >=20 > A notable point is that there is no discussion or references to IPSec > in the document, nor any of the IPv6 "bugs" (e.g., RFC 5722 and RFC > 6946). There may be other document that could be referenced that = would > lead to improved security, but it is hard to list them all. >=20 > This document seems related to draft-ietf-v6ops-rfc3316bis which > describe another IPv6 profile for 3GPP hosts. The utility of having > two different IPv6 profiles for 3GPP hosts could be discussed, but it > is only a security issue in the marginal sense that complexity often > leads to poor security. >=20 > The security considerations of this document is only pointers to > the security considerations of RFC3316bis, RFC6459, and RFC6092 which > feels underwhelming to me -- especially since the RFC3316bis security > consideration is for the particular profile that RFC3316bis defines. > The security considerations of RFC3316bis wouldn't automatically apply > to the profile defined by draft-ietf-v6ops-mobile-device-profile since > the profiles are different. >=20 > Other notes: >=20 > * The document uses RFC 2119 language "for precision", although I = don't > understand what it means for an Informational document to contain > MUST languages. >=20 > * The document really really should reference RFC 2460. >=20 > * The security consideration contains normative text (REQ#34) that > typically go into the core part of a document. >=20 > * I found REQ#32 a bit too generalized. I believe it is common for > applications to be aware of whether connections are over IPv4 or IPv6 > and behave differently. >> REQ#32: Applications MUST be independent of the underlying IP >> address family. This means applications must be IP version >> agnostic. >=20 > /Simon If at first the idea is not absurd, then there is no hope for it. =20 Albert Einstein --Apple-Mail=_A2ECCDDF-A037-481A-A258-6B386A170966 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 - http://gpgtools.org iD8DBQFSI7ewbjEdbHIsm0MRAsvjAJ0RwzzG3lsfWW+xtq+3NCtgmL99ywCfV5oH 7eUmXKHO7RKolMSD21snuuA= =Ne6u -----END PGP SIGNATURE----- --Apple-Mail=_A2ECCDDF-A037-481A-A258-6B386A170966-- From mohamed.boucadair@orange.com Mon Sep 2 01:39:35 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB1521E80A3; Mon, 2 Sep 2013 01:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1vszhpryGRT; Mon, 2 Sep 2013 01:38:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7243811E81CB; Mon, 2 Sep 2013 01:36:35 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id B7511264321; Mon, 2 Sep 2013 10:36:28 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 9979027C046; Mon, 2 Sep 2013 10:36:28 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 2 Sep 2013 10:36:28 +0200 From: To: Simon Josefsson , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" Date: Mon, 2 Sep 2013 10:36:23 +0200 Thread-Topic: secdir review of draft-ietf-v6ops-mobile-device-profile-04 Thread-Index: Ac6mkBaBpJwCb374SYyhCtkWT/I2iQBIPY1A Message-ID: <94C682931C08B048B7A8645303FDC9F36EF0335DAE@PUEXCB1B.nanterre.francetelecom.fr> References: <20130831232125.19f0ceb6@latte.josefsson.org> In-Reply-To: <20130831232125.19f0ceb6@latte.josefsson.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.2.80316 Subject: Re: [secdir] secdir review of draft-ietf-v6ops-mobile-device-profile-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 08:39:46 -0000 Dear Simon, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Simon Josefsson [mailto:simon@josefsson.org] >Envoy=E9=A0: samedi 31 ao=FBt 2013 23:21 >=C0=A0: secdir@ietf.org; iesg@ietf.org; draft-ietf-v6ops-mobile-device- >profile.all@tools.ietf.org >Objet=A0: secdir review of draft-ietf-v6ops-mobile-device-profile-04 > >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 (informational) document list a set of features a 3GPP device is >supposed to be compliant with. The document contain pointers to other >protocols/specifications which contains the real security >considerations for those protocols. As such, I don't think there could >be any significant security issue with this document. Hence my take >is that the document is Ready with nits (see below). [Med] Thanks for the review. > >A notable point is that there is no discussion or references to IPSec [Med] IPsec is not explicitly mentioned in this document as it is discussed= in these two references cited in the "Security Considerations" section: rf= c3316bis and rfc6092. Is there any particular change you want us make in th= e "Security Considerations" section? Thanks. >in the document, nor any of the IPv6 "bugs" (e.g., RFC 5722 and RFC >6946). There may be other document that could be referenced that would >lead to improved security, but it is hard to list them all. [Med] We didn't included explicit references to RFC5722 and RFC6980 as thos= e are already cited in rfc3316bis. "Security Considerations" refers explici= tly to rfc3316bis. Is there any particular change you want us to make in "S= ecurity Considerations" section? Thanks. > >This document seems related to draft-ietf-v6ops-rfc3316bis which >describe another IPv6 profile for 3GPP hosts. The utility of having >two different IPv6 profiles for 3GPP hosts could be discussed, but it >is only a security issue in the marginal sense that complexity often >leads to poor security. > >The security considerations of this document is only pointers to >the security considerations of RFC3316bis, RFC6459, and RFC6092 which >feels underwhelming to me -- especially since the RFC3316bis security >consideration is for the particular profile that RFC3316bis defines. >The security considerations of RFC3316bis wouldn't automatically apply >to the profile defined by draft-ietf-v6ops-mobile-device-profile since >the profiles are different. [Med] The relationship between the two documents is explained in the introd= uction; in particular: This document defines a different profile than the one for general connection to IPv6 mobile networks defined in [I-D.ietf-v6ops-rfc3316bis]; in particular: o It lists an extended list of required features while [I-D.ietf-v6ops-rfc3316bis] identifies issues and explains how to implement basic IPv6 features in a cellular context. o It identifies also features to ensure IPv4 service delivery over an IPv6-only transport. Because of this difference, this document points to the security considerat= ions of rfc3316bis security section and to RFC6092 because Cellular Devices= with LAN capabilities are within the scope of this document.=20 > >Other notes: > >* The document uses RFC 2119 language "for precision", although I don't > understand what it means for an Informational document to contain > MUST languages. [Med] This use is not specific to this document; see for example: http://to= ols.ietf.org/html/rfc6092#section-1.2. A note was added to the document to = explain this usage. > >* The document really really should reference RFC 2460. [Med] Done. > >* The security consideration contains normative text (REQ#34) that > typically go into the core part of a document. [Med] I made this change: OLD: The security considerations identified in [I-D.ietf-v6ops-rfc3316bis] and [RFC6459] are to be taken into account. REQ#34: If the cellular device provides LAN features, it SHOULD be compliant with the security requirements specified in [RFC6092]. NEW: The security considerations identified in [I-D.ietf-v6ops-rfc3316bis] and [RFC6459] are to be taken into account. Security-related considerations that apply when the cellular device provides LAN features are specified in [RFC6092]. =20 RFC6092 is already called out in the core part of the document. > >* I found REQ#32 a bit too generalized. I believe it is common for > applications to be aware of whether connections are over IPv4 or IPv6 > and behave differently. > >REQ#32: Applications MUST be independent of the underlying IP > > address family. This means applications must be IP version > > agnostic. > [Med] I agree this is a too generalized requirements. We have it on purpose= to encourage applications devs to avoid making assumptions on the underlyi= ng available connectivity. FWIW, our teams tested devices that support IPv6= connectivity... but that embed applications which are broken when IPv6 con= nectivity is enabled (e.g., ip address literals). An education effort is st= ill needed to avoid this kind of brokenness.=20 >/Simon From simon@josefsson.org Mon Sep 2 07:31:30 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82CA21F9123; Mon, 2 Sep 2013 07:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZpk7Bwnfuhy; Mon, 2 Sep 2013 07:31:30 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id DD85C21F90C3; Mon, 2 Sep 2013 07:31:29 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r82EVMpZ029539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Sep 2013 16:31:25 +0200 Date: Mon, 2 Sep 2013 16:31:18 +0200 From: Simon Josefsson To: Message-ID: <20130902163118.0a0e1cb2@latte.josefsson.org> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF0335DAE@PUEXCB1B.nanterre.francetelecom.fr> References: <20130831232125.19f0ceb6@latte.josefsson.org> <94C682931C08B048B7A8645303FDC9F36EF0335DAE@PUEXCB1B.nanterre.francetelecom.fr> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-v6ops-mobile-device-profile-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 14:31:31 -0000 You wrote: > >A notable point is that there is no discussion or references to IPSec > > [Med] IPsec is not explicitly mentioned in this document as it is > discussed in these two references cited in the "Security > Considerations" section: rfc3316bis and rfc6092. Is there any > particular change you want us make in the "Security Considerations" > section? Thanks. No -- that was a general observation. However both rfc3316bis and rfc6092 are informative references in your document, so what you say above combined with... > >in the document, nor any of the IPv6 "bugs" (e.g., RFC 5722 and RFC > >6946). There may be other document that could be referenced that > >would lead to improved security, but it is hard to list them all. > > [Med] We didn't included explicit references to RFC5722 and RFC6980 > as those are already cited in rfc3316bis. "Security Considerations" > refers explicitly to rfc3316bis. Is there any particular change you > want us to make in "Security Considerations" section? Thanks. ...what you say here makes it sounds as if rfc3316bis should be a normative reference to me. It seems like reading rfc3316bis is essential to get a good understanding of this document. > >This document seems related to draft-ietf-v6ops-rfc3316bis which > >describe another IPv6 profile for 3GPP hosts. The utility of having > >two different IPv6 profiles for 3GPP hosts could be discussed, but it > >is only a security issue in the marginal sense that complexity often > >leads to poor security. > > > >The security considerations of this document is only pointers to > >the security considerations of RFC3316bis, RFC6459, and RFC6092 which > >feels underwhelming to me -- especially since the RFC3316bis security > >consideration is for the particular profile that RFC3316bis defines. > >The security considerations of RFC3316bis wouldn't automatically > >apply to the profile defined by > >draft-ietf-v6ops-mobile-device-profile since the profiles are > >different. > > [Med] The relationship between the two documents is explained in the > introduction; in particular: > > This document defines a different profile than the one for general > connection to IPv6 mobile networks defined in > [I-D.ietf-v6ops-rfc3316bis]; in particular: > > o It lists an extended list of required features while > [I-D.ietf-v6ops-rfc3316bis] identifies issues and explains how > to implement basic IPv6 features in a cellular context. > > o It identifies also features to ensure IPv4 service delivery over > an IPv6-only transport. > > Because of this difference, this document points to the security > considerations of rfc3316bis security section and to RFC6092 because > Cellular Devices with LAN capabilities are within the scope of this > document. OK. > >Other notes: > > > >* The document uses RFC 2119 language "for precision", although I > >don't > > understand what it means for an Informational document to contain > > MUST languages. > > [Med] This use is not specific to this document; see for example: > http://tools.ietf.org/html/rfc6092#section-1.2. A note was added to > the document to explain this usage. OK. > >* The document really really should reference RFC 2460. > > [Med] Done. Thanks. Having a normative reference to 2460 also takes care of my concern about not referring to RFC 5722 and RFC 6946. > [Med] I made this change: > > OLD: > The security considerations identified in > [I-D.ietf-v6ops-rfc3316bis] and [RFC6459] are to be taken into > account. > > REQ#34: If the cellular device provides LAN features, it SHOULD be > compliant with the security requirements specified in > [RFC6092]. > > NEW: > The security considerations identified in > [I-D.ietf-v6ops-rfc3316bis] and [RFC6459] are to be taken into > account. > > Security-related considerations that apply when the cellular device > provides LAN features are specified in [RFC6092]. > > RFC6092 is already called out in the core part of the document. Thanks, this seems clearer to me. > >* I found REQ#32 a bit too generalized. I believe it is common for > > applications to be aware of whether connections are over IPv4 or > > IPv6 and behave differently. > > >REQ#32: Applications MUST be independent of the underlying IP > > > address family. This means applications must be IP version > > > agnostic. > > > > [Med] I agree this is a too generalized requirements. We have it on > purpose to encourage applications devs to avoid making assumptions on > the underlying available connectivity. FWIW, our teams tested devices > that support IPv6 connectivity... but that embed applications which > are broken when IPv6 connectivity is enabled (e.g., ip address > literals). An education effort is still needed to avoid this kind of > brokenness. I understand and completely agree! /Simon From shanna@juniper.net Mon Sep 2 18:46:02 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA58521F9F88; Mon, 2 Sep 2013 18:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlz7jljed-lY; Mon, 2 Sep 2013 18:45:44 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0249.outbound.messaging.microsoft.com [213.199.154.249]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5AA21F9F77; Mon, 2 Sep 2013 18:45:41 -0700 (PDT) Received: from mail87-db9-R.bigfish.com (10.174.16.238) by DB9EHSOBE017.bigfish.com (10.174.14.80) with Microsoft SMTP Server id 14.1.225.22; Tue, 3 Sep 2013 01:45:41 +0000 Received: from mail87-db9 (localhost [127.0.0.1]) by mail87-db9-R.bigfish.com (Postfix) with ESMTP id EA7981E00A8; Tue, 3 Sep 2013 01:45:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zz4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail87-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(164054003)(83322001)(74366001)(81686001)(76576001)(49866001)(63696002)(81342001)(47736001)(4396001)(50986001)(47976001)(33646001)(76176001)(81542001)(46102001)(76796001)(76786001)(51856001)(74316001)(76482001)(54316002)(69226001)(56776001)(81816001)(74876001)(66066001)(80976001)(56816003)(77096001)(80022001)(53806001)(65816001)(54356001)(79102001)(74706001)(59766001)(77982001)(31966008)(83072001)(74502001)(47446002)(74662001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB054; H:BLUPR05MB053.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail87-db9 (localhost.localdomain [127.0.0.1]) by mail87-db9 (MessageSwitch) id 137817273833245_26119; Tue, 3 Sep 2013 01:45:38 +0000 (UTC) Received: from DB9EHSMHS006.bigfish.com (unknown [10.174.16.247]) by mail87-db9.bigfish.com (Postfix) with ESMTP id EDA15100041; Tue, 3 Sep 2013 01:45:37 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS006.bigfish.com (10.174.14.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 3 Sep 2013 01:45:37 +0000 Received: from BLUPR05MB054.namprd05.prod.outlook.com (10.255.210.149) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.353.4; Tue, 3 Sep 2013 01:45:36 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) by BLUPR05MB054.namprd05.prod.outlook.com (10.255.210.149) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 3 Sep 2013 01:45:35 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.120]) by BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.120]) with mapi id 15.00.0745.000; Tue, 3 Sep 2013 01:45:35 +0000 From: Stephen Hanna To: "secdir@ietf.org" , The IESG , "draft-ietf-ccamp-gmpls-g709-framework.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-ccamp-gmpls-g709-framework-14 Thread-Index: Ac6oR0docu720d3jTjWZQdbk5uqGwg== Date: Tue, 3 Sep 2013 01:45:34 +0000 Message-ID: <72b0e920a53e4bb287960dd5df5f6f22@BLUPR05MB053.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 09583628E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [secdir] secdir review of draft-ietf-ccamp-gmpls-g709-framework-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 01:46:02 -0000 I reviewed this document as part of the security directorate's ongoing=20 effort to review all IETF documents being processed by the IESG. These=20 comments were written primarily for the benefit of the security area=20 directors. Document editors and WG chairs should treat these comments=20 just like any other last call comments. This document provides a framework to allow the development of=20 protocol extensions to support Generalized Multi-Protocol Label=20 Switching (GMPLS) and Path Computation Element (PCE) control of=20 Optical Transport Networks (OTN) as specified in ITU-T Recommendation=20 G.709. It's part of a group of four documents pertaining to G.709 that are all proceeding through the IESG. Because I know little about GMPLS, PCE, OTN, or G.709, I found this document to be a bit hard to understand. Probably if I read all the references, I might understand it better. I'm afraid that I don't have time for that. I did review the Security Considerations section and found it to be easy to understand. This section states that the threats posed by an enhanced OTN control plane are no greater than the threats posed by the existing, simpler OTN control plane. That seems reasonable. In addition, the Security Considerations section points to RFC 5920, which contains a thorough analysis of the threats that may be mounted against MPLS/GMPLS networks and the countermeasures that may be employed against these threats. The threats and countermeasures described in RFC 5920 seem to be broad enough to encompass any additional issues raised by this document. My conclusion is that, within my limited scope of understanding of this document, the Security Considerations section is adequate and there are no troubling issues from a security perspective. Thanks, Steve From mohamed.boucadair@orange.com Mon Sep 2 22:52:29 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4404111E817F; Mon, 2 Sep 2013 22:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHlzYT2uKFHd; Mon, 2 Sep 2013 22:52:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A787B11E817B; Mon, 2 Sep 2013 22:52:21 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 0DA5822C6E8; Tue, 3 Sep 2013 07:52:18 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id E1EAC35C048; Tue, 3 Sep 2013 07:52:17 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 3 Sep 2013 07:52:17 +0200 From: To: Simon Josefsson Date: Tue, 3 Sep 2013 07:52:16 +0200 Thread-Topic: secdir review of draft-ietf-v6ops-mobile-device-profile-04 Thread-Index: Ac6n6R9plQc+60qVQA6IOYRwo45VGwAgE3Gw Message-ID: <94C682931C08B048B7A8645303FDC9F36EF033600D@PUEXCB1B.nanterre.francetelecom.fr> References: <20130831232125.19f0ceb6@latte.josefsson.org> <94C682931C08B048B7A8645303FDC9F36EF0335DAE@PUEXCB1B.nanterre.francetelecom.fr> <20130902163118.0a0e1cb2@latte.josefsson.org> In-Reply-To: <20130902163118.0a0e1cb2@latte.josefsson.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.90030 Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-v6ops-mobile-device-profile-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 05:52:29 -0000 Hi Simon, Ok to move rfc3316bis to the normative references.=20 I implemented all the changes we agreed. FWIW, I will send you a message wh= en the new revision is available online. Many thanks for your review. Much appreciated. Cheers, Med >-----Message d'origine----- >De=A0: Simon Josefsson [mailto:simon@josefsson.org] >Envoy=E9=A0: lundi 2 septembre 2013 16:31 >=C0=A0: BOUCADAIR Mohamed IMT/OLN >Cc=A0: secdir@ietf.org; iesg@ietf.org; draft-ietf-v6ops-mobile-device- >profile.all@tools.ietf.org >Objet=A0: Re: secdir review of draft-ietf-v6ops-mobile-device-profile-04 > >You wrote: > >> >A notable point is that there is no discussion or references to IPSec >> >> [Med] IPsec is not explicitly mentioned in this document as it is >> discussed in these two references cited in the "Security >> Considerations" section: rfc3316bis and rfc6092. Is there any >> particular change you want us make in the "Security Considerations" >> section? Thanks. > >No -- that was a general observation. However both rfc3316bis and >rfc6092 are informative references in your document, so what you say >above combined with... > >> >in the document, nor any of the IPv6 "bugs" (e.g., RFC 5722 and RFC >> >6946). There may be other document that could be referenced that >> >would lead to improved security, but it is hard to list them all. >> >> [Med] We didn't included explicit references to RFC5722 and RFC6980 >> as those are already cited in rfc3316bis. "Security Considerations" >> refers explicitly to rfc3316bis. Is there any particular change you >> want us to make in "Security Considerations" section? Thanks. > >...what you say here makes it sounds as if rfc3316bis should be a >normative reference to me. It seems like reading rfc3316bis is >essential to get a good understanding of this document. > >> >This document seems related to draft-ietf-v6ops-rfc3316bis which >> >describe another IPv6 profile for 3GPP hosts. The utility of having >> >two different IPv6 profiles for 3GPP hosts could be discussed, but it >> >is only a security issue in the marginal sense that complexity often >> >leads to poor security. >> > >> >The security considerations of this document is only pointers to >> >the security considerations of RFC3316bis, RFC6459, and RFC6092 which >> >feels underwhelming to me -- especially since the RFC3316bis security >> >consideration is for the particular profile that RFC3316bis defines. >> >The security considerations of RFC3316bis wouldn't automatically >> >apply to the profile defined by >> >draft-ietf-v6ops-mobile-device-profile since the profiles are >> >different. >> >> [Med] The relationship between the two documents is explained in the >> introduction; in particular: >> >> This document defines a different profile than the one for general >> connection to IPv6 mobile networks defined in >> [I-D.ietf-v6ops-rfc3316bis]; in particular: >> >> o It lists an extended list of required features while >> [I-D.ietf-v6ops-rfc3316bis] identifies issues and explains how >> to implement basic IPv6 features in a cellular context. >> >> o It identifies also features to ensure IPv4 service delivery over >> an IPv6-only transport. >> >> Because of this difference, this document points to the security >> considerations of rfc3316bis security section and to RFC6092 because >> Cellular Devices with LAN capabilities are within the scope of this >> document. > >OK. > >> >Other notes: >> > >> >* The document uses RFC 2119 language "for precision", although I >> >don't >> > understand what it means for an Informational document to contain >> > MUST languages. >> >> [Med] This use is not specific to this document; see for example: >> http://tools.ietf.org/html/rfc6092#section-1.2. A note was added to >> the document to explain this usage. > >OK. > >> >* The document really really should reference RFC 2460. >> >> [Med] Done. > >Thanks. Having a normative reference to 2460 also takes care of my >concern about not referring to RFC 5722 and RFC 6946. > >> [Med] I made this change: >> >> OLD: >> The security considerations identified in >> [I-D.ietf-v6ops-rfc3316bis] and [RFC6459] are to be taken into >> account. >> >> REQ#34: If the cellular device provides LAN features, it SHOULD be >> compliant with the security requirements specified in >> [RFC6092]. >> >> NEW: >> The security considerations identified in >> [I-D.ietf-v6ops-rfc3316bis] and [RFC6459] are to be taken into >> account. >> >> Security-related considerations that apply when the cellular device >> provides LAN features are specified in [RFC6092]. >> >> RFC6092 is already called out in the core part of the document. > >Thanks, this seems clearer to me. > >> >* I found REQ#32 a bit too generalized. I believe it is common for >> > applications to be aware of whether connections are over IPv4 or >> > IPv6 and behave differently. >> > >REQ#32: Applications MUST be independent of the underlying IP >> > > address family. This means applications must be IP version >> > > agnostic. >> > >> >> [Med] I agree this is a too generalized requirements. We have it on >> purpose to encourage applications devs to avoid making assumptions on >> the underlying available connectivity. FWIW, our teams tested devices >> that support IPv6 connectivity... but that embed applications which >> are broken when IPv6 connectivity is enabled (e.g., ip address >> literals). An education effort is still needed to avoid this kind of >> brokenness. > >I understand and completely agree! > >/Simon From benl@google.com Tue Sep 3 06:04:22 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B580E21E8141 for ; Tue, 3 Sep 2013 06:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eMetQmAf2YN for ; Tue, 3 Sep 2013 06:04:22 -0700 (PDT) Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1A97A21E8134 for ; Tue, 3 Sep 2013 06:04:21 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id 6so1471763qea.4 for ; Tue, 03 Sep 2013 06:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A6WqvZmUb8T1Vs95P5QiPJUn+nC1KAcUAAq0SB5afoY=; b=PmZ5posKVeUItKXQTLaqZXLFavORbedJryq59TxXXkfZwj5BFC8DyLniq7RMKl7AdT F0+4R5fVVqkaQt7PoEeqvkC+4IBIWv8RZMUQZk9sOXPJjJ3Tk8kOwCjdD+VLrhq4LDWj YX1pVL0GmzrWRhAoMtp7nur9J9jnxpMNga7IPw9qzKkr/yCG4dy1iw9+7yE8bILqE03I X6ghGCbf5byQDhoawEAVEDx+GwpHYeacmHGtPtAS9fEc8AD8vJlFTKc9SFqWHmQmHnQZ T4M4MPHUYMuF9Lo8hFWsu613DjjMs1gug6ygP4xCBNN9warl/7SH+y/PXgfy6gw0ngLY aCJQ== 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=A6WqvZmUb8T1Vs95P5QiPJUn+nC1KAcUAAq0SB5afoY=; b=OA5BWvtFgmx1IwLrOCr+85gEdQJJ2g4XsNjjt4HT20MPrWz5q3C/Arp3BcXsBwbWLG gsq1CzVioQC8LHaTq2EzNAMTgpav0Ar35Q8+FUoPYlWeKi7T5FhY43LVjcnWFtEBfiPK YqHh1SR3X5Oc1VgpTxSFTM0uIQH5nLOFozP6h+oNq/Vi6pxgIAP6SSXqu4XgUHEMVwRU v79UpVo2ikwU+degZii53kMJwwKoF1qiXEKnGhWJNU0PSDep3STyBU2eakKpUWXE0y2w JldZfQ/d7yvSYKhQY+Lx6+Rx+HAkpkTch8TveLD3+KlhGlaSLcnGYzW/A4VPEYrouu5j 6oFA== X-Gm-Message-State: ALoCoQm+IZ7jkLcCzpDS92MhU4+ME5SpmA/JtVHyJntiCL1n24dvQWvOh+7Vk0cfeAi+W+RStOEso2K6BYfrF+CnoeuXrk6aLPW43t6c2qkR3i5mq4ddBT47r3utx2eK46Jn5CbFXDSEdwbmP3Tpm49Mb6Gj8hV1phbvK2T2aMnoAJK0f88DWghhj+5CYXha5a4PnmN+ObEs MIME-Version: 1.0 X-Received: by 10.49.17.162 with SMTP id p2mr11505969qed.69.1378213461322; Tue, 03 Sep 2013 06:04:21 -0700 (PDT) Received: by 10.229.68.6 with HTTP; Tue, 3 Sep 2013 06:04:21 -0700 (PDT) In-Reply-To: <20977.19493.623188.411131@fireball.kivinen.iki.fi> References: <20977.19493.623188.411131@fireball.kivinen.iki.fi> Date: Tue, 3 Sep 2013 14:04:21 +0100 Message-ID: From: Ben Laurie To: secdir-secretary@mit.edu Content-Type: multipart/alternative; boundary=047d7bea38acc9922204e57a536f Cc: "secdir@ietf.org" Subject: Re: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 13:04:22 -0000 --047d7bea38acc9922204e57a536f Content-Type: text/plain; charset=ISO-8859-1 On 25 July 2013 17:02, Tero Kivinen wrote: > Ben Laurie T 2013-07-25 draft-ietf-emu-crypto-bind-04 I managed to miss this one, and I see it has now timed out, but perhaps worth mentioning, even at this late date, that the existence of this I-D seems to suggest that the protocols they're attempting to fix are badly broken and should never have been standardised! --047d7bea38acc9922204e57a536f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On 25 July 2013 17:02, Tero Kivinen <kivinen@iki.fi> wrote:
=
Ben Laurie =A0 =A0 =A0 =A0 =A0 =A0 T 2013-07-25 draft-ietf-emu-crypto-bind-= 04

I managed to miss this one, and I see it has now t= imed out, but perhaps worth mentioning, even at this late date, that the ex= istence of this I-D seems to suggest that the protocols they're attempt= ing to fix are badly broken and should never have been standardised!

--047d7bea38acc9922204e57a536f-- From derek@ihtfp.com Tue Sep 3 08:36:23 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB3721F9BB6 for ; Tue, 3 Sep 2013 08:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.694 X-Spam-Level: X-Spam-Status: No, score=-101.694 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPL4w2oZp9ev for ; Tue, 3 Sep 2013 08:36:14 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id DD5BE21E814E for ; Tue, 3 Sep 2013 08:36:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 73223260237; Tue, 3 Sep 2013 11:36:12 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 17319-04; Tue, 3 Sep 2013 11:36:06 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 189AC26021A; Tue, 3 Sep 2013 11:36:05 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.5/Submit) id r83Fa3Xi002482; Tue, 3 Sep 2013 11:36:03 -0400 From: Derek Atkins To: Ben Laurie References: <20977.19493.623188.411131@fireball.kivinen.iki.fi> Date: Tue, 03 Sep 2013 11:36:03 -0400 In-Reply-To: (Ben Laurie's message of "Tue, 3 Sep 2013 14:04:21 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: secdir-secretary@mit.edu, "secdir@ietf.org" Subject: Re: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 15:36:23 -0000 Ben Laurie writes: > On 25 July 2013 17:02, Tero Kivinen wrote: > > Ben Laurie =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 T 2013-07-25 dra= ft-ietf-emu-crypto-bind-04 > > I managed to miss this one, and I see it has now timed out, but perhaps w= orth > mentioning, even at this late date, that the existence of this I-D seems = to > suggest that the protocols they're attempting to fix are badly broken and > should never have been standardised! That was a fight we lost a long time ago. This happened so long ago Jeff Schiller was still SecAD. -derek --=20 Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From d3e3e3@gmail.com Tue Sep 3 19:37:18 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E021521E8094; Tue, 3 Sep 2013 19:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.276 X-Spam-Level: X-Spam-Status: No, score=-102.276 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VCIpYP71mUO; Tue, 3 Sep 2013 19:37:17 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id A8E3B21F99E8; Tue, 3 Sep 2013 19:37:14 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wo10so6642286obc.41 for ; Tue, 03 Sep 2013 19:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=jWAYRDZGPddPMZd9vEYlMDGwE6bWyKfPO1l52PzDY6U=; b=m1dVNtVqTnpq0fs3m6lO5X9e0ZC9ltq9iiQnqt0bLqlprIN8BbCzEj9hSVNZ9jNc1y iA5PpDRKd8iMNBFrXjWbROu2hbYzOtEnHQ5qfbP4mahd+gD0ZbBn5e0U0gKjsgDj3lkV NSma4Z0cNkeOyp6vi18XnZ3vkYx2Sh+HSxpDrSagjrrk0ogwAsDhZqRXTm2Hp7vW7v0M 1csTwImCCi22Bz6HUGAJ+43jP+QX2oLLgNLpbMJpJJDGY4dGrF7AvndEoIWl9nAfFXXr LlgCSCGxuV8S9jmFHJFY19SE9NHtAbDF73eCe1HP8PMy6CSF6rTzJoITUwEXDOH3RJQj 9slA== X-Received: by 10.182.113.195 with SMTP id ja3mr394580obb.46.1378262234233; Tue, 03 Sep 2013 19:37:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.131.7 with HTTP; Tue, 3 Sep 2013 19:36:54 -0700 (PDT) From: Donald Eastlake Date: Tue, 3 Sep 2013 22:36:54 -0400 Message-ID: To: "iesg@ietf.org" , draft-ietf-repute-model.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: "secdir@ietf.org" Subject: [secdir] SECDIR Review of draft-ietf-repute-model-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 02:37:18 -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. The Security Consideration section of this draft is fine, considering how high-level this document is, but I think there are some problems in the rest of the document as indicated below. This high-level document describes a general architecture for a reputation-based service and a model for requesting reputation-related data over the Internet. Minor Problems: Section 1: The last sentence of the first paragraph could be read to imply that lack of authentication is the primary cause of spam. In this era of botnets, I don't think that's true. Perhaps "... leads to spam, phishing, and other attacks." should say "... makes spam, phishing, and other attacks even easier than they would otherwise be." or something like that. Section 4.1.1: My guess is that the values of a "Rating" are floating point in the range 0.0 to 1.0 but it doesn't actually say that... If so, why isn't the example "1.0" said to indicate "exact agreement" or the like instead of "strong agreement"? Would 2.0 indicate "very strong agreement". Section 4.2: It appears that "Reputon" and "Response Set" are the same thing. Is that true? If so, my personal opinion is that, while the word "Reputon" may be cute, it should just be tossed as superfluous. Section 5: This section seems in some ways like the heart of the document but is also seems a bit blurry. Even at a high level, I would think that there could be an explicit cardinality associated with these bullet items. That is, it should say for each (or for all in the case it is the same for all of them) if they can be omitted, whether or not they must occur at least once, and if they can occur multiple times. Is "application context" the same as what quality is being rated? I would think not. For example, couldn't the application be "restaurant recommendation" and then couldn't there be, say, four ratings, one for food quality, one for price, one for decor, and one for service? If so, why isn't what the rating measures an additional bullet item or part of the rating score item? On the other hand, the rating score item says "overall rating score" implying there can only be one... Section 6: Suddenly, in this section, for the first time, we have the capitalized word "Target". Why isn't this defined in Section 4 on terminology and definitions? I suppose it means something like the pair of identity of the entity being rated and the application context? Trivia: Section 1: In paragraph 3 the definition of "reputation" uses the word "estimation" in an uncommon way that might confuse some readers. I think it could use something like the word "esteem" instead. The word "opinion" could also be used but would require minor corresponding changes. This occurs within quoted text that looks like it is copied from somewhere else. If so, shouldn't that source be referenced? Section3: The Figure 1 footer should be on the same page as the figure. Section 4.1: In the last sentence of the 2nd paragraph at the end of page 7, I would strongly prefer "specify" to "define" but that might be a personal quirk. From kivinen@iki.fi Thu Sep 5 07:32:39 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE10611E81A6 for ; Thu, 5 Sep 2013 07:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjJp2QmLvxec for ; Thu, 5 Sep 2013 07:32:39 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id A41A811E80EC for ; Thu, 5 Sep 2013 07:32:36 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r85EWW5N003517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 5 Sep 2013 17:32:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r85EWTm8000752; Thu, 5 Sep 2013 17:32:29 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21032.38397.183965.224644@fireball.kivinen.iki.fi> Date: Thu, 5 Sep 2013 17:32:29 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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, 05 Sep 2013 14:32:39 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Sandy Murphy is next in the rotation. For telechat 2013-09-12 Reviewer LC end Draft Dave Cridland T 2013-08-29 draft-ietf-repute-email-identifiers-09 Alan DeKok T 2013-08-29 draft-ietf-repute-media-type-11 Phillip Hallam-Baker TR2013-09-02 draft-ietf-spfbis-4408bis-19 Paul Hoffman TR2013-07-16 draft-ivov-xmpp-cusax-07 Jeffrey Hutzelman T 2013-09-03 draft-ietf-mpls-targeted-mldp-04 Leif Johansson T 2013-09-03 draft-ietf-pim-rfc4601-update-survey-report-02 Vincent Roca T 2013-08-21 draft-ietf-mpls-tp-mip-mep-map-09 Sam Weiler T 2013-08-17 draft-ietf-homenet-arch-10 For telechat 2013-09-26 Carl Wallace T 2013-08-16 draft-ietf-dime-overload-reqs-11 Last calls and special requests: Rob Austein 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Rob Austein 2013-08-29 draft-ietf-netext-update-notifications-08 Dave Cridland - draft-ietf-httpbis-p5-range-23 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-03-30 draft-ietf-roll-terminology-12 Dan Harkins 2013-09-02 draft-ietf-ccamp-gmpls-signaling-g709v3-11 Sam Hartman 2013-09-03 draft-ietf-mediactrl-call-flows-13 Jeffrey Hutzelman 2013-07-16 draft-yusef-dispatch-ccmp-indication-04 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-04 Scott Kelly 2013-09-16 draft-kelsey-intarea-mesh-link-establishment-05 Tero Kivinen 2013-09-24 draft-cotton-rfc4020bis-01 Warren Kumari 2013-09-19 draft-ietf-ccamp-otn-g709-info-model-11 Julien Laganier - draft-ietf-avtcore-rtp-security-options-06 Julien Laganier - draft-ietf-websec-key-pinning-08 Julien Laganier 2013-09-17 draft-ietf-ccamp-swcaps-update-03 Ben Laurie 2013-09-23 draft-ietf-idr-rfd-usable-03 Matt Lepinski 2013-09-24 draft-ietf-l2vpn-pbb-vpls-interop-05 Catherine Meadows 2013-09-23 draft-ietf-l2vpn-vpls-mcast-14 Alexey Melnikov - draft-ietf-payload-rtp-howto-05 Alexey Melnikov 2013-09-23 draft-ietf-pwe3-vccv-impl-survey-results-02 Kathleen Moriarty 2013-10-01 draft-resnick-retire-std1-00 Ondrej Sury 2013-08-16 draft-nandakumar-rtcweb-stun-uri-06 David Waltermire - draft-ietf-repute-considerations-02 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-13 Brian Weis - draft-ietf-radext-dtls-06 Glen Zorn 2012-11-27 draft-ietf-lisp-eid-block-05 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 -- kivinen@iki.fi From paul.hoffman@vpnc.org Thu Sep 5 07:48:20 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB51021F9B90 for ; Thu, 5 Sep 2013 07:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.632 X-Spam-Level: X-Spam-Status: No, score=-102.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qN0ipipG3aZB for ; Thu, 5 Sep 2013 07:48:20 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D142E21F9B12 for ; Thu, 5 Sep 2013 07:48:19 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r85EmHcd071695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 5 Sep 2013 07:48:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9353E398-0AEE-42FF-9BD1-26E324D23832@vpnc.org> Date: Thu, 5 Sep 2013 07:48:18 -0700 To: secdir Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [secdir] Secdir update on draft-ivov-xmpp-cusax X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 14:48:20 -0000 The authors made an excellent set of changes in the latest draft and I = now have no security concerns. --Paul Hoffman= From leifj@sunet.se Thu Sep 5 11:58:23 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2626821F9E3F for ; Thu, 5 Sep 2013 11:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkr5K6GVNWI7 for ; Thu, 5 Sep 2013 11:58:17 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) by ietfa.amsl.com (Postfix) with ESMTP id DA3C621F9B91 for ; Thu, 5 Sep 2013 11:58:15 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id r85IwDea001559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Sep 2013 20:58:13 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.4/8.14.4) with ESMTP id r85IwAlI026781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Sep 2013 20:58:12 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [10.0.0.244] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.1.2) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Thu, 5 Sep 2013 20:58:09 +0200 Message-ID: <5228D440.8040005@sunet.se> Date: Thu, 05 Sep 2013 20:58:08 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: draft-ietf-pim-rfc4601-update-survey-report.all@tools.ietf.org, secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09KluWd3U - 5e3351abe3a3 - 20130905 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: [secdir] secdir review of draft-ietf-pim-rfc4601-update-survey-report-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 18:58:24 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is an implementation report for PIM-SM to provide supporting documentation for progressing PIM-SM to Internet Standard. Note: I am in no way an expert on multicast. Nit: The document is inconsistent when it comes to spelling out abbreviations, eg RP is never spelled out. The only other comment I have is that the security considerations section says "no implications" while 2.4 argues for the removal of PMBR which features in the security implications section of RFC4601. I don't know if the removal of PMBR makes things better or worse but the security considerations section maybe should provide a word or two of comment on this. Cheers Leif From vincent.roca@inria.fr Fri Sep 6 02:44:36 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DEA21E80DF; Fri, 6 Sep 2013 02:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMMSCcMZ5zYB; Fri, 6 Sep 2013 02:44:30 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id 065CC21E81D4; Fri, 6 Sep 2013 02:44:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,853,1371074400"; d="scan'208";a="31762008" Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 06 Sep 2013 11:44:27 +0200 From: Vincent Roca Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 6 Sep 2013 11:44:27 +0200 Message-Id: <20500220-AB0E-46C7-B3EE-5738C7D8446F@inria.fr> To: IESG , draft-ietf-mpls-tp-mip-mep-map.all@tools.ietf.org, secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [secdir] Secdir review of draft-ietf-mpls-tp-mip-mep-map-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 09:44:37 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. -- This document refers to [RFC6371] and [RFC6941] for detailed security discussions. I have no problem with that. However I have two comments: 1/ It says: "Implementations therefore are required to offer security mechanisms for OAM. Deployments are strongly advised to use such mechanisms." These sentences do not use the RFC2119 key words. Is that deliberate? 2/ I really have problems understanding the following claim: "Mixing of per-node and per-interface OAM on a single node is not advised as OAM message leakage could be the result." Can you be more explicit in the I-D? It's important since it's probably not discussed in [RFC6371] and [RFC6941]. Minor comments: ** MEP is used without being defined. Cheers, Vincent From adrian@olddog.co.uk Fri Sep 6 20:25:03 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A9321F9DA3; Fri, 6 Sep 2013 20:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dt8WHW8aSbKf; Fri, 6 Sep 2013 20:24:56 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 4499C21F9D17; Fri, 6 Sep 2013 20:24:55 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r873OskV021317; Sat, 7 Sep 2013 04:24:54 +0100 Received: from 950129200 ([119.225.221.74]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r873OlQP021289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 7 Sep 2013 04:24:51 +0100 From: "Adrian Farrel" To: "'Vincent Roca'" References: <20500220-AB0E-46C7-B3EE-5738C7D8446F@inria.fr> In-Reply-To: <20500220-AB0E-46C7-B3EE-5738C7D8446F@inria.fr> Date: Sat, 7 Sep 2013 04:24:47 +0100 Message-ID: <0bb101ceab79$d1c0d070$75427150$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHNVAcSvtuGrBOkL1i0/8IXDm1dx5m8Segg Content-Language: en-gb Cc: 'IESG' , draft-ietf-mpls-tp-mip-mep-map.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-mpls-tp-mip-mep-map-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 03:25:03 -0000 Hi Vincent, Thanks for your time. > This document refers to [RFC6371] and [RFC6941] for detailed security > discussions. I have no problem with that. However I have two comments: > > 1/ It says: > "Implementations therefore are required to offer security mechanisms > for OAM. Deployments are strongly advised to use such mechanisms." > These sentences do not use the RFC2119 key words. Is that deliberate? Yes. This is an Informational and Design Considerations document, not a protocol spec. The normal English language seemed perfectly fine for conveying the consensus of the WG. > 2/ I really have problems understanding the following claim: > "Mixing of per-node and per-interface OAM on a single node is not > advised as OAM message leakage could be the result." > Can you be more explicit in the I-D? It's important since it's probably not > discussed in [RFC6371] and [RFC6941]. It seemed to the authors (and the WG - in fact, I recall this text coming from the WG review) that an implementation that attempts to handle per interface OAM and per node OAM is almost certain to get confused and send the wrong OAM messages at the wrong time. I would not go as far as to suggest that the quoted text is particularly important, and the only way I can think to clarify it would be by adding "unless an implementation is particularly well designed and tested." > Minor comments: > > ** MEP is used without being defined. You're right! Amazed that it slipped through. Thanks. Cheers, Adrian From superuser@gmail.com Sat Sep 7 14:57:39 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0001C21F9F51; Sat, 7 Sep 2013 14:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwPUIwu+VgYL; Sat, 7 Sep 2013 14:57:37 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2D13E21F9F31; Sat, 7 Sep 2013 14:57:36 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id m14so4112707wgh.31 for ; Sat, 07 Sep 2013 14:57:36 -0700 (PDT) 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=a+7HwcKr3MrLSSFYwFO9uVthrcE+2v/am/7qMLFFCqo=; b=REEh6jPqR0hSeL2ARaCNB3jza/miNSbbV/DK6IOVeQ01TPo9X5ViUcWLs81XGHE3Lg TbrFLqo/nceluBFsTRvNPHm08mXEtgCyiXUDliJ7w/T9z99ckN6tuLHAy2BTxs9Lrk6p 51qtKLmpPCz+nTH3xJNwA43apfMXhGmrMXtdmf32nOZcoC5LppPegezhwqvgrIVs0k8s 7yca8CHwgvrmJDUOGVpm4JMsKXy+RaRJvxO7pSeqFb2Jw7NWKo21WpTln4F6fijH3WV1 6ws+BsRzMkWnH9vFz9gXQ66fLwh2kohDj6ke7LhNsvfHuFkfNkIuok01ofNm15iIkllC 21NQ== MIME-Version: 1.0 X-Received: by 10.180.184.107 with SMTP id et11mr3252918wic.60.1378591056359; Sat, 07 Sep 2013 14:57:36 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Sat, 7 Sep 2013 14:57:36 -0700 (PDT) In-Reply-To: References: Date: Sat, 7 Sep 2013 14:57:36 -0700 Message-ID: From: "Murray S. Kucherawy" To: Donald Eastlake Content-Type: multipart/alternative; boundary=001a11c227ee3478b404e5d23ef5 X-Mailman-Approved-At: Sat, 07 Sep 2013 15:13:59 -0700 Cc: draft-ietf-repute-model.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR Review of draft-ietf-repute-model-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 21:57:39 -0000 --001a11c227ee3478b404e5d23ef5 Content-Type: text/plain; charset=ISO-8859-1 Hi Donald, thanks for your comments. Replies inline. On Tue, Sep 3, 2013 at 7:36 PM, Donald Eastlake wrote: > Minor Problems: > > Section 1: > The last sentence of the first paragraph could be read to imply that > lack of authentication is the primary cause of spam. In this era of > botnets, I don't think that's true. Perhaps "... leads to spam, > phishing, and other attacks." should say "... makes spam, phishing, > and other attacks even easier than they would otherwise be." or > something like that. > OK. Section 4.1.1: > My guess is that the values of a "Rating" are floating point in the > range 0.0 to 1.0 but it doesn't actually say that... If so, why isn't > the example "1.0" said to indicate "exact agreement" or the like > instead of "strong agreement"? Would 2.0 indicate "very strong > agreement". > Right, the range is actually spelled out in the media-type document, where ABNF is provided. I'll add that here as well. > Section 5: > This section seems in some ways like the heart of the document but > is also seems a bit blurry. Even at a high level, I would think that > there could be an explicit cardinality associated with these bullet > items. That is, it should say for each (or for all in the case it is > the same for all of them) if they can be omitted, whether or not they > must occur at least once, and if they can occur multiple times. > I've added "at least the following data" since a basic response will include all of those. Additional values might be present in a response within a given application space. This is spelled out more normatively in the media-type document. > Is "application context" the same as what quality is being rated? I > would think not. For example, couldn't the application be "restaurant > recommendation" and then couldn't there be, say, four ratings, one for > food quality, one for price, one for decor, and one for service? If > so, why isn't what the rating measures an additional bullet item or > part of the rating score item? On the other hand, the rating score > item says "overall rating score" implying there can only be one... > In your hypothetical example, the application context would be "restaurant", and the assertions possible would be "food-quality", "price", "decor", and "service". A different rating would be returned for each of those, as requested by the client. > > Section 6: > Suddenly, in this section, for the first time, we have the > capitalized word "Target". Why isn't this defined in Section 4 on > terminology and definitions? I suppose it means something like the > pair of identity of the entity being rated and the application > context? > We don't use "Target" anywhere else, but rather use "subject", so I've changed it to that and de-capitalized all of them. There's no need to introduce a new term so late in the document. > Trivia: > > Section 1: > In paragraph 3 the definition of "reputation" uses the word > "estimation" in an uncommon way that might confuse some readers. I > think it could use something like the word "esteem" instead. The word > "opinion" could also be used but would require minor corresponding > changes. This occurs within quoted text that looks like it is copied > from somewhere else. If so, shouldn't that source be referenced? > I got it from a dictionary, namely http://dictionary.reference.com/browse/reputation. It looks like that's based on the 2013 Random House dictionary. I'll add a citation. > > Section3: > The Figure 1 footer should be on the same page as the figure. > Is there a way to force that in xml2rfc? > > Section 4.1: > In the last sentence of the 2nd paragraph at the end of page 7, I > would strongly prefer "specify" to "define" but that might be a > personal quirk. > Done. Thanks again, -MSK --001a11c227ee3478b404e5d23ef5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Donald, thanks for your comments.=A0 Replies inline.
On Tue, Sep 3, 2= 013 at 7:36 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
Minor Problems:

Section 1:
=A0 The last sentence of the first paragraph could be read to imply that lack of authentication is the primary cause of spam. In this era of
botnets, I don't think that's true. Perhaps "... leads to spam= ,
phishing, and other attacks." should say "... makes spam, phishin= g,
and other attacks even easier than they would otherwise be." or
something like that.

OK.

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Section 4.1.1:
=A0 My guess is that the values of a "Rating" are floating point = in the
range 0.0 to 1.0 but it doesn't actually say that... If so, why isn'= ;t
the example "1.0" said to indicate "exact agreement" or= the like
instead of "strong agreement"? Would 2.0 indicate "very stro= ng
agreement".

Right, the range is ac= tually spelled out in the media-type document, where ABNF is provided.=A0 I= 'll add that here as well.


Section 5:
=A0 This section seems in some ways like the heart of the document but
is also seems a bit blurry. Even at a high level, I would think that
there could be an explicit cardinality associated with these bullet
items. That is, it should say for each (or for all in the case it is
the same for all of them) if they can be omitted, whether or not they
must occur at least once, and if they can occur multiple times.

I've added "at least the following data&q= uot; since a basic response will include all of those.=A0 Additional values= might be present in a response within a given application space.=A0 This i= s spelled out more normatively in the media-type document.
=A0
=A0 Is "application context" the same as what quality is being ra= ted? I
would think not. For example, couldn't the application be "restaur= ant
recommendation" and then couldn't there be, say, four ratings, one= for
food quality, one for price, one for decor, and one for service? If
so, why isn't what the rating measures an additional bullet item or
part of the rating score item? On the other hand, the rating score
item says "overall rating score" implying there can only be one..= .

In your hypothetical example, the app= lication context would be "restaurant", and the assertions possib= le would be "food-quality", "price", "decor",= and "service".=A0 A different rating would be returned for each = of those, as requested by the client.
=A0

Section 6:
=A0 Suddenly, in this section, for the first time, we have the
capitalized word "Target". Why isn't this defined in Section = 4 on
terminology and definitions? I suppose it means something like the
pair of identity of the entity being rated and the application
context?

We don't use "Target&= quot; anywhere else, but rather use "subject", so I've change= d it to that and de-capitalized all of them.=A0 There's no need to intr= oduce a new term so late in the document.


Trivia:

Section 1:
=A0 In paragraph 3 the definition of "reputation" uses the word "estimation" in an uncommon way that might confuse some readers. = I
think it could use something like the word "esteem" instead. The = word
"opinion" could also be used but would require minor correspondin= g
changes. This occurs within quoted text that looks like it is copied
from somewhere else. If so, shouldn't that source be referenced?

I got it from a dictionary, namely http://dictionary.refer= ence.com/browse/reputation. It looks like that's based on the 2013 = Random House dictionary.=A0 I'll add a citation.
=A0

Section3:
=A0 The Figure 1 footer should be on the same page as the figure.

Is there a way to force that in xml2rfc?
=A0<= br>

Section 4.1:
=A0 In the last sentence of the 2nd paragraph at the end of page 7, I
would strongly prefer "specify" to "define" but that mi= ght be a
personal quirk.

Done.

=
Thanks again,

-MSK
--001a11c227ee3478b404e5d23ef5-- From d3e3e3@gmail.com Sat Sep 7 17:59:56 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D39C21E8084; Sat, 7 Sep 2013 17:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.283 X-Spam-Level: X-Spam-Status: No, score=-102.283 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vV1QKjG2Cggp; Sat, 7 Sep 2013 17:59:55 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED4E21E8064; Sat, 7 Sep 2013 17:59:55 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so4865875pab.27 for ; Sat, 07 Sep 2013 17:59:55 -0700 (PDT) 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=qHLCtXbR2AJgtTE8XQniahp/gvJXv/UCVPvoxdE+S6U=; b=Bf9a4DUag/xrJCIpdBZPLVOdzV6L5ENmVVAT6yQVYkxbxgyTLsasXC7WNdGroMQHs6 s4lvhjr0K8l54ImlzW4/lGvb+FvTk0Hn0xtijB6PyRP+I7ngChWmHGM4K76ezMUvubwO UwVzlUIHrCwX9aG+dwp/hqCGuxRN3WHIFErmCk9XhZcEK44xhExsOAP4pNNFcMZhw3l+ QmgAfBumzoVJP7HZR8hiHzCwaNLl741r14q9pd2ooWByNIIaOKBnL4DpufX6jMcjS06H liqtgdgRPylcsHZgOzi+zP07+0YIvCC1IqIXQqAnmJogLSeHI58WsW6HeygnmJvBBCKx m0Tg== X-Received: by 10.66.161.138 with SMTP id xs10mr12226379pab.56.1378601994525; Sat, 07 Sep 2013 17:59:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.91.143 with HTTP; Sat, 7 Sep 2013 17:59:34 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Sat, 7 Sep 2013 20:59:34 -0400 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-repute-model.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR Review of draft-ietf-repute-model-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 00:59:56 -0000 Hi Murray, Thanks, for the response. It looks good. On Sat, Sep 7, 2013 at 5:57 PM, Murray S. Kucherawy wrote: > Hi Donald, thanks for your comments. Replies inline. > > On Tue, Sep 3, 2013 at 7:36 PM, Donald Eastlake wrote: >> >> Minor Problems: >> >> Section 1: >> The last sentence of the first paragraph could be read to imply that >> lack of authentication is the primary cause of spam. In this era of >> botnets, I don't think that's true. Perhaps "... leads to spam, >> phishing, and other attacks." should say "... makes spam, phishing, >> and other attacks even easier than they would otherwise be." or >> something like that. > > > OK. > >> Section 4.1.1: >> My guess is that the values of a "Rating" are floating point in the >> range 0.0 to 1.0 but it doesn't actually say that... If so, why isn't >> the example "1.0" said to indicate "exact agreement" or the like >> instead of "strong agreement"? Would 2.0 indicate "very strong >> agreement". > > > Right, the range is actually spelled out in the media-type document, where > ABNF is provided. I'll add that here as well. > >> >> Section 5: >> This section seems in some ways like the heart of the document but >> is also seems a bit blurry. Even at a high level, I would think that >> there could be an explicit cardinality associated with these bullet >> items. That is, it should say for each (or for all in the case it is >> the same for all of them) if they can be omitted, whether or not they >> must occur at least once, and if they can occur multiple times. > > > I've added "at least the following data" since a basic response will include > all of those. Additional values might be present in a response within a > given application space. This is spelled out more normatively in the > media-type document. > >> >> Is "application context" the same as what quality is being rated? I >> would think not. For example, couldn't the application be "restaurant >> recommendation" and then couldn't there be, say, four ratings, one for >> food quality, one for price, one for decor, and one for service? If >> so, why isn't what the rating measures an additional bullet item or >> part of the rating score item? On the other hand, the rating score >> item says "overall rating score" implying there can only be one... > > > In your hypothetical example, the application context would be "restaurant", > and the assertions possible would be "food-quality", "price", "decor", and > "service". A different rating would be returned for each of those, as > requested by the client. > >> >> >> Section 6: >> Suddenly, in this section, for the first time, we have the >> capitalized word "Target". Why isn't this defined in Section 4 on >> terminology and definitions? I suppose it means something like the >> pair of identity of the entity being rated and the application >> context? > > > We don't use "Target" anywhere else, but rather use "subject", so I've > changed it to that and de-capitalized all of them. There's no need to > introduce a new term so late in the document. > >> >> Trivia: >> >> Section 1: >> In paragraph 3 the definition of "reputation" uses the word >> "estimation" in an uncommon way that might confuse some readers. I >> think it could use something like the word "esteem" instead. The word >> "opinion" could also be used but would require minor corresponding >> changes. This occurs within quoted text that looks like it is copied >> from somewhere else. If so, shouldn't that source be referenced? > > > I got it from a dictionary, namely > http://dictionary.reference.com/browse/reputation. It looks like that's > based on the 2013 Random House dictionary. I'll add a citation. > >> Section3: >> The Figure 1 footer should be on the same page as the figure. > > > Is there a way to force that in xml2rfc? I don't know. I use nroff where it is simple to do such things. >> Section 4.1: >> In the last sentence of the 2nd paragraph at the end of page 7, I >> would strongly prefer "specify" to "define" but that might be a >> personal quirk. > > > Done. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Thanks again, > > -MSK From alexey.melnikov@isode.com Sun Sep 8 09:39:16 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21A621F830F; Sun, 8 Sep 2013 09:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.337 X-Spam-Level: X-Spam-Status: No, score=-103.337 tagged_above=-999 required=5 tests=[AWL=-0.738, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4fRTiw-gmTk; Sun, 8 Sep 2013 09:39:11 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 6050F21F8BE6; Sun, 8 Sep 2013 09:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1378658350; d=isode.com; s=selector; i=@isode.com; bh=evfUQMXCI/iwEtjqn7bkHO1aNu21CQJFEZEVaP5Cad4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ufIpuLKZ06wx1VaSOM6Sy0Y9oexBG3U/hMtlV+ZjKN7xipEDS08uxJjIlXL+tyCZuH7z41 SIO/geFAkCNDTbIR8B0CVM7SmYBTNgGIbL//2A88JrfbN8LkFgCb3m9k+PFUZCXQkClrfs 4wMvourbs4/Ue5r/zpa1ap+c3XAcW54=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginmedia.com [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 8 Sep 2013 17:39:10 +0100 Message-ID: <522CA828.1010103@isode.com> Date: Sun, 08 Sep 2013 17:39:04 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: IESG , draft-ietf-pwe3-vccv-impl-survey-results.all@tools.ietf.org, secdir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Secdir review of draft-ietf-pwe3-vccv-impl-survey-results-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 16:39:16 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. -- Most pseudowire Emulation Edge-to-Edge (PWE3) encapsulations mandate the use of the Control Word (CW) to carry information essential to the emulation, to inhibit Equal-Cost Multipath (ECMP) behavior, and to discriminate Operations, Administration, and Maintenance (OAM) from Pseudowire (PW) packets. However, some encapsulations treat the Control Word as optional. As a result, implementations of the CW, for encapsulations for which it is optional, vary by equipment manufacturer, equipment model and service provider network. Similarly, Virtual Circuit Connectivity Verification (VCCV) supports three Control Channel (CC) types and multiple Connectivity Verification (CV) Types. This flexibility has led to reports of interoperability issues within deployed networks and associated drafts to attempt to remedy the situation. This survey of the PW/ VCCV user community was conducted to determine implementation trends. The survey and results are presented in this document. As the document is a survey of what existing implementations do in this area, I agree with editors that it doesn't introduce new security concerns. Editors also clarified that they took precautions to ensure the validity of the sample and the data, in particular they verified email addresses of respondents and that they are representing different companies, not including equipment vendors. I don't have any concerns about security considerations for this document. With no disrespect to document editors, the WG and the shepherding AD, I am however concerns that this document doesn't contain information that is useful for publishing as an RFC. I would be happy to be proven wrong on this. Best Regards, Alexey From carl@redhoundsoftware.com Sun Sep 8 11:46:09 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056BD21E80B7 for ; Sun, 8 Sep 2013 11:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yieW1D2X9QmB for ; Sun, 8 Sep 2013 11:46:03 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id 296D721E80BA for ; Sun, 8 Sep 2013 11:46:02 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id cz12so2943459veb.32 for ; Sun, 08 Sep 2013 11:46:01 -0700 (PDT) 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:message-id :thread-topic:mime-version:content-type:content-transfer-encoding; bh=2lEegntF0BjqpgsHHu3SoYsZT9ijMct2KRvgaSQmCSo=; b=M9PCHqtmHuW2YSC3yICKgldEtmTRJmlLT/rjplKxL3m+HOxYxYZ6bx8lBJ0PIKiCjN Tq1ZPNa5ZYub/oCWkr8gXsj9AMrxad4upQdqaut2B+OJJfC70Xx63w03g1RiBgnsKtpP EX0H0Zd7LFkmwGnAe/nsFVslfTlGoCQfcjd8aXX4wfVTeWzXA3OC4Imc2nz5UMxStmvD r8WnKUExg1ABHTMm9rBRhD4nqf7pRLTNmqjeQ0VohR9TK4YlJ2q2TE/3T2lZo3lO3AVr PPOnTrlUpPb9TMQsZ0Oc/1Fm4gQ1s/uzgtHqW+EzZdDhiJ+j5K/p2ADTzwYyT9v+joli yRjA== X-Gm-Message-State: ALoCoQlyYZseg1buo4iJ5MrDTlokFT2y/fMaIAh4SUNXDdgO8RTZvyWIcQpFIQt63sy4JDB2pH5Y X-Received: by 10.220.105.199 with SMTP id u7mr13308744vco.1.1378665961114; Sun, 08 Sep 2013 11:46:01 -0700 (PDT) Received: from [192.168.2.6] (pool-173-79-121-77.washdc.fios.verizon.net. [173.79.121.77]) by mx.google.com with ESMTPSA id ir5sm1777465veb.6.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 08 Sep 2013 11:46:00 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Sun, 08 Sep 2013 14:46:00 -0400 From: Carl Wallace To: , , Message-ID: Thread-Topic: secdir review of draft-ietf-dime-overload-reqs-11 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [secdir] secdir review of draft-ietf-dime-overload-reqs-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 18:46:09 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes the limitations of the existing Diameter overload mechanisms and provides requirements for new overload management mechanisms. The document is very well written and clear. I had just two comments: 1) The last sentence of Requirement 13 is a bit hard to parse. 2) Requirement 31 requires indication of overload at specified granularities (realm, application, node). Should overload status mechanisms have similar granularity requirements (see requirements 10 or 24)? From emcmurry@computer.org Mon Sep 9 17:42:06 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5DC21E80FA; Mon, 9 Sep 2013 17:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSuEtKHC1PXe; Mon, 9 Sep 2013 17:42:00 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2771D21E8063; Mon, 9 Sep 2013 17:41:59 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8A0ftJ5032763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Sep 2013 00:41:56 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8A0fr6J024104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Sep 2013 00:41:54 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8A0frbF024101; Tue, 10 Sep 2013 00:41:53 GMT Received: from ericlaptop.casamcmurry.com (/76.184.161.215) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Sep 2013 17:41:53 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: Date: Mon, 9 Sep 2013 19:41:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Carl Wallace X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Mailman-Approved-At: Mon, 09 Sep 2013 17:43:47 -0700 Cc: Ben Allen Campbell , secdir@ietf.org, draft-ietf-dime-overload-reqs.all@tools.ietf.org, jouni.nospam@gmail.com, "lionel.morand@orange.com Morand" , iesg@ietf.org, "bclaise@cisco.com Claise" Subject: Re: [secdir] secdir review of draft-ietf-dime-overload-reqs-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 00:42:06 -0000 Hi Carl, Thanks for taking the time to look at this and provide comments. For your first comment, we think it would be fine to drop the last = sentence of requirement 13 to avoid confusion. It is not necessary. For your second, are you asking if the load levels in req 24 should have = granularity requirements? It may make sense for a load metric to have = similar granularity to the overload information, but the thinking was = that the load metric may be used in different ways and we did not want = to constrain it. I'm a bit lost on how requirement 10 would relate to this though. Can = you please elaborate a bit on the question? Thanks! Eric On Sep 8, 2013, at 13:46 , 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. >=20 > This document describes the limitations of the existing Diameter = overload > mechanisms and provides requirements for new overload management > mechanisms. The document is very well written and clear. I had just = two > comments: >=20 > 1) The last sentence of Requirement 13 is a bit hard to parse. >=20 > 2) Requirement 31 requires indication of overload at specified > granularities (realm, application, node). Should overload status > mechanisms have similar granularity requirements (see requirements 10 = or > 24)? >=20 >=20 From carl@redhoundsoftware.com Mon Sep 9 18:07:41 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C91C21E8115 for ; Mon, 9 Sep 2013 18:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-mLAdw93s0v for ; Mon, 9 Sep 2013 18:07:23 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6602121E8107 for ; Mon, 9 Sep 2013 18:07:23 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id ii20so37480qab.5 for ; Mon, 09 Sep 2013 18:07:22 -0700 (PDT) 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:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=DB3+YBIO7vcfKtVAeW9bNCvmdXquzxtE0bNKaYgdOvQ=; b=J8MxQkOyjNagkx1COjp8WX7P7wQh7syz1JTCz/8WcS0C1Vij2Qb/VowL0Y2DVJNERr hYuwF7GqODZKglXz75szAWh+z3bpH99UjaRU/R3jD25HjcI7aj97iF70F3qmVZWckfOV hBFEmyNOskJFHPlm+NqHoi2xp9S2hVSitBIcuJb9Z7Cptvb8bm08VGQ9iqiymhCFZJOV CXKYpM2+62PuQN6qJl7TPWpgeiMdM7o53a2318HtKdCU+U8YXrNHB8Xr3tSr4Bt/MrLI qvx2iwZoWBKIS9tPWEHwf61WrK6c8EvTykAGNpnJkzJh6uMmOoApDzsCO/AruNABLdEf 2gBg== X-Gm-Message-State: ALoCoQk/DCMg2S2/IhFNGgnh7+noz2DdtXpRLLR4XjfKMmZatiKvydIPFTe6nmRqAJo8tWy9EIcV X-Received: by 10.49.1.166 with SMTP id 6mr14674370qen.65.1378775242525; Mon, 09 Sep 2013 18:07:22 -0700 (PDT) Received: from [192.168.2.3] (pool-173-79-121-77.washdc.fios.verizon.net. [173.79.121.77]) by mx.google.com with ESMTPSA id h6sm29701778qej.4.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 09 Sep 2013 18:07:22 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Mon, 09 Sep 2013 21:07:15 -0400 From: Carl Wallace To: Eric McMurry Message-ID: Thread-Topic: secdir review of draft-ietf-dime-overload-reqs-11 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Ben Allen Campbell , secdir@ietf.org, draft-ietf-dime-overload-reqs.all@tools.ietf.org, jouni.nospam@gmail.com, "lionel.morand@orange.com Morand" , iesg@ietf.org, "bclaise@cisco.com Claise" Subject: Re: [secdir] secdir review of draft-ietf-dime-overload-reqs-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 01:07:41 -0000 On 9/9/13 8:41 PM, "Eric McMurry" wrote: >Hi Carl, > >Thanks for taking the time to look at this and provide comments. > >For your first comment, we think it would be fine to drop the last >sentence of requirement 13 to avoid confusion. It is not necessary. > >For your second, are you asking if the load levels in req 24 should have >granularity requirements? It may make sense for a load metric to have >similar granularity to the overload information, but the thinking was >that the load metric may be used in different ways and we did not want to >constrain it. > >I'm a bit lost on how requirement 10 would relate to this though. Can >you please elaborate a bit on the question? Requirement 31 states: "The solution MUST allow Diameter nodes to indicate overload with sufficient granularity to allow clients to take action based on the overloaded resources without unreasonably forcing available capacity to go unused. The solution MUST support specification of overload information with granularities of at least "Diameter node", "realm", and "Diameter application", and MUST allow extensibility for others to be added in the future." Requirement 10 states: "Consumers of overload information MUST be able to determine when the overload condition improves or ends" My question was, must consumers of overload information be able to determine when the overload condition improves or ends? Requirement 10 seems to be addressing a type of action a client may take based on granular information provided under requirement 31. More or less the same question applied to 24 as well, maybe not as an action following overload as in requirement 10 but perhaps as an action with similar granular needs. > >Thanks! > >Eric > > >On Sep 8, 2013, at 13:46 , 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 document describes the limitations of the existing Diameter >>overload >> mechanisms and provides requirements for new overload management >> mechanisms. The document is very well written and clear. I had just >>two >> comments: >> >> 1) The last sentence of Requirement 13 is a bit hard to parse. >> >> 2) Requirement 31 requires indication of overload at specified >> granularities (realm, application, node). Should overload status >> mechanisms have similar granularity requirements (see requirements 10 or >> 24)? >> >> > From carl@redhoundsoftware.com Mon Sep 9 18:28:02 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32C211E80F8 for ; Mon, 9 Sep 2013 18:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdjFWWLH+B0n for ; Mon, 9 Sep 2013 18:27:35 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id BA70121E8179 for ; Mon, 9 Sep 2013 18:27:24 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c9so1640017qcz.14 for ; Mon, 09 Sep 2013 18:27:24 -0700 (PDT) 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:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=zP9xTl2b4xGvAndQKYJXeM9UVz/2SnzzVT/DKKdDxfs=; b=gQA7NEQ8DANAQ3BOIEFoS4+DP7zoHBYsKXvXA8h/bihA4GaUFKkyFpSNDA4TjKyN5s CK0DhU2UL/kgNhAKGmCa/zZ4L757R4PZ+VNHmO90P4it25pYtQHxkLd5XGG30GeDsOvY VgVndCpWkvVvpQFcDvaQtcb1RL3xUVJjKxTA5kFlql+V5i4LSCLA23+896LEuErWmk9h eSECiZXf0xdUqcZv8oxG1nG+XZHkW/Tmu4WQporw4EmdkvzHXUNRC0yGzzq/TenOzZJV 3+foMkqXIMKdQHs6Wm7hPPlxxIan9O7fzyAAnjsyh36oRdAPjBpge7a3M7+/ZxjBCa1s C1+w== X-Gm-Message-State: ALoCoQmAOw9C2TQUh8rxr+JH11yu+po2+VL0a1NdRTxhPTBUaKRarNk/RTtgjI0VgWpOAaAa+pQ5 X-Received: by 10.224.34.69 with SMTP id k5mr2975515qad.42.1378776444075; Mon, 09 Sep 2013 18:27:24 -0700 (PDT) Received: from [192.168.2.3] (pool-173-79-121-77.washdc.fios.verizon.net. [173.79.121.77]) by mx.google.com with ESMTPSA id u8sm29852742qef.3.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 09 Sep 2013 18:27:23 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Mon, 09 Sep 2013 21:27:17 -0400 From: Carl Wallace To: Ben Campbell Message-ID: Thread-Topic: secdir review of draft-ietf-dime-overload-reqs-11 In-Reply-To: <27D02CC2-7D12-41B4-87C3-9E5545A0B0AE@nostrum.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: secdir@ietf.org, draft-ietf-dime-overload-reqs.all@tools.ietf.org, jouni.nospam@gmail.com, "lionel.morand@orange.com Morand" , iesg@ietf.org, "bclaise@cisco.com Claise" , Eric McMurry Subject: Re: [secdir] secdir review of draft-ietf-dime-overload-reqs-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 01:28:03 -0000 > > > >The intent was that the overload condition has granularity. That is, the >overloaded node indicates an overload condition with some granularity, >and later ends it. The act of ending doesn't change the granularity. We >don't have an explicit requirement to be able to change the granularity >of an existing condition. (Although we do not prevent a solution from >offering that ability--but I suspect if the solution did that, it would >involve multiple concurrent overload conditions, or ending one condition >and starting another.) Got it. Thanks. From jouni.nospam@gmail.com Mon Sep 9 20:22:26 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C438B21F9FB7; Mon, 9 Sep 2013 20:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_IP_211216=0.978, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYYI-VMjmkAc; Mon, 9 Sep 2013 20:22:26 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 54EF321F9F80; Mon, 9 Sep 2013 20:22:26 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id q10so6986761pdj.20 for ; Mon, 09 Sep 2013 20:22:25 -0700 (PDT) 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:cc :content-transfer-encoding:message-id:references:to; bh=MkczKop9wc7f4XX6RZqECYghcOWkP+nLVSQY62WlVsA=; b=StW3FTd/+FkILihQRQzNvpNn2sYt0OJwaBD1Mv5WTHk0D8OtUomQj00iZh/ggF9fGY iaHO0KM2ji++/U/duIG5R30kHk8L1G2OzkotocYZ9xFtixEU081b4MSJVBE0ww8nS4le bl0shI/qDNxtWkbSgjg91nJLW85JaK5sG65nI+hf/uh4gEvtngrjloK0Sc57TNsDqUUL +QLF9qRRGbn68dyWHdLCl0h9G43jzC8epCfYkXQ8Rzp5aZdmqk05bBK2wIcXAz3/rddC LomsqSTD1HTbsCcVXNV7q6z8BrnwNU0PE6dq35uieqjGv4pMvDHWHyi5J0lBvL1N4ING DJZw== X-Received: by 10.66.136.227 with SMTP id qd3mr11839630pab.113.1378783344961; Mon, 09 Sep 2013 20:22:24 -0700 (PDT) Received: from [10.5.8.117] ([211.219.0.130]) by mx.google.com with ESMTPSA id iu7sm19651456pbc.45.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 20:22:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: Date: Tue, 10 Sep 2013 06:22:19 +0300 Content-Transfer-Encoding: 7bit Message-Id: <8D9934B4-948F-47A5-AB5E-02DEDD5277F0@gmail.com> References: To: Carl Wallace X-Mailer: Apple Mail (2.1508) Cc: Ben Campbell , secdir@ietf.org, draft-ietf-dime-overload-reqs.all@tools.ietf.org, "lionel.morand@orange.com Morand" , iesg@ietf.org, "bclaise@cisco.com Claise" , Eric McMurry Subject: Re: [secdir] secdir review of draft-ietf-dime-overload-reqs-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 03:22:26 -0000 Folks, So if I got it right, the last sentence of the Req13 will be removed and the Req31 stays as it is now. This would be fine with me. - JOuni On Sep 10, 2013, at 4:27 AM, Carl Wallace wrote: >> >> >> >> The intent was that the overload condition has granularity. That is, the >> overloaded node indicates an overload condition with some granularity, >> and later ends it. The act of ending doesn't change the granularity. We >> don't have an explicit requirement to be able to change the granularity >> of an existing condition. (Although we do not prevent a solution from >> offering that ability--but I suspect if the solution did that, it would >> involve multiple concurrent overload conditions, or ending one condition >> and starting another.) > > Got it. Thanks. > > From emcmurry@computer.org Mon Sep 9 20:24:27 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D7111E80EA; Mon, 9 Sep 2013 20:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEqmmB8fCPb3; Mon, 9 Sep 2013 20:24:21 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 292C221F9FF3; Mon, 9 Sep 2013 20:24:20 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8A3OGtV032250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Sep 2013 03:24:17 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8A3OFL7018523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Sep 2013 03:24:15 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8A3OEPp018519; Tue, 10 Sep 2013 03:24:14 GMT Received: from ericlaptop.casamcmurry.com (/76.184.161.215) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Sep 2013 20:24:14 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: <8D9934B4-948F-47A5-AB5E-02DEDD5277F0@gmail.com> Date: Mon, 9 Sep 2013 22:24:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <271A8F02-3A74-46E9-B08E-2D155EC3DDD3@computer.org> References: <8D9934B4-948F-47A5-AB5E-02DEDD5277F0@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Ben Campbell , secdir@ietf.org, draft-ietf-dime-overload-reqs.all@tools.ietf.org, "lionel.morand@orange.com Morand" , iesg@ietf.org, "bclaise@cisco.com Claise" Subject: Re: [secdir] secdir review of draft-ietf-dime-overload-reqs-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 03:24:27 -0000 that matches what I came away with. How would you like us to address = that? On Sep 9, 2013, at 22:22 , Jouni Korhonen = wrote: >=20 > Folks, >=20 > So if I got it right, the last sentence of the Req13 will be removed = and > the Req31 stays as it is now. >=20 > This would be fine with me. >=20 > - JOuni >=20 > On Sep 10, 2013, at 4:27 AM, Carl Wallace = wrote: >=20 >>>=20 >>>=20 >>>=20 >>> The intent was that the overload condition has granularity. That is, = the >>> overloaded node indicates an overload condition with some = granularity, >>> and later ends it. The act of ending doesn't change the granularity. = We >>> don't have an explicit requirement to be able to change the = granularity >>> of an existing condition. (Although we do not prevent a solution = from >>> offering that ability--but I suspect if the solution did that, it = would >>> involve multiple concurrent overload conditions, or ending one = condition >>> and starting another.) >>=20 >> Got it. Thanks. =20 >>=20 >>=20 >=20 From jouni.nospam@gmail.com Mon Sep 9 20:55:44 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3887121F9B12; Mon, 9 Sep 2013 20:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_IP_211216=0.978, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6avEl6Nnw-v; Mon, 9 Sep 2013 20:55:43 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9F37D21F99CD; Mon, 9 Sep 2013 20:55:43 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id y10so6998097pdj.8 for ; Mon, 09 Sep 2013 20:55:43 -0700 (PDT) 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:cc :content-transfer-encoding:message-id:references:to; bh=Z81gtmzJc0IvBBu2pxRrwscMO9doPbh2NCeie9gb6oI=; b=uKAO72+FuFDNWLsQU1s+u1pbj+VcFVeHYDcLN1rao3gQhuq/x+qgWQ6lAdT3xEG3Mb GgiXSKZm2WnE5EATSXdFFDcg9q1hhhOeypEgvCcbQ24TX8RPDny1ND1RdRIdbVmuJlK5 snAH2mzz23xTMl/HoZ/4djRc21pZYXAQ75m0IFFHiRpfcV0GM7qagrjOJ88855jYSZOP JXP0DWy/5yyocWzENsA13kp0PeO/i62NstKAFFHmtSzcMUEq9p6AMdjmSHFPh5vX7iVi zwtVz/nRliC8MGB5DbxskeDSR2XB43+GIkLPLicKmH6MRHSsXmPpXaLacI05JyW4WupT mw8A== X-Received: by 10.68.232.134 with SMTP id to6mr6583597pbc.163.1378785342986; Mon, 09 Sep 2013 20:55:42 -0700 (PDT) Received: from [10.5.8.117] ([211.219.0.130]) by mx.google.com with ESMTPSA id qa9sm19862435pbc.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 20:55:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: <271A8F02-3A74-46E9-B08E-2D155EC3DDD3@computer.org> Date: Tue, 10 Sep 2013 06:55:37 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <351B6399-E47D-4041-A09F-712ED4570F40@gmail.com> References: <8D9934B4-948F-47A5-AB5E-02DEDD5277F0@gmail.com> <271A8F02-3A74-46E9-B08E-2D155EC3DDD3@computer.org> To: Eric McMurry X-Mailer: Apple Mail (2.1508) Cc: Ben Campbell , secdir@ietf.org, draft-ietf-dime-overload-reqs.all@tools.ietf.org, "lionel.morand@orange.com Morand" , iesg@ietf.org, "bclaise@cisco.com Claise" Subject: Re: [secdir] secdir review of draft-ietf-dime-overload-reqs-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 03:55:44 -0000 I would note down the change but implement/submit a revision after we = get the rest of the IESG comments (the doc is in next week's telechat). = That's because ADs (and others) are now reading the -11. - Jouni On Sep 10, 2013, at 6:24 AM, Eric McMurry wrote: > that matches what I came away with. How would you like us to address = that? >=20 >=20 > On Sep 9, 2013, at 22:22 , Jouni Korhonen = wrote: >=20 >>=20 >> Folks, >>=20 >> So if I got it right, the last sentence of the Req13 will be removed = and >> the Req31 stays as it is now. >>=20 >> This would be fine with me. >>=20 >> - JOuni >>=20 >> On Sep 10, 2013, at 4:27 AM, Carl Wallace = wrote: >>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The intent was that the overload condition has granularity. That = is, the >>>> overloaded node indicates an overload condition with some = granularity, >>>> and later ends it. The act of ending doesn't change the = granularity. We >>>> don't have an explicit requirement to be able to change the = granularity >>>> of an existing condition. (Although we do not prevent a solution = from >>>> offering that ability--but I suspect if the solution did that, it = would >>>> involve multiple concurrent overload conditions, or ending one = condition >>>> and starting another.) >>>=20 >>> Got it. Thanks. =20 >>>=20 >>>=20 >>=20 >=20 From bclaise@cisco.com Tue Sep 10 02:24:59 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19A221F997D; Tue, 10 Sep 2013 02:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.216 X-Spam-Level: X-Spam-Status: No, score=-10.216 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTV2q5BPGbDV; Tue, 10 Sep 2013 02:24:53 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E981121E80DC; Tue, 10 Sep 2013 02:24:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r8A9Oc2G025145; Tue, 10 Sep 2013 11:24:38 +0200 (CEST) Received: from [10.61.219.48] ([10.61.219.48]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r8A9MsYq010635; Tue, 10 Sep 2013 11:23:04 +0200 (CEST) Message-ID: <522EB7EA.5010207@cisco.com> Date: Tue, 10 Sep 2013 08:10:50 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jouni Korhonen References: <8D9934B4-948F-47A5-AB5E-02DEDD5277F0@gmail.com> <271A8F02-3A74-46E9-B08E-2D155EC3DDD3@computer.org> <351B6399-E47D-4041-A09F-712ED4570F40@gmail.com> In-Reply-To: <351B6399-E47D-4041-A09F-712ED4570F40@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ben Campbell , secdir@ietf.org, draft-ietf-dime-overload-reqs.all@tools.ietf.org, "lionel.morand@orange.com Morand" , iesg@ietf.org, Eric McMurry Subject: Re: [secdir] secdir review of draft-ietf-dime-overload-reqs-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 09:24:59 -0000 Actually, it might be better to quickly publish a new version (as opposed to me writing down a RFC editor note), because the IESG is still busy reading the document for this Thursday telechat. Regards, Benoit > I would note down the change but implement/submit a revision after we get > the rest of the IESG comments (the doc is in next week's telechat). That's > because ADs (and others) are now reading the -11. > > - Jouni > > > On Sep 10, 2013, at 6:24 AM, Eric McMurry wrote: > >> that matches what I came away with. How would you like us to address that? >> >> >> On Sep 9, 2013, at 22:22 , Jouni Korhonen wrote: >> >>> Folks, >>> >>> So if I got it right, the last sentence of the Req13 will be removed and >>> the Req31 stays as it is now. >>> >>> This would be fine with me. >>> >>> - JOuni >>> >>> On Sep 10, 2013, at 4:27 AM, Carl Wallace wrote: >>> >>>>> >>>>> >>>>> The intent was that the overload condition has granularity. That is, the >>>>> overloaded node indicates an overload condition with some granularity, >>>>> and later ends it. The act of ending doesn't change the granularity. We >>>>> don't have an explicit requirement to be able to change the granularity >>>>> of an existing condition. (Although we do not prevent a solution from >>>>> offering that ability--but I suspect if the solution did that, it would >>>>> involve multiple concurrent overload conditions, or ending one condition >>>>> and starting another.) >>>> Got it. Thanks. >>>> >>>> > > From kivinen@iki.fi Tue Sep 10 04:12:41 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7D311E8132; Tue, 10 Sep 2013 04:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmqjKKRsJn+8; Tue, 10 Sep 2013 04:12:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 812D611E8197; Tue, 10 Sep 2013 04:12:39 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r8ABCaF2004688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 Sep 2013 14:12:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r8ABCWIn024410; Tue, 10 Sep 2013 14:12:32 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21038.65184.648694.445550@fireball.kivinen.iki.fi> Date: Tue, 10 Sep 2013 14:12:32 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-cotton-rfc4020bis.all@tools.ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 8 min Subject: [secdir] Secdir review of draft-cotton-rfc4020bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 11:12:41 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes (or updates) the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. One of the big problems with early allocations is that the implementations using those numbers will never really go away, even if the numbers are later changed (i.e. changed from private number space to real allocations). At least with this kind of early real allocations, the implementations could use the real numbers and be interoperable with the RFC versions. The security considerations section do cover the denial of service attacks against IANA (depletion of code space by early allocations, and process overload of IANA itself). I do not have any comments for this document, and I think it is ready. -- kivinen@iki.fi From emcmurry@computer.org Tue Sep 10 06:26:23 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DD721E8053; Tue, 10 Sep 2013 06:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNB4v4UP5wNV; Tue, 10 Sep 2013 06:26:16 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1B75D11E81A4; Tue, 10 Sep 2013 06:26:10 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8ADPqkr002940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Sep 2013 13:25:53 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8ADPn6t008944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Sep 2013 13:25:50 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8ADPmdF012081; Tue, 10 Sep 2013 13:25:48 GMT Received: from ericlaptop.casamcmurry.com (/76.184.161.215) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Sep 2013 06:25:48 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: <522EB7EA.5010207@cisco.com> Date: Tue, 10 Sep 2013 08:25:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <563A86C3-662A-471A-A569-9C004317652D@computer.org> References: <8D9934B4-948F-47A5-AB5E-02DEDD5277F0@gmail.com> <271A8F02-3A74-46E9-B08E-2D155EC3DDD3@computer.org> <351B6399-E47D-4041-A09F-712ED4570F40@gmail.com> <522EB7EA.5010207@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Ben Campbell , secdir@ietf.org, draft-ietf-dime-overload-reqs.all@tools.ietf.org, Jouni Korhonen , "lionel.morand@orange.com Morand" , iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dime-overload-reqs-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 13:26:23 -0000 okay Benoit. I'll do that this morning. Thanks, Eric On Sep 10, 2013, at 1:10 , Benoit Claise wrote: > Actually, it might be better to quickly publish a new version (as = opposed to me writing down a RFC editor note), because the IESG is still = busy reading the document for this Thursday telechat. >=20 > Regards, Benoit >> I would note down the change but implement/submit a revision after we = get >> the rest of the IESG comments (the doc is in next week's telechat). = That's >> because ADs (and others) are now reading the -11. >>=20 >> - Jouni >>=20 >>=20 >> On Sep 10, 2013, at 6:24 AM, Eric McMurry = wrote: >>=20 >>> that matches what I came away with. How would you like us to = address that? >>>=20 >>>=20 >>> On Sep 9, 2013, at 22:22 , Jouni Korhonen = wrote: >>>=20 >>>> Folks, >>>>=20 >>>> So if I got it right, the last sentence of the Req13 will be = removed and >>>> the Req31 stays as it is now. >>>>=20 >>>> This would be fine with me. >>>>=20 >>>> - JOuni >>>>=20 >>>> On Sep 10, 2013, at 4:27 AM, Carl Wallace = wrote: >>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The intent was that the overload condition has granularity. That = is, the >>>>>> overloaded node indicates an overload condition with some = granularity, >>>>>> and later ends it. The act of ending doesn't change the = granularity. We >>>>>> don't have an explicit requirement to be able to change the = granularity >>>>>> of an existing condition. (Although we do not prevent a solution = from >>>>>> offering that ability--but I suspect if the solution did that, it = would >>>>>> involve multiple concurrent overload conditions, or ending one = condition >>>>>> and starting another.) >>>>> Got it. Thanks. >>>>>=20 >>>>>=20 >>=20 >>=20 >=20 From ben@nostrum.com Mon Sep 9 18:20:44 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435D111E80FF; Mon, 9 Sep 2013 18:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivqooUt+wKdK; Mon, 9 Sep 2013 18:20:43 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B59A611E80F8; Mon, 9 Sep 2013 18:20:43 -0700 (PDT) Received: from [10.0.1.9] (cpe-76-187-89-238.tx.res.rr.com [76.187.89.238]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r8A1KPwu021430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Sep 2013 20:20:25 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: Date: Mon, 9 Sep 2013 20:20:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <27D02CC2-7D12-41B4-87C3-9E5545A0B0AE@nostrum.com> References: To: Carl Wallace X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.89.238 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 10 Sep 2013 08:13:10 -0700 Cc: secdir@ietf.org, draft-ietf-dime-overload-reqs.all@tools.ietf.org, jouni.nospam@gmail.com, "lionel.morand@orange.com Morand" , iesg@ietf.org, "bclaise@cisco.com Claise" , Eric McMurry Subject: Re: [secdir] secdir review of draft-ietf-dime-overload-reqs-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 01:20:44 -0000 On Sep 9, 2013, at 8:07 PM, Carl Wallace = wrote: >=20 > On 9/9/13 8:41 PM, "Eric McMurry" wrote: >>=20 [...] >> I'm a bit lost on how requirement 10 would relate to this though. = Can >> you please elaborate a bit on the question? >=20 > Requirement 31 states: >=20 > "The solution MUST allow Diameter nodes to indicate overload with > sufficient granularity to allow clients to take action based on the > overloaded resources without unreasonably forcing available capacity = to go > unused. The solution MUST support specification of overload = information > with granularities of at least "Diameter node", "realm", and "Diameter > application", and MUST allow extensibility for others to be added in = the > future." >=20 > Requirement 10 states: >=20 > "Consumers of overload information MUST be able to determine when the > overload condition improves or ends" >=20 > My question was, must consumers of overload information be able to > determine when the overload condition > improves or ends? Requirement 10 seems to be addressing a type of = action > a client may take based on granular information provided under = requirement > 31. =20 >=20 The intent was that the overload condition has granularity. That is, the = overloaded node indicates an overload condition with some granularity, = and later ends it. The act of ending doesn't change the granularity. We = don't have an explicit requirement to be able to change the granularity = of an existing condition. (Although we do not prevent a solution from = offering that ability--but I suspect if the solution did that, it would = involve multiple concurrent overload conditions, or ending one condition = and starting another.) > More or less the same question applied to 24 as well, maybe not as an > action following overload as in requirement 10 but perhaps as an = action > with similar granular needs. Since 24 talks of "load" rather than "overload", we assumed your = question concerned whether "load" needed the same or similar = granularities to "overload". Did you mean something different? Thanks! Ben. From ben@nostrum.com Mon Sep 9 20:24:35 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E71A11E810D; Mon, 9 Sep 2013 20:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHi+SFE1CS3o; Mon, 9 Sep 2013 20:24:35 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E13A511E80EA; Mon, 9 Sep 2013 20:24:34 -0700 (PDT) Received: from [10.0.1.9] (cpe-76-187-89-238.tx.res.rr.com [76.187.89.238]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r8A3OK4Z034281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Sep 2013 22:24:21 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: <8D9934B4-948F-47A5-AB5E-02DEDD5277F0@gmail.com> Date: Mon, 9 Sep 2013 22:24:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0B9FA867-7A39-44E0-A7A0-04C67B493710@nostrum.com> References: <8D9934B4-948F-47A5-AB5E-02DEDD5277F0@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.89.238 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 10 Sep 2013 08:13:10 -0700 Cc: secdir@ietf.org, draft-ietf-dime-overload-reqs.all@tools.ietf.org, "lionel.morand@orange.com Morand" , iesg@ietf.org, "bclaise@cisco.com Claise" , Eric McMurry Subject: Re: [secdir] secdir review of draft-ietf-dime-overload-reqs-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 03:24:35 -0000 On Sep 9, 2013, at 10:22 PM, Jouni Korhonen = wrote: >=20 > Folks, >=20 > So if I got it right, the last sentence of the Req13 will be removed = and > the Req31 stays as it is now. >=20 > This would be fine with me. >=20 That is my understanding. Or more precisely, the last sentence of Req13 = will be removed, and nothing else will change. > - JOuni >=20 > On Sep 10, 2013, at 4:27 AM, Carl Wallace = wrote: >=20 >>>=20 >>>=20 >>>=20 >>> The intent was that the overload condition has granularity. That is, = the >>> overloaded node indicates an overload condition with some = granularity, >>> and later ends it. The act of ending doesn't change the granularity. = We >>> don't have an explicit requirement to be able to change the = granularity >>> of an existing condition. (Although we do not prevent a solution = from >>> offering that ability--but I suspect if the solution did that, it = would >>> involve multiple concurrent overload conditions, or ending one = condition >>> and starting another.) >>=20 >> Got it. Thanks. =20 >>=20 >>=20 >=20 From weiler@watson.org Tue Sep 10 19:54:02 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0096211E8108; Tue, 10 Sep 2013 19:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Xux1yuI0yF8; Tue, 10 Sep 2013 19:53:55 -0700 (PDT) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by ietfa.amsl.com (Postfix) with ESMTP id C963421F9F84; Tue, 10 Sep 2013 19:53:55 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id 8EDB746B2A; Tue, 10 Sep 2013 22:53:53 -0400 (EDT) Received: from fledge.watson.org (weiler@localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.7/8.14.7) with ESMTP id r8B2rrwm027410; Tue, 10 Sep 2013 22:53:53 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.7/8.14.7/Submit) with ESMTP id r8B2rqSC027403; Tue, 10 Sep 2013 22:53:53 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 10 Sep 2013 22:53:52 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org, iesg@ietf.org, draft-ietf-homenet-arch.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Wed, 11 Sep 2013 03:53:53 +0100 (BST) Subject: [secdir] secdir review of draft-ietf-homenet-arch-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 02:54:02 -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. Even though this is an architecture document, I think it deserves some AD attention. First: it seems odd to set an expectation for (near) zero-configuration: It is not practical to expect home users to configure their networks. Thus the assumption of this document is that the homenet is as far as possible self-organising and self-configuring, i.e. it should function without pro-active management by the residential user. and then decline to give any guidance about, arguably, the most important security choice in the document: This document takes no position on [whether 'default allow' or 'default deny'] mode is the default, but assumes the choice for the homenet to use either mode would be available. I found the "Name spaces" section (3.7.3) a bit confusing, in part because it doesn't specifically name DNS at the start of the section, even though the details below clearly point to DNS (IDNA, possible conflicts with dotless TLDs). Perhaps the second paragraph of 3.7.4, explaining that there are some non-DNS alternatives under consideration, should be moved up? Furthermore, there are some particular assertions in both 3.7.3 and 3.7.4 that need to be reconsidered: -- "When DNS is used as the homenet name service, it includes both a resolving service and an authoritative service." Does it necessarily? -- "The name space(s) should be served authoritatively by the homenet..." Why is that necessary? (Indeed, there is text in 3.7.4 that seems to conflict with this.) -- There is a recommendation to support DNSSEC on the authoritative server side (in 3.7.4). Shouldn't there be a similar recommendation on the resolver side? From mark@townsley.net Wed Sep 11 01:00:37 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9FC11E81FD for ; Wed, 11 Sep 2013 01:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ra90l1XVwhks for ; Wed, 11 Sep 2013 01:00:31 -0700 (PDT) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7655811E81F0 for ; Wed, 11 Sep 2013 01:00:29 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id c1so4438636eek.10 for ; Wed, 11 Sep 2013 01:00:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Mjpi7WWtt+kmOIN4UpCP4fILTatirw63f0cZVG1ynUM=; b=GlTH9SaYks4cFc4p3S34WZZRtUBNBX5zfrQacyehuKdhtaP6HOaMP15Avay0ku9H06 mM1v78gqacZBnW0ftsZQX85Fr8xRmRTf0VLsJ5uQY6CRgKaMGIA1QoZjwj10/8iqwtRU f0ktSAraY3vip96SxCRrFYm3kwy6uzanF3fN3vQXvHiffJIut3fHvhT1Z9qetZWZqwv+ klRuF3WPOAy+yN+M0S1zlFnZN6Nt9ZgjoCijq8ty7u4In9EAYLVFXreOdSMAehcpJd+K Erqao8tEuHfHQfMkyi0IK3EiD/v6oJmyJ7RLcXhDRfUXB907WsNngF4mIfgyqTEwMNDp kN1Q== X-Gm-Message-State: ALoCoQkoonoaGmiAb99fXI8H7Fq+FV+mHwsJdEihuiqkvr44f9/qpG2uIC2xGCPv7njJ8ebksivG X-Received: by 10.14.109.201 with SMTP id s49mr423796eeg.54.1378886428088; Wed, 11 Sep 2013 01:00:28 -0700 (PDT) Received: from ams-townsley-8913.cisco.com (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id p5sm38037023eeg.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Sep 2013 01:00:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Wed, 11 Sep 2013 10:00:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Samuel Weiler X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Wed, 11 Sep 2013 02:30:11 -0700 Cc: Ray Bellis , iesg@ietf.org, draft-ietf-homenet-arch.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-homenet-arch-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 08:00:37 -0000 Hi Sam, thanks for the review. Inline... On Sep 11, 2013, at 4:53 AM, Samuel Weiler 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. >=20 >=20 > Even though this is an architecture document, I think it deserves some = AD attention. >=20 >=20 > First: it seems odd to set an expectation for (near) = zero-configuration: >=20 > It is not practical to expect home users to configure their = networks. > Thus the assumption of this document is that the homenet is as far = as > possible self-organising and self-configuring, i.e. it should > function without pro-active management by the residential user. >=20 > and then decline to give any guidance about, arguably, the most = important security choice in the document: >=20 > This document takes no position on [whether 'default allow' or > 'default deny'] mode is the default, but assumes > the choice for the homenet to use either mode would be available. Homenet's focus is on the interior of the home network. RFC 6204 already = tackled the egress ("WAN Port") facing the ISP within v6ops, along with = the painful process of this particular issue. Perhaps we should make = that more clear in this document. >=20 >=20 > I found the "Name spaces" section (3.7.3) a bit confusing, in part = because it doesn't specifically name DNS at the start of the section, = even though the details below clearly point to DNS (IDNA, possible = conflicts with dotless TLDs). Perhaps the second paragraph of 3.7.4, = explaining that there are some non-DNS alternatives under consideration, = should be moved up? Furthermore, there are some particular assertions = in both 3.7.3 and 3.7.4 that need to be reconsidered: >=20 > -- "When DNS is used as the homenet name service, it includes both a > resolving service and an authoritative service." Does it > necessarily? >=20 > -- "The name space(s) should be served authoritatively by the > homenet..." Why is that necessary? (Indeed, there is text in > 3.7.4 that seems to conflict with this.) >=20 > -- There is a recommendation to support DNSSEC on the authoritative > server side (in 3.7.4). Shouldn't there be a similar > recommendation on the resolver side? Good points, but I'll let my DNS-hat-wearing co-chair chime in on these. Thanks, - Mark= From Ray.Bellis@nominet.org.uk Wed Sep 11 01:33:18 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C010A11E8162; Wed, 11 Sep 2013 01:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImcRr9hMR-Ic; Wed, 11 Sep 2013 01:33:13 -0700 (PDT) Received: from mx1.nominet.org.uk (mail.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9C38C11E81EC; Wed, 11 Sep 2013 01:33:07 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=p9yqRfxyM9tRzLPZqVSYnsp9ebIYCP1xh1mHFJ2hY/dwq7vM7Osl8ifY Ol1rrZiD0FPYmfynQ/BspLCCAzVmt+XuvdpazL4ICs1yfzd846BRCAxds sb0+Wa9hTUOAPCB; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1378888388; x=1410424388; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+16kQriOhfRcP5WoPA5GIs0f4sM0EC2WNeLK4K2UuNc=; b=k9SYyAAbYlbR6IXvvPzt/5aVehKaNJce4RDvEnG0wy8ELjBuZRVoMgGe +yBDANmgFrs51KNMX5dm3RlEdPBCADvTIUuZeVN2aaSu02NaxyR3JwWdW pUYyp+1A903qxgC; X-IronPort-AV: E=Sophos;i="4.90,883,1371078000"; d="scan'208";a="3287016" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 11 Sep 2013 09:33:02 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Wed, 11 Sep 2013 09:33:01 +0100 From: Ray Bellis To: Samuel Weiler Thread-Topic: secdir review of draft-ietf-homenet-arch-10 Thread-Index: AQHOrpowneGtTVadlEOUAKAd3eCKbZnAG/gAgAAJHAA= Date: Wed, 11 Sep 2013 08:33:00 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE90676@wds-exc1.okna.nominet.org.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <6599B12216C8E046909015FFDC7FC3A4@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 11 Sep 2013 02:30:05 -0700 Cc: "iesg@ietf.org" , "draft-ietf-homenet-arch.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-homenet-arch-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 08:33:19 -0000 Sam, Following on from Mark's comments: > -- "When DNS is used as the homenet name service, it includes both a > resolving service and an authoritative service." Does it > necessarily? A Homenet that is not currently connected to the Internet still needs to be= able to function, so (when DNS is used) authoritative local name service a= nd a service for resolution of those local names are both needed. > -- "The name space(s) should be served authoritatively by the > homenet..." Why is that necessary? (Indeed, there is text in > 3.7.4 that seems to conflict with this.) One reason is simply to prevent names only intended to be known internally = from being shared with externally maintained authoritative servers. The other is the "disconnected homenet" mentioned above. Can you please indicate which text you believe is in conflict? > -- There is a recommendation to support DNSSEC on the authoritative > server side (in 3.7.4). Shouldn't there be a similar > recommendation on the resolver side? That (short) paragraph is not specific to authoritative servers, it applies= to the entire section. The example of cache-poisoning further indicates i= ts applicability to recursive resolution. kind regards, Ray From hallam@gmail.com Wed Sep 11 05:07:30 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F6721F9CF3; Wed, 11 Sep 2013 05:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oy3Iy8Naloda; Wed, 11 Sep 2013 05:07:29 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5617121F9D99; Wed, 11 Sep 2013 05:07:28 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id y6so7255344lbh.6 for ; Wed, 11 Sep 2013 05:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=i9ZT0KXzziiHajSx7umn3B9iAN9oowTmA32FjbKePZ8=; b=e9fs1SN7W7sGzvF+XuHwbVWDWSC+o3VcFV7fvF89aWJhg61XkIO+AwGjGyD/qdNVBK zCL58oMha0Up4/abrSQg6+nSs7wjoPRC4/70imtV70guxdG7FlCPH2WgBL7x7AjMC7SJ xUy3btzBYkCXxp2lixBWzsozHO4EL8dFhhYqtkmnR3pHCPglKdR5vxIe2AVb0doue9uQ UHm7DgEdmwVF1/kdiy7NpIvqm4sr4tpFV+1c7Rw462Td4UHHHYKh36azQzDP6/E8qIiQ R3srAr9cOnchwyxiEALDHFqZ3LMO0tm1mM/rJqhVLVxI6NxE9+33z3ZTQCaYsU3JYTpH zyyw== MIME-Version: 1.0 X-Received: by 10.112.190.1 with SMTP id gm1mr2449827lbc.30.1378901247143; Wed, 11 Sep 2013 05:07:27 -0700 (PDT) Received: by 10.112.77.106 with HTTP; Wed, 11 Sep 2013 05:07:27 -0700 (PDT) Date: Wed, 11 Sep 2013 08:07:27 -0400 Message-ID: From: Phillip Hallam-Baker To: draft-ietf-spfbis-4408bis.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3836c0434aa04e61a779a Subject: [secdir] SECDIR Review of draft-ietf-spfbis-4408bis-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 12:07:30 -0000 --001a11c3836c0434aa04e61a779a Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. The document has been produced as part of a proposal to upgrade SPF to standards track recognizing the state of deployment experience. Minor issues. 1.1.3 . MAIL FROM Definition I found this section completely opaque and very confusing. It should not be necessary to hunt through other specs to find a definition. Particularly since the referenced specs do not give an explicit definition for the term as used and the references point to the whole spec rather than a particular section. The Security Considerations section is adequate for the purpose except that no mention is made anywhere in the specification about DKIM and how a mail receiver should interpret presence of DKIM and SPF policy at the same time. This is a legitimate concern since DKIM is already a standards track proposal and SPF is only now being promoted to Standards Track. Thus the SPF document should address the question of dual use. 8.7 . Permerror "This signals an error condition that definitely requires operator intervention to be resolved." I cannot imagine a circumstance which definitely requires a human to be involved in mail delivery. 11.2 . SPF-Authorized Email May Contain Other False Identities Do not construe the "MAIL FROM" and "HELO" identity authorizations to provide more assurance than they do. Document has quasi normative language that should be worded as statements of fact rather than as direction. -- Website: http://hallambaker.com/ --001a11c3836c0434aa04e61a779a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dir= ectorate's
ongoing effort to review all IETF documents being processed by the<= br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">I= ESG. =A0Document editors and WG chairs should treat these comments just
like any other last call comments.

The document ha= s been produced as part of a proposal to upgrade SPF to standards track rec= ognizing the state of deployment experience.



Minor issues.


1.1.3.  MAIL FROM Definition

<= /div>
I found this section completely opaque and very confusing. It should n= ot be necessary to hunt through other specs to find a definition. Particula= rly since the referenced specs do not give an explicit definition for the t= erm as used and the references point to the whole spec rather than a partic= ular section.

The Security Considerations section is adequate for the= purpose except that no mention is made anywhere in the specification about= DKIM and how a mail receiver should interpret presence of DKIM and SPF pol= icy at the same time. This is a legitimate concern since DKIM is already a = standards track proposal and SPF is only now being promoted to Standards Tr= ack. Thus the SPF document should address the question of dual use.



8.7.  Permerror
&q=
uot;
This signal=
s an error condition that
   definitely requires operator intervention to be resolved.=
"

I cannot imagine a circumstance which definitely requi= res a human to be involved in mail delivery.=A0

11.2. SPF-Authorized Email May Contain Other False Identities Do not construe the "MAIL FROM" and "HELO" identity = authorizations to provide more assurance than they do.


Docu= ment has quasi normative language that should be worded as statements of fa= ct rather than as direction.

--
Website: http://hallambaker.com/
--001a11c3836c0434aa04e61a779a-- From sm@elandsys.com Wed Sep 11 06:23:45 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA7311E81A0; Wed, 11 Sep 2013 06:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grwWIslAHgv4; Wed, 11 Sep 2013 06:23:45 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA52B11E8117; Wed, 11 Sep 2013 06:23:43 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.34]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8BDNQKV021962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Sep 2013 06:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378905820; bh=1BG+P+6sD+YJV3Lg0C6TOIXT80Wd9LP7kiYBEpHIh6U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=G2Nx/i3X0KzKz09wCPOFKCaBwgBcROZifapTi4/7xg0+sCF19N+/PYeP0y4zoRJH4 0Ci2cAp3btFCqtEhXsS9JESjoKuLqqEY29C63MB225Z3JxeZuWAbsqg4tymtW24ctT +d9jaQDWBmCDDVdW7a32Jf8f6JIB+0m3qDiQhz7s= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378905820; i=@elandsys.com; bh=1BG+P+6sD+YJV3Lg0C6TOIXT80Wd9LP7kiYBEpHIh6U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=GJCChcv8bhGvYyGQFIoHpXgRQJbtOSolEu6IKjP3IVJ82qWMmqZFb82DnCHGJE1UF ZaM3sZHIYvKuSPkGf8Hv9NLZRT8EYqskos8ZsPhKEz9N+JFis4NRqFfGx/J94DSHFD XtBbaKZgSqxpXzaxowWczMhaN99tH2it5WbwTDf8= Message-Id: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Sep 2013 06:22:32 -0700 To: Phillip Hallam-Baker , draft-ietf-spfbis-4408bis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [secdir] SECDIR Review of draft-ietf-spfbis-4408bis-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 13:23:45 -0000 Hi Phillip, I am responding to the comment about DKIM only and wait for the SPFBIS WG to address the other issues. At 05:07 11-09-2013, Phillip Hallam-Baker 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. Document editors and WG chairs should treat these comments just >like any other last call comments. > >The document has been produced as part of a proposal to upgrade SPF >to standards track recognizing the state of deployment experience. > >Minor issues. > >1.1.3. MAIL FROM Definition > >I found this section completely opaque and very confusing. It should >not be necessary to hunt through other specs to find a definition. >Particularly since the referenced specs do not give an explicit >definition for the term as used and the references point to the >whole spec rather than a particular section. I am commenting on the following paragraph only: >The Security Considerations section is adequate for the purpose >except that no mention is made anywhere in the specification about >DKIM and how a mail receiver should interpret presence of DKIM and >SPF policy at the same time. This is a legitimate concern since DKIM >is already a standards track proposal and SPF is only now being >promoted to Standards Track. Thus the SPF document should address >the question of dual use. There was a BoF at the last IETF meeting to discuss proposals about how to interpret the presence of DKIM and/or SPF policy at the same time ( http://www.ietf.org/proceedings/87/minutes/minutes-87-dmarc ). The dual use can be addressed as part of the DMARC effort. >8.7. Permerror > >" > >This signals an error condition that > > definitely requires operator intervention to be resolved." > >I cannot imagine a circumstance which definitely requires a human to >be involved in mail delivery. > > >11.2. SPF-Authorized Email May Contain Other False Identities > > Do not construe the "MAIL FROM" and "HELO" identity authorizations to > provide more assurance than they do. > >Document has quasi normative language that should be worded as >statements of fact rather than as direction. > >-- >Website: http://hallambaker.com/ From superuser@gmail.com Wed Sep 11 06:43:56 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74EE11E8171; Wed, 11 Sep 2013 06:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKE8144ORBzo; Wed, 11 Sep 2013 06:43:56 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3F36011E816D; Wed, 11 Sep 2013 06:43:55 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id a12so1880695wgh.2 for ; Wed, 11 Sep 2013 06:43:54 -0700 (PDT) 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=prERtaDMDdfMWqzcemXLy+KUBa2T0SgelMKfJ6xkY9I=; b=POiAlkwzK6xfbQB1XYQAz9/vBxUD9pBrvSCdr0cx9Vqx531i5J6J1KM3GiM3G0oERx MXeEwz1g2IfwZ1SF74+gQLSh8/GFnaDNGUwOiq8LhUlRiGazvkKRfFXSyKJ0UdOty35k 8CjCllve9ysglma9wBsmOJJQga8FG9BekDOpHidpfW1mzL2NeFYYdg/6zdgMjxh8Jur9 tpxyZjG/KIqqThPBdEir886a2Djd93YGHT4A7bT2ErdHsoYt0CuMeqcY/eAQMcC0qmBK PwIate4xuv40kxF5JhWhID4lAxxo5x1pr5NQcTCdgOBSgQr9+3dvsoy/wuuv3W5OJ/v8 lExQ== MIME-Version: 1.0 X-Received: by 10.194.23.196 with SMTP id o4mr1617606wjf.62.1378907034388; Wed, 11 Sep 2013 06:43:54 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Wed, 11 Sep 2013 06:43:54 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> References: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> Date: Wed, 11 Sep 2013 06:43:54 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=047d7b5d9c6bf6907e04e61bcfd2 Cc: "spfbis@ietf.org" , draft-ietf-spfbis-4408bis.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 13:43:56 -0000 --047d7b5d9c6bf6907e04e61bcfd2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 11, 2013 at 6:22 AM, S Moonesamy wrote: > I am responding to the comment about DKIM only and wait for the SPFBIS WG > to address the other issues. > Was the SecDir review for this draft posted to the spfbis list? I haven't seen it. > > The Security Considerations section is adequate for the purpose except >> that no mention is made anywhere in the specification about DKIM and how a >> mail receiver should interpret presence of DKIM and SPF policy at the same >> time. This is a legitimate concern since DKIM is already a standards track >> proposal and SPF is only now being promoted to Standards Track. Thus the >> SPF document should address the question of dual use. >> > > There was a BoF at the last IETF meeting to discuss proposals about how to > interpret the presence of DKIM and/or SPF policy at the same time ( > http://www.ietf.org/**proceedings/87/minutes/**minutes-87-dmarc). The dual use can be addressed as part of the DMARC effort. > DKIM has no intrinsic policy component. Are we actually talking about ADSP here? Assuming we are, I think the best we could do is to note that it's possible for ADSP and SPF to yield conflicting policy results; one could be a "pass" while the other could be a "fail", meaning the receiving MTA now has one "reject" instruction and one "accept" instruction. The receiving ADMD will have to make a decision about which one ought to get precedence. -MSK --047d7b5d9c6bf6907e04e61bcfd2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 11, 2013 at 6:22 AM, S Moonesamy <sm+ietf@= elandsys.com> wrote:
I am responding to the comment about DKIM on= ly and wait for the SPFBIS WG to address the other issues.

Was the SecDir review for this draft posted to the spfb= is list?=A0 I haven't seen it.
=A0

The Security Considerations section is adequate for the purpose except that= no mention is made anywhere in the specification about DKIM and how a mail= receiver should interpret presence of DKIM and SPF policy at the same time= . This is a legitimate concern since DKIM is already a standards track prop= osal and SPF is only now being promoted to Standards Track. Thus the SPF do= cument should address the question of dual use.

There was a BoF at the last IETF meeting to discuss proposals about how to = interpret the presence of DKIM and/or SPF policy at the same time ( http://www.ietf.org/proceedings/87/minutes/minutes-87= -dmarc ). =A0The dual use can be addressed as part of the DMARC effort.=

DKIM has no intrinsic policy component. = =A0 Are we actually talking about ADSP here?

Assuming we = are, I think the best we could do is to note that it's possible for ADS= P and SPF to yield conflicting policy results; one could be a "pass&qu= ot; while the other could be a "fail", meaning the receiving MTA = now has one "reject" instruction and one "accept" instr= uction.=A0 The receiving ADMD will have to make a decision about which one = ought to get precedence.

-MSK
--047d7b5d9c6bf6907e04e61bcfd2-- From hallam@gmail.com Wed Sep 11 07:33:48 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D469921E80C3; Wed, 11 Sep 2013 07:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EafxDzFuf3NQ; Wed, 11 Sep 2013 07:33:48 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id BCA8621E812A; Wed, 11 Sep 2013 07:33:46 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id lv10so821243lab.9 for ; Wed, 11 Sep 2013 07:33:45 -0700 (PDT) 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=oSxmF9jOzFdU7bl9ju6086GgfsTU/VQi8e3GGGxoB4I=; b=1CDMDGdhFQGH180Q6LdfOchU34qFsXhFlCAO3WkfeWDaJBjh6V5yRI9ryQIPI38ICe TO5HkA7jDtO4cZBsK3l+bgQFvWvCq032DMLcOL2ksF/ejJIUWA8RWM1mjmqhYV+J3wkh gQ/Fs4GYebbJiUZ1icd7VeMcE2riOUlohtmMnt8XFFRN/GykPz/U8VNrIi176xCwbV6r 14E3Zb2sAhc9JjbWq9Etk4iLuJ7dSu8oeVZJbv2BtEQbqww2I8V+X88mCI4LCJFyyzeL UeaXzm8gJkdR2xWXHvV9keeCw4MBhpf7KY3c1UD4dhjCHF9ZgMrJqFBpkxLXK0T9Ncn6 Ju5A== MIME-Version: 1.0 X-Received: by 10.152.4.6 with SMTP id g6mr340185lag.50.1378910025535; Wed, 11 Sep 2013 07:33:45 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Wed, 11 Sep 2013 07:33:45 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> Date: Wed, 11 Sep 2013 10:33:45 -0400 Message-ID: From: Phillip Hallam-Baker To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=089e013d1e603fd71604e61c82e5 Cc: "spfbis@ietf.org" , draft-ietf-spfbis-4408bis.all@tools.ietf.org, "secdir@ietf.org" , S Moonesamy , The IESG Subject: Re: [secdir] [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 14:33:49 -0000 --089e013d1e603fd71604e61c82e5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 11, 2013 at 9:43 AM, Murray S. Kucherawy wrote: > On Wed, Sep 11, 2013 at 6:22 AM, S Moonesamy wrote: > >> I am responding to the comment about DKIM only and wait for the SPFBIS WG >> to address the other issues. >> > > Was the SecDir review for this draft posted to the spfbis list? I haven't > seen it. > The draft-ietf-spfbis-4408bis.all@tools.ietf.org doesn't cover it? I thought that was the point. > >> The Security Considerations section is adequate for the purpose except >>> that no mention is made anywhere in the specification about DKIM and how a >>> mail receiver should interpret presence of DKIM and SPF policy at the same >>> time. This is a legitimate concern since DKIM is already a standards track >>> proposal and SPF is only now being promoted to Standards Track. Thus the >>> SPF document should address the question of dual use. >>> >> >> There was a BoF at the last IETF meeting to discuss proposals about how >> to interpret the presence of DKIM and/or SPF policy at the same time ( >> http://www.ietf.org/**proceedings/87/minutes/**minutes-87-dmarc). The dual use can be addressed as part of the DMARC effort. >> > > DKIM has no intrinsic policy component. Are we actually talking about > ADSP here? > If a message has a DKIM signature and it is valid for the sending domain then that is strong evidence that the owner of the domain intended to send it. Hence DKIM Signature overlaps with SPF policy. Regardless RFC 5617 is standards track and it is a part of DKIM and the SPF document should probably mention it as well. > Assuming we are, I think the best we could do is to note that it's > possible for ADSP and SPF to yield conflicting policy results; one could be > a "pass" while the other could be a "fail", meaning the receiving MTA now > has one "reject" instruction and one "accept" instruction. The receiving > ADMD will have to make a decision about which one ought to get precedence. > I suspect that the answer is that SPF will take precedence simply because the MailFROM will be received and acted upon before the MTA has enough information to act on DKIM information. An MTA that decides email is spam on the basis of SPF is likely to drop the connection or tar pit it. I doubt it is going to bother to check a DKIM signature. -- Website: http://hallambaker.com/ --089e013d1e603fd71604e61c82e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Sep 11, 2013 at 9:43 AM, Murray S. Kucherawy <superuser@= gmail.com> wrote:
On Wed, Sep 11, 2013 at= 6:22 AM, S Moonesamy <sm+ietf@elandsys.com> wrote:
I am responding to the comment about DKIM only and wait fo= r the SPFBIS WG to address the other issues.

Was the SecDir review for this draft posted to th= e spfbis list?=A0 I haven't seen it.

The draft-ietf-spfbis-4408bis.all@tools.ietf.org doesn&#= 39;t cover it? I thought that was the point.


=A0

The Security Considerations section is adequate for the purpose except that= no mention is made anywhere in the specification about DKIM and how a mail= receiver should interpret presence of DKIM and SPF policy at the same time= . This is a legitimate concern since DKIM is already a standards track prop= osal and SPF is only now being promoted to Standards Track. Thus the SPF do= cument should address the question of dual use.

There was a BoF at the last IETF meeting to discuss proposals about how to = interpret the presence of DKIM and/or SPF policy at the same time ( http://www.ietf.org/proceedings/87/minutes/minutes-87= -dmarc ). =A0The dual use can be addressed as part of the DMARC effort.=

DKIM has no intrinsic policy compone= nt. =A0 Are we actually talking about ADSP here?

If a message has a DKIM signature and it = is valid for the sending domain then that is strong evidence that the owner= of the domain intended to send it. Hence DKIM Signature overlaps with SPF = policy.=A0

Regardless RFC 5617 is standards track and it is a part= of DKIM and the SPF document should probably mention it as well.

=A0
Assuming we are, I think the best we could do is to note that i= t's possible for ADSP and SPF to yield conflicting policy results; one = could be a "pass" while the other could be a "fail", me= aning the receiving MTA now has one "reject" instruction and one = "accept" instruction.=A0 The receiving ADMD will have to make a d= ecision about which one ought to get precedence.

I suspect that the answe= r is that SPF will take precedence simply because the MailFROM will be rece= ived and acted upon before the MTA has enough information to act on DKIM in= formation. An MTA that decides email is spam on the basis of SPF is likely = to drop the connection or tar pit it. I doubt it is going to bother to chec= k a DKIM signature.=A0

--
Website: ht= tp://hallambaker.com/
--089e013d1e603fd71604e61c82e5-- From weiler@watson.org Wed Sep 11 08:17:28 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6B911E8181; Wed, 11 Sep 2013 08:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kG3sbDBLViZ6; Wed, 11 Sep 2013 08:17:23 -0700 (PDT) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by ietfa.amsl.com (Postfix) with ESMTP id 57C1911E826A; Wed, 11 Sep 2013 08:17:13 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id BB29046B42; Wed, 11 Sep 2013 11:17:01 -0400 (EDT) Received: from fledge.watson.org (weiler@localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.7/8.14.7) with ESMTP id r8BFH1Tx013839; Wed, 11 Sep 2013 11:17:01 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.7/8.14.7/Submit) with ESMTP id r8BFH0ia013831; Wed, 11 Sep 2013 11:17:00 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 11 Sep 2013 11:17:00 -0400 (EDT) From: Samuel Weiler To: Ray Bellis In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE90676@wds-exc1.okna.nominet.org.uk> Message-ID: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE90676@wds-exc1.okna.nominet.org.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Wed, 11 Sep 2013 16:17:01 +0100 (BST) Cc: "iesg@ietf.org" , "draft-ietf-homenet-arch.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-homenet-arch-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 15:17:29 -0000 On Wed, 11 Sep 2013, Ray Bellis wrote: >> -- "The name space(s) should be served authoritatively by the >> homenet..." Why is that necessary? (Indeed, there is text in >> 3.7.4 that seems to conflict with this.) ... > Can you please indicate which text you believe is in conflict? Sure. in 3.7.3: "The name space(s) should be served authoritatively by the homenet, most likely by a server resident on the CER." in 3.7.4 "One approach ... is to run an authoritative name service on the CER and a secondary resolving name service provided by the ISP or perhaps a cloud-based third party." The former I see as more prescriptive (you should do X) and the latter as just a suggestion (one idea is X). I was challenging the prescription. The quotes are necessarily in conflict, but they seem to carry very different force. >> -- There is a recommendation to support DNSSEC on the authoritative >> server side (in 3.7.4). Shouldn't there be a similar >> recommendation on the resolver side? > > That (short) paragraph is not specific to authoritative servers, it > applies to the entire section. The example of cache-poisoning > further indicates its applicability to recursive resolution. That is not clear from the text. I read "it is desirable to support appropriate name service security methods, including DNSSEC." and interpreted as shown above. -- Sam From Ted.Lemon@nominum.com Wed Sep 11 08:39:22 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917F221F9B26; Wed, 11 Sep 2013 08:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.481 X-Spam-Level: X-Spam-Status: No, score=-106.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3JoylqgyGlC; Wed, 11 Sep 2013 08:39:15 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id BE13011E81A8; Wed, 11 Sep 2013 08:39:15 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUjCOo5oJl02KOSduxhNmrI41riDLtZFF@postini.com; Wed, 11 Sep 2013 08:39:15 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0C83C1B82A4; Wed, 11 Sep 2013 08:39:15 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 62F0C190074; Wed, 11 Sep 2013 08:39:12 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.03.0158.001; Wed, 11 Sep 2013 08:39:12 -0700 From: Ted Lemon To: Samuel Weiler Thread-Topic: secdir review of draft-ietf-homenet-arch-10 Thread-Index: AQHOrpotcPqjIoy9fUumqq7T/fdL8JnAohQAgAAJHACAAHDgAIAABjQA Date: Wed, 11 Sep 2013 15:39:11 +0000 Message-ID: <9E3806AB-46ED-4CF8-BA00-9C8EF3B59363@nominum.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE90676@wds-exc1.okna.nominet.org.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ray Bellis , "iesg@ietf.org" , "draft-ietf-homenet-arch.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-homenet-arch-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 15:39:22 -0000 On Sep 11, 2013, at 11:17 AM, Samuel Weiler wrote: > I was challenging the prescription. The quotes are necessarily in confli= ct, but they seem to carry very different force. Actually they aren't in conflict. 3.7.3 is saying "you need an authoritat= ive name server on the local net." 3.7.4 is saying "if you want names to = be resolved externally, one way to make this work would be to set up second= aries on external servers." In fact, the solution that I've seen discussed= recently is to have the master on the local network be a hidden master, so= that the only published authoritative servers for the zone would be the se= condaries. But the architecture document rightly avoids prescribing that = solution. From Ray.Bellis@nominet.org.uk Wed Sep 11 08:57:04 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BCA11E81A8; Wed, 11 Sep 2013 08:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdiUgg3iDjqS; Wed, 11 Sep 2013 08:56:58 -0700 (PDT) Received: from mx2.nominet.org.uk (mx2.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id 10C9621F9B8C; Wed, 11 Sep 2013 08:56:45 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=Tz1UkZbsJZxf6MjTotuJ3avdQvGd+HLrCfZYQY0645C2ZFfVs6JeBLQD 8Dl5eiPHAIkLrmEmpgejcSq8n7yDATG4DZ/rllYtq3w2nJClMLof0IyKJ XLrEXjzYGN9SPtJ; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1378915006; x=1410451006; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LFJoP92rsa9xmhnNZITCFJTiAoX1pYB4/5uWc//TTHA=; b=yYQCuI+7y259AgVEvmfgXGAkKvIRfDDA4zE9Tv2Zo2d16OKIJqONGuz3 aeCqz+3NG4zZGHK230CbLC+pnkdyIkzwZ9E+U8XCmBXLlhqJRRodpHvNt CgWYwaWYUNJvQfA; X-IronPort-AV: E=Sophos;i="4.90,885,1371078000"; d="scan'208";a="2984942" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 11 Sep 2013 16:56:40 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Wed, 11 Sep 2013 16:56:40 +0100 From: Ray Bellis To: Ted Lemon , Samuel Weiler Thread-Topic: secdir review of draft-ietf-homenet-arch-10 Thread-Index: AQHOrpowneGtTVadlEOUAKAd3eCKbZnAG/gAgAAJHACAAHDgAIAABjOAgAAE4YA= Date: Wed, 11 Sep 2013 15:56:39 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE92101@wds-exc1.okna.nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE90676@wds-exc1.okna.nominet.org.uk> <9E3806AB-46ED-4CF8-BA00-9C8EF3B59363@nominum.com> In-Reply-To: <9E3806AB-46ED-4CF8-BA00-9C8EF3B59363@nominum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <7DA70F5E29F4DB4ABFEB7E803DBE1F83@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "iesg@ietf.org IESG" , "draft-ietf-homenet-arch.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-homenet-arch-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 15:57:05 -0000 On 11 Sep 2013, at 16:39, Ted Lemon wrote: > Actually they aren't in conflict. 3.7.3 is saying "you need an authorit= ative name server on the local net." 3.7.4 is saying "if you want names t= o be resolved externally, one way to make this work would be to set up seco= ndaries on external servers." In fact, the solution that I've seen discuss= ed recently is to have the master on the local network be a hidden master, = so that the only published authoritative servers for the zone would be the = secondaries. But the architecture document rightly avoids prescribing tha= t solution. I think the confusion is caused by the use of the phrase "secondary resolvi= ng name service" in 3.7.4 Ted is (correctly, I think) taking the intent of that to mean a secondary _= authoritative_ service, but us DNS heads think of "resolving" as what stubs= and recursive servers do. Tim - can you please clarify the intent? Ray From superuser@gmail.com Wed Sep 11 09:35:13 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4B521E818E; Wed, 11 Sep 2013 09:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VA0jNJwNVgkF; Wed, 11 Sep 2013 09:35:11 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3132521E813D; Wed, 11 Sep 2013 09:35:10 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so2429971wiw.11 for ; Wed, 11 Sep 2013 09:35:09 -0700 (PDT) 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=OFUEkfGms1yjtgV9g6CStIWaSTTg9EedrPvmm+62DuE=; b=lC9BqIACzOjHoq5zT09Z8dZ03ZRerzFXVllcP+H7mMwow3rZcW4Y2zNXQZXcXMy+Rr h84zmPDE69W5RGLMJKHRPAJCuxM/Vgvl7h3SuuvwdqhLFLzSsHuFFkmabUGCTxEKdgRP r0OWJixwg7Wtzedd2t8o1u3dZspTZOTI9S7HuX+pa95bglO5osSqly81ESOSnUbI9ATa HylXrglE8/8bw+FjOkZxHtw+EnOck6nUjI6yO9DdoDxVDL5IYxCnp/1nouvOUj4+++VY tWVSdWeu70y09HoFPFUTdtesfCoOtmWZcKQY/pUGe4YdtYHhh38bp+mFk4QbiLutRvYw HchA== MIME-Version: 1.0 X-Received: by 10.180.211.19 with SMTP id my19mr2155121wic.19.1378917309327; Wed, 11 Sep 2013 09:35:09 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Wed, 11 Sep 2013 09:35:09 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> Date: Wed, 11 Sep 2013 09:35:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=001a11c3855665aee904e61e3419 Cc: "spfbis@ietf.org" , draft-ietf-spfbis-4408bis.all@tools.ietf.org, "secdir@ietf.org" , S Moonesamy , The IESG Subject: Re: [secdir] [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 16:35:14 -0000 --001a11c3855665aee904e61e3419 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 11, 2013 at 7:33 AM, Phillip Hallam-Baker wrote: > On Wed, Sep 11, 2013 at 9:43 AM, Murray S. Kucherawy wrote: > >> On Wed, Sep 11, 2013 at 6:22 AM, S Moonesamy wrote: >> >>> I am responding to the comment about DKIM only and wait for the SPFBIS >>> WG to address the other issues. >>> >> >> Was the SecDir review for this draft posted to the spfbis list? I >> haven't seen it. >> > > The draft-ietf-spfbis-4408bis.all@tools.ietf.org doesn't cover it? I > thought that was the point. > I'm pretty sure it's authors, shepherds, and co-chairs only, not the whole WG. > > > > >> >>> The Security Considerations section is adequate for the purpose except >>>> that no mention is made anywhere in the specification about DKIM and how a >>>> mail receiver should interpret presence of DKIM and SPF policy at the same >>>> time. This is a legitimate concern since DKIM is already a standards track >>>> proposal and SPF is only now being promoted to Standards Track. Thus the >>>> SPF document should address the question of dual use. >>>> >>> >>> There was a BoF at the last IETF meeting to discuss proposals about how >>> to interpret the presence of DKIM and/or SPF policy at the same time ( >>> http://www.ietf.org/**proceedings/87/minutes/**minutes-87-dmarc). The dual use can be addressed as part of the DMARC effort. >>> >> >> DKIM has no intrinsic policy component. Are we actually talking about >> ADSP here? >> > > If a message has a DKIM signature and it is valid for the sending domain > then that is strong evidence that the owner of the domain intended to send > it. Hence DKIM Signature overlaps with SPF policy. > Ah, I see where you're going now. > > Regardless RFC 5617 is standards track and it is a part of DKIM and the > SPF document should probably mention it as well. > ADSP has seen so little adoption that I think it would actually be a mistake to pay it any homage here. I think your point above about DKIM proper is the more interesting one. > > > >> Assuming we are, I think the best we could do is to note that it's >> possible for ADSP and SPF to yield conflicting policy results; one could be >> a "pass" while the other could be a "fail", meaning the receiving MTA now >> has one "reject" instruction and one "accept" instruction. The receiving >> ADMD will have to make a decision about which one ought to get precedence. >> > > I suspect that the answer is that SPF will take precedence simply because > the MailFROM will be received and acted upon before the MTA has enough > information to act on DKIM information. An MTA that decides email is spam > on the basis of SPF is likely to drop the connection or tar pit it. I doubt > it is going to bother to check a DKIM signature. > Right, I had forgotten about this as well. I shouldn't reply to SecDir without being appropriately caffeinated. It's not necessarily the case that an SPF failure will be acted upon before DKIM even gets evaluated. Though that is clearly for many installations the optimal use because you don't have to deal with the body, any MTA that wants to give DKIM due consideration as well will have to store the SPF result and then decide on it later. And there are sites that do prefer it that way, not the least of which is the entire DMARC community. This draft is already worded such that one can merely observe the SPF result and record it rather than enacting it as soon as possible, possibly using it as one input to a larger equation. This use case could bolster that argument by providing an example, and could even be done without naming DKIM specifically. Of course, the downside is that the receiver has to deal with accepting the body. As long as the tradeoff is made clear (if it isn't already), we might consider adding it. -MSK --001a11c3855665aee904e61e3419 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 11, 2013 at 7:33 AM, Phillip Hallam-Baker <hal= lam@gmail.com> wrote:
On Wed, Sep 11, 2013 at 9:4= 3 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Wed, Sep 11, 2013 at 6:22 AM, S Moonesamy <sm+= ietf@elandsys.com> wrote:
I am responding to the comment about DKIM only and wait fo= r the SPFBIS WG to address the other issues.

Was the SecDir review for this draft posted to th= e spfbis list?=A0 I haven't seen it.

The draft-ietf-spfbis-4408bis.all@to= ols.ietf.org doesn't cover it? I thought that was the point.

I'm pretty sure it&#= 39;s authors, shepherds, and co-chairs only, not the whole WG.
=A0


=A0

The Security Considerations section is adequate for the purpose except that= no mention is made anywhere in the specification about DKIM and how a mail= receiver should interpret presence of DKIM and SPF policy at the same time= . This is a legitimate concern since DKIM is already a standards track prop= osal and SPF is only now being promoted to Standards Track. Thus the SPF do= cument should address the question of dual use.

There was a BoF at the last IETF meeting to discuss proposals about how to = interpret the presence of DKIM and/or SPF policy at the same time ( http://www.ietf.org/proceedings/87/minutes/minutes-87= -dmarc ). =A0The dual use can be addressed as part of the DMARC effort.=

DKIM has no intrinsic policy compone= nt. =A0 Are we actually talking about ADSP here?

If a message has a DKIM signature a= nd it is valid for the sending domain then that is strong evidence that the= owner of the domain intended to send it. Hence DKIM Signature overlaps wit= h SPF policy.

Ah, I see where you'= re going now.
=A0
=A0
Regardless RFC 5617 is standards t= rack and it is a part of DKIM and the SPF document should probably mention = it as well.

ADSP has seen= so little adoption that I think it would actually be a mistake to pay it a= ny homage here.=A0 I think your point above about DKIM proper is the more i= nteresting one.
=A0

=A0
Assuming we are, I think the best we could do is to note that i= t's possible for ADSP and SPF to yield conflicting policy results; one = could be a "pass" while the other could be a "fail", me= aning the receiving MTA now has one "reject" instruction and one = "accept" instruction.=A0 The receiving ADMD will have to make a d= ecision about which one ought to get precedence.

I suspect that the= answer is that SPF will take precedence simply because the MailFROM will b= e received and acted upon before the MTA has enough information to act on D= KIM information. An MTA that decides email is spam on the basis of SPF is l= ikely to drop the connection or tar pit it. I doubt it is going to bother t= o check a DKIM signature.=A0

Right, I had forgotten a= bout this as well.=A0 I shouldn't reply to SecDir without being appropr= iately caffeinated.

It's not necessarily the case tha= t an SPF failure will be acted upon before DKIM even gets evaluated.=A0 Tho= ugh that is clearly for many installations the optimal use because you don&= #39;t have to deal with the body, any MTA that wants to give DKIM due consi= deration as well will have to store the SPF result and then decide on it la= ter.=A0 And there are sites that do prefer it that way, not the least of wh= ich is the entire DMARC community.

This draft is already worded such that one can merely observ= e the SPF result and record it rather than enacting it as soon as possible,= possibly using it as one input to a larger equation.=A0 This use case coul= d bolster that argument by providing an example, and could even be done wit= hout naming DKIM specifically.=A0 Of course, the downside is that the recei= ver has to deal with accepting the body.=A0 As long as the tradeoff is made= clear (if it isn't already), we might consider adding it.

-MSK

--001a11c3855665aee904e61e3419-- From dotzero@gmail.com Wed Sep 11 07:43:34 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E60121E811B; Wed, 11 Sep 2013 07:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4tMI+FgMre6; Wed, 11 Sep 2013 07:43:33 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id E008421E80B1; Wed, 11 Sep 2013 07:43:32 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id ev20so7299535lab.8 for ; Wed, 11 Sep 2013 07:43:31 -0700 (PDT) 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=oQa+aiAN9WOxBEq8tB45uXMraS7w9sEwPffFK0PAPtU=; b=gzZFxCfxw50aD0c+fRKoPmePUJMKo0OAq1pmPKahIzV6WpzlnXPWYEo1lr3JzYites 2HylnTIbwrnnbkwLLQOhyIZIJfd3FAVci2Otybg37tAIb9eLDT6VgFZ2BwRoNze8T/TR MGh3tuZlOvNVjDSOEV5MUhPrUsSZ8Aj75ACv6MEUFZwhin38v7dQiOw78VEYkXzTUU0b AH/VnH4XR4VyRGpPQXHGwqPQog5IN3Ejcy9yyoaD21f5xEJ87/66V2NWQ3NzJIGLNznO TUv7aiG2iZSg+SsjKt07lA9hbP7lRJ15rtOc3tooaPkBLl9Hfl7f+ME53RgSeDbwqRnY B8oA== MIME-Version: 1.0 X-Received: by 10.112.11.20 with SMTP id m20mr17320lbb.56.1378910611771; Wed, 11 Sep 2013 07:43:31 -0700 (PDT) Received: by 10.112.137.163 with HTTP; Wed, 11 Sep 2013 07:43:31 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> Date: Wed, 11 Sep 2013 10:43:31 -0400 Message-ID: From: Dotzero To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 11 Sep 2013 11:19:22 -0700 Cc: "secdir@ietf.org" , S Moonesamy , "spfbis@ietf.org" , The IESG , draft-ietf-spfbis-4408bis.all@tools.ietf.org Subject: Re: [secdir] [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 14:43:34 -0000 On Wed, Sep 11, 2013 at 9:43 AM, Murray S. Kucherawy wrote: > On Wed, Sep 11, 2013 at 6:22 AM, S Moonesamy wrote: >> >> I am responding to the comment about DKIM only and wait for the SPFBIS WG >> to address the other issues. > > > Was the SecDir review for this draft posted to the spfbis list? I haven't > seen it. > >> >> >>> The Security Considerations section is adequate for the purpose except >>> that no mention is made anywhere in the specification about DKIM and how a >>> mail receiver should interpret presence of DKIM and SPF policy at the same >>> time. This is a legitimate concern since DKIM is already a standards track >>> proposal and SPF is only now being promoted to Standards Track. Thus the SPF >>> document should address the question of dual use. >> >> >> There was a BoF at the last IETF meeting to discuss proposals about how to >> interpret the presence of DKIM and/or SPF policy at the same time ( >> http://www.ietf.org/proceedings/87/minutes/minutes-87-dmarc ). The dual use >> can be addressed as part of the DMARC effort. > > > DKIM has no intrinsic policy component. Are we actually talking about ADSP > here? > > Assuming we are, I think the best we could do is to note that it's possible > for ADSP and SPF to yield conflicting policy results; one could be a "pass" > while the other could be a "fail", meaning the receiving MTA now has one > "reject" instruction and one "accept" instruction. The receiving ADMD will > have to make a decision about which one ought to get precedence. > > ADSP should be relegated to historical. Very little implementation on the publishing side and even less validation on the receiving side. We (all of the usual suspects in this space) made compromises to get it out the door and we collectively got it wrong. Having said that, I could live with some kind of note in the SPFbis doc along the lines of what Murray suggests. Mike From dhc@dcrocker.net Wed Sep 11 07:51:40 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D715621E80B6; Wed, 11 Sep 2013 07:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7L+pAmVMZyHg; Wed, 11 Sep 2013 07:51:36 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6F521F9EE9; Wed, 11 Sep 2013 07:51:36 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r8BEpJeo018418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Sep 2013 07:51:22 -0700 Message-ID: <52308352.2060902@dcrocker.net> Date: Wed, 11 Sep 2013 07:50:58 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> In-Reply-To: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 11 Sep 2013 07:51:22 -0700 (PDT) X-Mailman-Approved-At: Wed, 11 Sep 2013 11:19:22 -0700 Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 14:51:41 -0000 On 9/11/2013 6:22 AM, S Moonesamy wrote: > I am commenting on the following paragraph only: > >> The Security Considerations section is adequate for the purpose except >> that no mention is made anywhere in the specification about DKIM and >> how a mail receiver should interpret presence of DKIM and SPF policy >> at the same time. This is a legitimate concern since DKIM is already a >> standards track proposal and SPF is only now being promoted to >> Standards Track. Thus the SPF document should address the question of >> dual use. > > There was a BoF at the last IETF meeting to discuss proposals about how > to interpret the presence of DKIM and/or SPF policy at the same time ( > http://www.ietf.org/proceedings/87/minutes/minutes-87-dmarc ). The dual > use can be addressed as part of the DMARC effort. At the level of a fully-integrated email anti-abuse system, concern about possible SPF and DKIM presence and interaction effects is, of course, essential. However SPF is only a component technology. It's specification is not the place for discussing higher-level interaction effects. By way of example, imagine the specification for an automobile tire being expected to talk about design and operations issues when the tire is linked to 3 siblings and a suspension system, and a motor and... That's an important topic, but the tire spec is wrong venue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From kivinen@iki.fi Thu Sep 12 03:40:50 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D714411E81A1 for ; Thu, 12 Sep 2013 03:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+Twcyg9878J for ; Thu, 12 Sep 2013 03:40:47 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id DB5A511E812D for ; Thu, 12 Sep 2013 03:40:46 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r8CAeg0D015701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 12 Sep 2013 13:40:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r8CAegxj013545; Thu, 12 Sep 2013 13:40:42 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21041.39466.335354.782772@fireball.kivinen.iki.fi> Date: Thu, 12 Sep 2013 13:40:42 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 10:40:50 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Yaron Sheffer is next in the rotation. For telechat 2013-09-12 Reviewer LC end Draft Dave Cridland T 2013-08-29 draft-ietf-repute-email-identifiers-09 Alan DeKok T 2013-08-29 draft-ietf-repute-media-type-12 Sam Hartman T 2013-09-03 draft-ietf-mediactrl-call-flows-13 Jeffrey Hutzelman T 2013-09-03 draft-ietf-mpls-targeted-mldp-04 Last calls and special requests: Rob Austein 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Rob Austein 2013-08-29 draft-ietf-netext-update-notifications-08 Dave Cridland - draft-ietf-httpbis-p5-range-23 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-03-30 draft-ietf-roll-terminology-12 Dan Harkins 2013-09-02 draft-ietf-ccamp-gmpls-signaling-g709v3-11 Jeffrey Hutzelman 2013-07-16 draft-yusef-dispatch-ccmp-indication-04 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-04 Scott Kelly 2013-09-16 draft-kelsey-intarea-mesh-link-establishment-05 Warren Kumari 2013-09-19 draft-ietf-ccamp-otn-g709-info-model-11 Julien Laganier - draft-ietf-avtcore-rtp-security-options-06 Julien Laganier - draft-ietf-websec-key-pinning-08 Julien Laganier 2013-09-17 draft-ietf-ccamp-swcaps-update-03 Ben Laurie 2013-09-23 draft-ietf-idr-rfd-usable-03 Matt Lepinski 2013-09-24 draft-ietf-l2vpn-pbb-vpls-interop-05 Catherine Meadows 2013-09-23 draft-ietf-l2vpn-vpls-mcast-14 Alexey Melnikov - draft-ietf-payload-rtp-howto-05 Kathleen Moriarty 2013-10-01 draft-resnick-retire-std1-01 Sandy Murphy 2013-09-20 draft-ietf-6man-ext-transmit-03 Yoav Nir - draft-ietf-dime-app-design-guide-19 Magnus Nystrom 2013-09-24 draft-ietf-insipid-session-id-reqts-08 Radia Perlman 2013-09-24 draft-ietf-mmusic-delayed-duplication-02 Vincent Roca 2013-09-24 draft-ietf-mmusic-duplication-grouping-03 Joe Salowey 2013-09-23 draft-ietf-sidr-bgpsec-threats-06 Ondrej Sury 2013-08-16 draft-nandakumar-rtcweb-stun-uri-07 David Waltermire - draft-ietf-repute-considerations-02 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-13 Brian Weis - draft-ietf-radext-dtls-06 Glen Zorn 2012-11-27 draft-ietf-lisp-eid-block-05 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 -- kivinen@iki.fi From scott@hyperthought.com Thu Sep 12 13:09:44 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D46211E80AD for ; Thu, 12 Sep 2013 13:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeI+Ax7rMt3C for ; Thu, 12 Sep 2013 13:09:39 -0700 (PDT) Received: from smtp152.iad.emailsrvr.com (smtp152.iad.emailsrvr.com [207.97.245.152]) by ietfa.amsl.com (Postfix) with ESMTP id 390E011E8105 for ; Thu, 12 Sep 2013 13:09:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp25.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 88F873005B8; Thu, 12 Sep 2013 16:09:36 -0400 (EDT) X-Virus-Scanned: OK Received: from legacy9.wa-web.iad1a (legacy9.wa-web.iad1a.rsapps.net [192.168.4.111]) by smtp25.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 2DF173005BB; Thu, 12 Sep 2013 16:09:36 -0400 (EDT) Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by legacy9.wa-web.iad1a (Postfix) with ESMTP id 18B1E1F8119; Thu, 12 Sep 2013 16:09:36 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Thu, 12 Sep 2013 13:09:36 -0700 (PDT) Date: Thu, 12 Sep 2013 13:09:36 -0700 (PDT) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-kelsey-intarea-mesh-link-establishment.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1379016576.09930416@apps.rackspace.com> X-Mailer: webmail7.0 Subject: [secdir] secdir review of draft-kelsey-intarea-mesh-link-establishment X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 20:09:44 -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.=0A=0AFrom the abstract: "This document defines = the mesh link establishment (MLE) protocol for establishing and configuring= secure radio links in IEEE 802.15.4 radio mesh networks." It defines a UDP= -based protocol to configure radio links, facilitate network-wide changes t= o radio parameters, and detect neighboring devices.=0A=0AThe protocol is in= tended for IEEE 802.15.4 mesh networks, and it re-uses features from this l= ink-layer protocol. I haven't been keeping up with this IEEE effort, so whe= n I opened the draft I was a complete noob. =0A=0AI have comments/questions= about 3 things in the document:=0A=0A1) The protocol mostly relies on the = security mechanisms of 802.15.4, except that it adds an anti-replay mechani= sm. This mechanism requires a a message recipient to send a challenge to a = newly-heard neighbor, and for that neighbor to return the same challenge. T= he challenge is defined as a TLV. Although RFC4086 is referenced for challe= nge generation, no minimum challenge length is specified. Does that mean a = one-byte random challenge is okay? Since the text also says "A new value MU= ST be chosen for each Challenge TLV transmitted", you probably want to spec= ify a reasonable minimum length.=0A=0A2) Section 5 says "MLE security MUST = NOT use any key that is being used by the link (or any other) layer." I thi= nk the point you're trying to make is that because of CCM, key re-use is po= tentially toxic. It might be good to explicitly state this.=0A=0A3) Prior t= o the text just referenced, it says, "If MLE security is in use each device= MUST maintain an outgoing MLE frame counter for use in securing outgoing p= ackets in compliance with [CCM]. This MAY be the same frame counter used f= or securing 802.15.4 frames; in this case the same counter value MUST NOT b= e used for securing both an 802.15.4 message and an MLE message."=0A=0AMayb= e I'm just missing it, but I don't understand the need for MUST NOT here. S= ince they must have different keys, what harm results from using the same c= ounter value in distinct protocols?=0A=0A=0A--Scott=0A From rdroms@cisco.com Fri Sep 13 14:32:03 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F56911E80D2; Fri, 13 Sep 2013 14:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1pe4FhmrZx1; Fri, 13 Sep 2013 14:31:55 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B102511E80AD; Fri, 13 Sep 2013 14:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4139; q=dns/txt; s=iport; t=1379107916; x=1380317516; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tX3Uo6kx8l9a97doGaVeIgs8xjNvsMGLMe6u7R4O8DQ=; b=RSwXMcTTmoK8czuyHyyu4fI+BIBqJR9QuEmk9JHXi9OBSzfVTeEyAqz6 v61Rkm6ozmg7HwnVM4nAwmkJNJpDupBSBkUqhHkpI9bp9a8KA1Q933XoH uSrV1zS7Ze7ls6jZa4Q15jp5asrMAg6QMYXUDvPz2jtmzOTGtOoXv4vbp E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAPiCM1KtJXG//2dsb2JhbABYA4MHgQrAe4EdFnSCJQEBAQMBOj8FCwIBCCIUEDIlAgQOBQiHaQMJBrAKCIkwjz4CIRAHEYMNgQADqW6DJIIq X-IronPort-AV: E=Sophos;i="4.90,900,1371081600"; d="scan'208";a="259540113" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 13 Sep 2013 21:31:55 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8DLVtBX004123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Sep 2013 21:31:55 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.202]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Fri, 13 Sep 2013 16:31:54 -0500 From: "Ralph Droms (rdroms)" To: ietfdbh Thread-Topic: secdir review of draft-ietf-dhc-dhcpv6-solmaxrt-update-03 Thread-Index: AQHOsMiqOZO8k1rZU0CLwj3Ipo/ffQ== Date: Fri, 13 Sep 2013 21:31:54 +0000 Message-ID: <4518F39EB578034D8C99A9B7776CDBA301B3CC3B@xmb-aln-x04.cisco.com> References: <017901cea661$313309b0$93991d10$@comcast.net> In-Reply-To: <017901cea661$313309b0$93991d10$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.248.169] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-dhc-dhcpv6-solmaxrt-update@tools.ietf.org" , "iesg@ietf.org IESG" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-dhc-dhcpv6-solmaxrt-update-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 21:32:03 -0000 Thanks for your review. Comments in line; all edits to appear in -04 rev. On Aug 31, 2013, at 11:46 AM 8/31/13, ietfdbh wrote: > I have reviewed this document as part of the security directorate's ongoi= ng > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments ju= st > like any other last call comments. >=20 > The document describes a change to the values of DHCPv6 Options for Solic= it > and Information timeout values (SOL_MAX_RT and INF_MAX_RT). >=20 > I am not very knowledgeable about DHCPv6 options, but I have a few > questions. > 1) section 6 says " the client MUST process an included SOL_MAX_RT option > and/or an included INF_MAX_RT option"; this could be interpreted as OR ev= en > if both are present. Hopefully no implementer would make that choice, but > they could claim compliance if they did.=20 > It would be tighter to say they MUST process SOL-MAX-RT and MUST process > INF_MAX_RT ... Another artifact of adding INF_MAX_RT to the document. Thanks for the sugg= ested text, which I've used > 2) section 7 says " A DHCPv6 client MUST include the SOL_MAX_RT option co= de > in an Option Request option [RFC3315] in any message it sends." Is this > really required for every message? Hm. This text is actually somewhat redundant as RFC 3315 is authoritative = as to when the Option Request option is sent. Changed to: A DHCPv6 client MUST include the SOL_MAX_RT option code in any Option Request option [RFC3315] it sends as required by RFC 3315. > 3) if #2 is true, then section 8 seems to have some unnecessary > conditionals. "the server will send option SOL_MAX_RT and INF_MAX_RT only= if > .... the client requested those options ...". Doesn't section 7 say the > client is REQUIRED to request these options? I think the text as it stands is appropriate for clarity regarding interope= ration with non-compliant clients. Otherwise, an implementor might interpr= et the text as requiring that the server send the options even if the clien= t has not requested them. > 4) similar to question #3, in section 8 paragraph 2, the server responds = to > " a client that has included the SOL_MAX_RT option code in an Option > Request option"; doesn't section 7 REQUIRE that the client include this? > Ditto for paragraph 3 and INF_MAX_RT? Previous answer applies here, as well. > 5) In security considerations, the potential security **impact** of a > malicious server setting a high value isn't discussed. OK. Added: ...which may cause an undue delay in a client completing its DHCPv6 protocol transaction in the case no other valid response is received. > 6) On a related note to #5, are there operational considerations if a DHC= Pv6 > server choose to set an arbitrarily high value? Could there be economic > benefit for a server to do this, leading some requesters to use a differe= nt > server either for load-balancing or servicing only priority customers? Wh= at > impact could such behavior create in a network that an operator should > consider? I can't think of any other impacts. If you feel strongly about the issue, = we can poll the dhc WG for their thoughts. > 7) In IANA considerations, you define OPTION_SOL_MAX_RT and > OPTION_INF_MAX_RT, but discussion of sending these options in sections 7 = and > 8 don't mention these codes; they refer only to SOL_MAX_RT and SOL_MAX_RT= . I > don't know much about registering DHCP options; is this correct? Section 7 uses the phrases "SOL_MAX_RT option code" and "INF_MAX_RT option = code, which would be considered equivalent to OPTION_SOL_MAX_RT and OPTON_I= NF_MAX_RT. Section 8 uses the phrases "SOL_MAX_RT option" and "INF_MAX_RT = option" to refer to the options themselves, not just the option codes. I t= hink the text is correct in all cases. - Ralph >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 >=20 From warren@kumari.net Fri Sep 13 15:53:10 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA00611E8218; Fri, 13 Sep 2013 15:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.675 X-Spam-Level: X-Spam-Status: No, score=-101.675 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TXyR-fMO8zz; Fri, 13 Sep 2013 15:53:05 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id E338411E821D; Fri, 13 Sep 2013 15:53:04 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.103]) by vimes.kumari.net (Postfix) with ESMTPSA id 94F301B4008B; Fri, 13 Sep 2013 18:53:03 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Sep 2013 18:53:03 -0400 Message-Id: <0DF61BD9-6007-4684-AB85-328D6538B81B@kumari.net> To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [secdir] Review of: draft-ietf-ccamp-otn-g709-info-model X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 22:53:11 -0000 Be ye not afraid... 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. Summary for Security AD: Nothing to see here, move along... General summary: This document could do with a careful reading for nits and similar. It also use a large number of acronyms that are not defined in it -- = e.g: ODUflex, GFP-F, ODUk.=20 While there may be really well known in some spheres, I have *no* idea = what they mean. Please explain / expand them, or (probably much easier) simply say: = "Familiarity with GMPLS and is expected, especially = [References]". The Security Considerations section contains: "New types of information to be conveyed regard OTN containers and = hierarchies and from a security standpoint this memo does not introduce = further risks with respect to the information that can be currently = conveyed via GMPLS protocols." I had a really hard time parsing this sentence -- I agree that this = does't seem to introduce any new security issues, but the sentence seems = to missing some words. Or something. Some nits: draft-ietf-ccamp-gmpls-ospf-g709v3-07 is now = draft-ietf-ccamp-gmpls-ospf-g709v3-08 =20 draft-ietf-ccamp-gmpls-signaling-g709v3-11 is now = draft-ietf-ccamp-gmpls-signaling-g709v3-12 Section 1: O: extensions need to support [G.709-2012] is provided in [OTN-FWK]. P: extensions needed to support [G.709-2012] is provided in [OTN-FWK]. C: s/need/needed/ Section 2. G.709 Mapping and Multiplexing Capabilities O: The digital OTN layered structure is comprised of digital path layer (ODU) and digital section layer (OTU) P: The digital OTN layered structure is comprised of the digital path = layer (ODU) and the digital section layer (OTU) O: needs to be advertised and signaled, what is already there in GMPLS = and what is missing. P: needs to be advertised and signaled, what already exists GMPLS and = what is missing. 3. Tributary Slot Granularity O: ITU-T recommendation defines two types of Tributary Slot (TS) C: Which ITU-T recommendation? Reference. O: - If both ends of a link are new cards supporting both 1.25Gbps TS and 2.5Gbps TS, then the link will work with 1.25Gbps TS. C: Throughout this section you reference "new" and "old" cards. I think = you need better names or simply removed the words "new" and "old". I = could presumably go to my vendor and buy a card that only supports = 2.5Gbps tomorrow and that would be "new" for me. 3.2. Control Plane considerations O: In case they cannot, A will compute an alternate path from itself to = Z (see figure 4). P: If not, A will compute an alternate path from itself to Z (see figure = 4). or P: If they cannot, A will compute an alternate path from itself to Z = (see figure 4). or P: In the case that they cannot, A will compute an alternate path from = itself to Z (see figure 4). O: Moreover, also TS granularity information needs to be signaled. P: Moreover, TS granularity information also needs to be signaled. O: the signaling to permit node C (see figure 5) choose the right one P: the signaling to permit node C (see figure 5) to choose the right one O: towards D. In case the full ERO is provided in the signaling with P: towards D. In the case that the full ERO is provided in the signaling = with or P: towards D. In cases where the full ERO is provided in the signaling = with=20 (I stopped here)=20 W -- I once absend-mindedly ordered Three Mile Island dressing in a = restaurant and, with great presence of mind, they brought Thousand = Island Dressing and a bottle of chili sauce. -- Terry Pratchett From d3e3e3@gmail.com Fri Sep 13 22:06:15 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA2711E80E8; Fri, 13 Sep 2013 22:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3G44pvOVyVY7; Fri, 13 Sep 2013 22:06:15 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7D46411E80E0; Fri, 13 Sep 2013 22:06:14 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lj1so3337315pab.15 for ; Fri, 13 Sep 2013 22:06:14 -0700 (PDT) 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=1fGFvAiCKyxqfGNJLZGMEKTk/bYfRkaQdIyHCCmdzHw=; b=KswIloL63gNhnd3vuXdcHycnN/Vjz7zGLfRzg282jWadOgum7AmIKwMI31VepZnBAx ZoQrWrnEMUe0z/7XLh3rXBC9cISvVTSO6zP4MuKiAhw2M0aLkBOAnqTpfDMiawdNhVAV qNSLbLCSigSEGMMvDePrSkvfzHH1u4LcITwcHKgxThjmFFSbfFnLpN4li2vx3+2y224p 04YIRKlzBVb3prYXeOtfaXNCVF5leWnujek6fGdudZv41gdKWiNUhKmIdxzmcaCY7CiF 2R2yO/VpgUa0YVdcPIGcYtcTcbXYn/U9/UuhLvCNABRwyMZ3ohlRvp26oJncFnS+g7og kTdQ== X-Received: by 10.68.196.234 with SMTP id ip10mr17301002pbc.18.1379135174072; Fri, 13 Sep 2013 22:06:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.91.143 with HTTP; Fri, 13 Sep 2013 22:05:54 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> From: Donald Eastlake Date: Sat, 14 Sep 2013 01:05:54 -0400 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "secdir@ietf.org" , S Moonesamy , "spfbis@ietf.org" , The IESG , draft-ietf-spfbis-4408bis.all@tools.ietf.org Subject: Re: [secdir] [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 05:06:15 -0000 On Wed, Sep 11, 2013 at 12:35 PM, Murray S. Kucherawy wrote: > On Wed, Sep 11, 2013 at 7:33 AM, Phillip Hallam-Baker > wrote: >> >> On Wed, Sep 11, 2013 at 9:43 AM, Murray S. Kucherawy >> wrote: >>> >>> On Wed, Sep 11, 2013 at 6:22 AM, S Moonesamy >>> wrote: >>>> >>>> I am responding to the comment about DKIM only and wait for the SPFBIS >>>> WG to address the other issues. >>> >>> >>> Was the SecDir review for this draft posted to the spfbis list? I >>> haven't seen it. >> >> >> The draft-ietf-spfbis-4408bis.all@tools.ietf.org doesn't cover it? I >> thought that was the point. > > > I'm pretty sure it's authors, shepherds, and co-chairs only, not the whole > WG. It also includes the sponsoring AD. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From new-work-bounces@ietf.org Fri Sep 13 09:37:09 2013 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 A02FC21E8131; Fri, 13 Sep 2013 09:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1379090229; bh=FSfYIKQunjEp4DlUt2rHAvfT+LtNiMr/9Mk9vPClog8=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=NexH1HgKO23JyzwMd1RueJSbzu5uA90iVNflpDvT4gAkUAIt2iYrpnUiUnwLg3KU4 qSNIUxPzQKBZF8f8frTgCUEJDO4Infeeokg/k8zeJ1+DESbtjbHjN9oApOn/5e3Tim dDGRLYLmwZMxJd900reWw1IB3C5UuoQZahHdfAO4= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874EB21E8131; Fri, 13 Sep 2013 09:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1SM0Cfnjr3N; Fri, 13 Sep 2013 09:37:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D706E21E812E; Fri, 13 Sep 2013 09:37:05 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130913163705.16689.48853.idtracker@ietfa.amsl.com> Date: Fri, 13 Sep 2013 09:37:05 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Sat, 14 Sep 2013 16:58:17 -0700 Subject: [secdir] [new-work] WG Review: DTLS In Constrained Environments (dice) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:37:09 -0000 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-09-23. DTLS In Constrained Environments (dice) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Stephen Farrell Mailing list Address: dtls-iot@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dtls-iot Archive: http://www.ietf.org/mail-archive/web/dtls-iot/ Charter: The Constrained Application Protocol (CoAP) can be used to manipulate resources on a device in constrained environments secured by Datagram Transport Layer Security (DTLS, RFC 6347). The DTLS In Constrained Environments (DICE) working group focuses on supporting the use of DTLS Transport-Layer Security in these environments. The first task of the working group is to define a DTLS profile that is suitable for Internet of Things applications and is reasonably implementable on many constrained devices. The second task of the working group is to define how DTLS record layer can be used to transmit multicast messages securely. Security for these multicast messages is needed in many Internet of Things environments, as some messages are commonly multicast among a set of receivers. Session keys are needed in order to use the DTLS record layer in this way. Changes to the DTLS handshake to support this may be needed in future but are not part of the initial charter for DICE wg. The third task of the working group is to investigate practical issues around the DTLS handshake in constrained environments. Many current systems end up fragmenting messages, and the re-transmission and re-ordering of handshake messages results in significant complexity and reliability problems. Additional reliability mechanisms for transporting DTLS handshake messages are required as they will ensure that handling of re-ordered messages needs to be done only once in a single place in the stack. The DICE working group may also look at alternative TLS transports in cooperation with the TLS WG. The DTLS state machine should not be modified and key management (including for multicast security) and multi-cast session setup are out the scope for the initial work. The DICE working group will work closely with the TLS, CoRE and LWIG working groups. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Fri Sep 13 09:45:46 2013 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 68C1921E812F; Fri, 13 Sep 2013 09:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1379090746; bh=nR1oy59RmTR41VbfXM093t/BgkYUYwvCaVICS5Y9mL4=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=OazjTdbQGiU6bglOr5f5h524o8yBfHs6/ri9Ah47fTOsD3mYXupNq+JU6qf8kdfpr gR4mnYtfv8QdrUM/6zkVoSep1AnEW6KRxZyewEHgFAhRjEq4ypXL2RT9hPncXV2hkp F7x95V6gQCUr02F1xSMzDoqWTmAwyFX6xxSgdt+A= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F6921E80AA; Fri, 13 Sep 2013 09:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZjZWK-qvmUK; Fri, 13 Sep 2013 09:45:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F4C21E80CA; Fri, 13 Sep 2013 09:45:30 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130913164530.24472.35328.idtracker@ietfa.amsl.com> Date: Fri, 13 Sep 2013 09:45:30 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Sat, 14 Sep 2013 16:58:18 -0700 Subject: [secdir] [new-work] WG Review: Active Queue Management and Packet Scheduling (aqm) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:45:46 -0000 A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-09-23. Active Queue Management and Packet Scheduling (aqm) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Martin Stiemerling Mailing list Address: aqm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/aqm Archive: http://www.ietf.org/mail-archive/web/aqm/current/maillist.html Charter: Internet routers, lower-layer switches, end-host operating systems, device drivers, and many types of additional middleboxes include memory buffers in which they implement queues to hold packets that require processing or otherwise need to wait for forwarding to the next hop. The queues are intended to absorb bursts of traffic that may naturally occur, and avoid unneccessary losses. However, queues also cause latency and jitter in the eventual arrival times of packets. This can create issues and complications for interactive applications. Extremely large unmanaged buffers have been noticed in some software and equipment. When these buffers fill, interactive applications and other traffic can be severely impacted or completely broken, due to high and potentially oscillating delays. The Active Queue Management and Packet Scheduling working group (AQM) works on algorithms for managing queues in order to: (1) minimize standing queues, helping to reduce delay for interactive applications (2) help flow sources control their sending rates without unnecessary losses, e.g. through ECN (3) consider the merits of various techniques to protect flows from negative impacts of other more aggressive or misbehaving flows (4) help avoid global synchronization of flows sharing a bottleneck The AQM working group will produce documents that cover the design, use, configuration, and monitoring of algorithms for managing queues in Internet devices and software. The scope includes both how to best configure existing equipment and software, as well as recommendations on designing new equipment and software. The AQM working group will also publish algorithm specifications that are found to be broadly applicable and beneficial. Evaluating these algorithms shall be done in coordination with the Internet Congestion Control Research Ground (ICCRG), and related IETF Working Groups, such as the RTP Media Congestion Avoidance Techniques Working Group (RMCAT), in order to select and assess the relevant criteria, scenarios, and metrics. The working group will also explore the merits of whether to isolate flows, and mechanisms for performing this function. Note that isolation and potentially policing of flows implies some policy beyond what is required to simply minimize queues. This topic requires significant attention in the working group. AQM algorithms do not have to be implemented universally in order to be effective. Specifications will aid in producing proper implementations that avoid potential ambiguities and corner cases. "Interoperability" of algorithms and implementations of them is not the reason for creating these specifications; correctness is the primary motivation. The working group will not make changes to existing IETF protocols, but the working group may use ECN, Diffserv, and other mechanisms maintained by the TSVWG working group. Since the implementation of these mechanisms is likely to be entwined with AQM algorithms, there is expected to be close coordination between the TSVWG and AQM groups. Many AQM algorithms have been proposed in academic literature, but a smaller number are widely implemented and deployed. The goal of the working group is to produce recommendations that will actually be used, and algorithms that will actually be implemented, deployed in equipment, and enabled. Towards these ends, the group actively encourages participation from operators and implementers. Furthermore, the group will jointly work with the Routing and Internet Area in order to involve vendors of networking equipment in the development of the AQM mechanisms. Wider research and evaluation of AQM mechanisms shall be coordinated with the IRTF/ICCRG, and significant participation in this WG from the academic and research community is highly desirable, when it is directly relevant to implementation and deployment. Combined Queue Management / Packet Scheduling algorithms are in-scope, provided their benefit have been evaluated against the established requirements for an AQM algorithm. It is expected that some classes of algorithms will focus on software implementations, while others on existing or new hardware deployments, and algorithms may be specific to distinct scenarios. Milestones: Jan 2014 - Submit AQM recommendations to IESG for publication, obsoleting RFC 2309 Jul 2014 - Submit AQM algorithm evaluation guidelines to IESG for publication as Informational Dec 2014 - Submit first algorithm specification to IESG for publication as Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Fri Sep 13 09:53:05 2013 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 8E0D221F9D92; Fri, 13 Sep 2013 09:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1379091185; bh=aGu+TXje6S5sEy5bpwPeRZ4JaXbmjifpjrHC5l1a/LA=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=is/uO8gNvEuEuuU+sqm88c7FaoSVkp5fEZQM7euXVPuxjqyJb9H7KuTw/A5P0kZUZ uzJVao90H/sB5A6sq5rqAMwtAEXMLwH3vYWv4lVlcTB7t8y/V1wd4q729pu4UieCk8 hEzsGS5TJ0ggvHjuvWHj2JJFFihJr+OazReW0W44= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D3521F9D92; Fri, 13 Sep 2013 09:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.43 X-Spam-Level: X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Emg1jLXf7S8F; Fri, 13 Sep 2013 09:53:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A39E411E812F; Fri, 13 Sep 2013 09:53:00 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130913165300.19659.25396.idtracker@ietfa.amsl.com> Date: Fri, 13 Sep 2013 09:53:00 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Sat, 14 Sep 2013 16:58:18 -0700 Subject: [secdir] [new-work] WG Review: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:53:05 -0000 A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-09-23. IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) ------------------------------------------------ Current Status: Proposed WG Chairs: Pascal Thubert Thomas Watteyne Assigned Area Director: Ted Lemon Charter: 6TiSCH: "IPv6 over the TSCH mode of IEEE 802.15.4e". Background/Introduction: ------------------------ Low-power and Lossy Networks (LLNs) interconnect a possibly large number of resource-constrained nodes to form a wireless mesh network. The 6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols at various layers of the protocol stack, including an IPv6 adaptation layer, a routing protocol and a web transfer protocol. This protocol stack has been used with IEEE802.15.4 low-power radios. The IEEE802.15.4e Timeslotted Channel Hopping (TSCH) is a recent amendment to the Medium Access Control (MAC) portion of the IEEE802.15.4 standard. TSCH is the emerging standard for industrial automation and process control LLNs, with a direct inheritance from WirelessHART and ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable the further adoption of IPv6 in industrial standards and the convergence of Operational Technology (OT) with Information Technology (IT). The nodes in a IEEE802.15.4e TSCH network communicate by following a Time Division Multiple Access (TDMA) schedule. A timeslot in this schedule provides a unit of bandwidth that is allocated for communication between neighbor nodes. The allocation can be programmed such that the predictable transmission pattern matches the traffic. This avoids idle listening, and extends battery lifetime for constrained nodes. Channel-hopping improves reliability in the presence of narrow-band interference and multi-path fading. These techniques enable a new range of use cases for LLNs, including: - Control loops in a wireless process control network, in which high reliability and a fully deterministic behavior are required. - Service Provider networks transporting data from different independent clients, and for which an operator needs flow isolation and traffic shaping. - Networks comprising energy harvesting nodes, which require an extremely low and predictable average power consumption. IEEE802.15.4e only defines the link-layer mechanisms. It does not define how the network communication schedule is built and matched to the traffic requirements of the network. Description of Working Group: ----------------------------- The Working Group will focus on enabling IPv6 over the TSCH mode of the IEEE802.15.4e standard. The extent of the problem space for the WG is one or more LLNs, eventually federated through a common backbone link via one or more LLN Border Routers (LBRs). Initially, the WG will limit its scope to distributed routing over a static schedule. In that case, a node's schedule can be either preconfigured, or learnt by a node when joining the network, but it remains unchanged after the node has joined a network. The Routing Protocol for LLNs (RPL) is used on the resulting network. The WG will interface with other appropriate groups in the IETF Internet, Operations and Management, Routing and Security areas. Work Items: ----------- The group will: 1. Produce "6TiSCH architecture" to describe the design of 6TiSCH networks. This document will highlight the different architectural blocks and signalling flows, including the operation of the network in the presence of multiple LBRs. Initially, the document will focus on distributed routing operation over a static TSCH schedule. 2. Produce an Information Model containing the management requirements of a 6TiSCH node. This includes describing how an entity can manage the TSCH schedule on a 6TiSCH node, and query timeslot information from that node. A data model mapping for an existing protocol (such as Concise Binary Object Representation (CBOR) over the Constrained Application Protocol (CoAP)) will be provided. 3. Produce "Minimal 6TiSCH Configuration" defining how to build a 6TiSCH network using the Routing Protocol for LLNs (RPL) and a static TSCH schedule. It is expected that RPL and the Objective Function 0 (OF0) will be reused as-is. The work will include a best practice configuration for RPL and OF0 operation over the static schedule. Based on that experience the group may produce a requirements draft for OF0 extensions, to be studied in ROLL. Non-milestone work items: ------------------------- The Working Group may maintain a number of running, often-respun documents, that evolve as the technology is refined for work items that do not affect the milestone work items: - implementers guide: this document will collect clarifying information based on input from implementers, in particular as it becomes available from interoperability events. This guide will contain information about test harnesses used for interoperability testing. - coexistence guide: this document will provide information on how 6TiSCH can be operated in an environment shared with other protocols that use the same or a similar TSCH MAC, and/or operate on the same frequency band. The WG will welcome requirements for dynamic timeslot operation, for example for centralized schedule computation. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From worley@shell01.TheWorld.com Mon Sep 16 14:38:09 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B8211E81CF for ; Mon, 16 Sep 2013 14:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsgbYpockMF9 for ; Mon, 16 Sep 2013 14:38:03 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id D09B211E8113 for ; Mon, 16 Sep 2013 14:38:02 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r8GLb99j016883; Mon, 16 Sep 2013 17:37:11 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r8GLb8XV1255150; Mon, 16 Sep 2013 17:37:08 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r8GLb3Tl1255783; Mon, 16 Sep 2013 17:37:03 -0400 (EDT) Date: Mon, 16 Sep 2013 17:37:03 -0400 (EDT) Message-Id: <201309162137.r8GLb3Tl1255783@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Stephen Kent In-reply-to: <52163380.5070005@bbn.com> (kent@bbn.com) References: <52163380.5070005@bbn.com> X-Mailman-Approved-At: Mon, 16 Sep 2013 14:53:16 -0700 Cc: mary.ietf.barnes@gmail.com, gonzalo.camarillo@ericsson.com, fluffy@iii.ca, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-worley-service-example-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 21:38:09 -0000 This is a report on changes to draft-worley-service-example (to produce draft-worley-service-example-14) in response to the SECDIR review by Stephen Kent. > Date: Thu, 22 Aug 2013 11:51:28 -0400 > From: Stephen Kent > This document describes how to provide music on old (MOH) in a VoIp > environment, an obviously critical capability needed to preserve feature > compatibility with the PSTN. Callers who are not subjected to MOH might > otherwise not be exposed to classical music, in many contexts, a tragic > outcome. Unfortunately, the real market driver for MOH is businesses that want to play ads to you while you are waiting on hold to talk to a human. Creating a facility to allow these businesses to do what they want might be considered as violating the "Do no evil." principle, but it does seem to be critical in the marketplace. > I was surprised to see that all the references to RFCs (normative > and informative) use labels other than RFC numbers. This an unusual > convention that I hope the RFC editor will fix. Personally, I find it a lot more convenient to tag RFCs by their topics than their numbers, as I don't remember the numbers of more than a handful of RFCs. Nonetheless, using RFC numbers as tags is the convention these days, and I've updated the draft to do the same. > It is hard to overstate the importance of appropriate security > mechanisms for this critical aspect of VoIP. Consistent with this > observation, the Security Considerations section of this document > consists of just one paragraph. The paragraph addresses one security > concern, i.e., the ability of the UA of a caller to filter incoming > media based on the address of the source of the media. The design in > this document provides the source address of the MOH server, via SDP (in > a re-INVITE), to the caller who is on hold, and thus satisfies this concern. > > In a more serious vein, I'd like to see the Security Considerations > section mention whether UAs are expected to use SDP and SIP security > mechanisms for MOH, IF these mechanisms were employed for the original > call. Another paragraph could be added to discuss the desirability of > maintaining an equivalent level of security when a caller is switched > over to MOH, and to cite the relevant RFCs, or to explain why this is > not appropriate. I've expanded the draft in this regard. The new text is: 5. Security Considerations 5.1. SIP (signaling) security The executing UA and the MOH server will usually be within the same administrative domain and the SIP signaling path between them will lie entirely within that domain. In this case, the administrator of the domain should configure the UA and server to apply to to the dialog between them a level of security that is appropriate for the administrative domain. If the executing UA and the MOH server are not within the same administrative domain, the SIP signaling between them should be at least as secure as the SIP signaling between the executing UA and the remote UA. Thus, the MOH server should support all of the SIP security facilities that are supported by the executing UA, and the executing UA should use in its dialog with the MOH server all SIP security facilities that are used in its dialog with the remote UA. 5.2. RTP (media) security The RTP for the MOH media will pass directly between the MOH server and the remote UA, and thus may pass outside the administrative domain of the executing UA. While it is uncommon for the contents of the MOH media to be sensitive (and the remote UA will not usually be generating RTP when it is on-hold), the MOH RTP should be at least as secure as the RTP between the executing UA and the remote UA. In order to make this possible, the MOH server should support all of the RTP security facilities that are supported by the executing UA. It is possible that the remote UA and the MOH server support an RTP security facility that the executing UA does not support, and that it is desirable to use this facility for the MOH RTP. To enable this, the executing UA should the SDP between the remote UA and the MOH server completely, not omitting elements that it does not understand. 5.3. Media filtering Some UAs filter incoming RTP based on the address of origin as a media security measure. The remote UA in the original dialog may use this media filtering, and if the executing UA does not update the SDP to inform the remote UA of the source address of the MOH media, the remote UA may not render the MOH media. Note that the executing UA has no means for detecting that the remote UA uses media filtering, so the executing UA must assume that any remote UA uses media filtering. The technique described in this document ensures that any UA that should render MOH media will be informed of the source address of the media via the SDP that it receives. This allows such UAs to filter media without interfering with MOH operation. Dale From kathleen.moriarty@emc.com Mon Sep 16 17:19:28 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A58B11E8168 for ; Mon, 16 Sep 2013 17:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GjcOGbuVRuo for ; Mon, 16 Sep 2013 17:19:23 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2797611E8160 for ; Mon, 16 Sep 2013 17:19:22 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r8H0JMJH026311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Sep 2013 20:19:22 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com r8H0JMJH026311 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1379377162; bh=sfvt+tX2ii33x97+nl2aPwFrTrg=; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; b=Jj0PJBs7z3hnx9hbrvMyoSh0U/uL03/CbFsb2rlpyLLYBAD8dQ4Wc2aEF6U7aH6sw k0148/sNZfDL5ARYoNUJrU/wDG3VyphcWd0jmh3x/6IaoEW+3gwk3c78QDjwv7vJ0m W7mDSUFzUOeE0kZ69s/snR5PkV4Ml0mPe0CpzMF8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com r8H0JMJH026311 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd03.lss.emc.com (RSA Interceptor) for ; Mon, 16 Sep 2013 20:19:08 -0400 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r8H0J8QO005784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 16 Sep 2013 20:19:08 -0400 Received: from mxhub39.corp.emc.com (128.222.70.106) by mxhub20.corp.emc.com (10.254.93.49) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 16 Sep 2013 20:19:08 -0400 Received: from mx15a.corp.emc.com ([169.254.1.46]) by mxhub39.corp.emc.com ([128.222.70.106]) with mapi; Mon, 16 Sep 2013 20:19:07 -0400 From: "Moriarty, Kathleen" To: "secdir@ietf.org" Date: Mon, 16 Sep 2013 20:19:06 -0400 Thread-Topic: Sec-dri review of draft-resnick-retire-std1-01 Thread-Index: Ac6zO4VglRe1enu/S9u2qk4x1UGacw== Message-ID: 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_F5063677821E3B4F81ACFB7905573F24049E642B01MX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-EMM-GWVC: 1 X-RSA-Classifications: DLM_1, public X-EMM-McAfeeVC: 1 Subject: Re: [secdir] Sec-dri review of draft-resnick-retire-std1-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 00:19:28 -0000 --_000_F5063677821E3B4F81ACFB7905573F24049E642B01MX15Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Moriarty, Kathleen Sent: Monday, September 16, 2013 8:14 PM To: 'sec-dir@ietf.org'; '2013-10-01'; 'iesg@ietf.org' Cc: 'presnick@qti.qualcomm.com' Subject: Sec-dri review of 2013-10-01 draft-resnick-retire-std1-01 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. 2013-10-01 draft-resnick-retire-std1-01 is ready for publication. There ar= e no outstanding security considerations. Thank you, Kathleen --_000_F5063677821E3B4F81ACFB7905573F24049E642B01MX15Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Moriarty, Kathleen
Sent: Monday, September 16, 2013 8= :14 PM
To: 'sec-dir@ietf.org'; '2013-10-01'; 'iesg@ietf.org'
<= b>Cc: 'presnick@qti.qualcomm.com'
Subject: Sec-dri review of = 2013-10-01 draft-resnick-retire-std1-01

 

I have reviewe= d 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 trea= t

these comments just like any other la= st call comments.

 

<= p class=3DMsoNormal>2013-10-01 draft-resnick-retire-std1-01 is ready for pu= blication.  There are no outstanding security considerations.

 

Thank = you,

Kathleen

= --_000_F5063677821E3B4F81ACFB7905573F24049E642B01MX15Acorpemcc_-- From sm@elandsys.com Tue Sep 17 01:21:51 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C222411E83A5; Tue, 17 Sep 2013 01:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nubGhtYEGKDO; Tue, 17 Sep 2013 01:21:51 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 016B011E83A4; Tue, 17 Sep 2013 01:21:50 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.146.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8H8LRBK006285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Sep 2013 01:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379406101; bh=zq64VaMlu23G0SBrguiNJfHihcBMLsDmh2linByo9yo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=AzydwO0Zfc4tMf+cTmsdTD+UVflUllImPxZIyrIvrFAfhVhsmYd1MLBMA+8VwyLwY CaGJvkgS59WXRFO07pqVsOWeR9g3IlHly9GxDFFf3weFlCXkWUM+OV1n0rCu38piRj eYSR2vY5klaqi3lWqjHSqaUINwNTu44uktbCyPQM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379406101; i=@elandsys.com; bh=zq64VaMlu23G0SBrguiNJfHihcBMLsDmh2linByo9yo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=S7n9YJtgxv29q0ILom4JYHJ72ggg3hBOPZgQp0tL9QXSwexIXa7Et3w1iVuOiTedz NrG+rPg0JvAy7MRVAjPgk58CB367yGOOS0uiknTeWZjED8vIVZykXnSdUYZZJozLss rRvxzIfYAR05uvT/KEXsWIWuXjNn2oJXjYCV6Mzs= Message-Id: <6.2.5.6.2.20130917010720.06302bf8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 17 Sep 2013 01:19:44 -0700 To: Phillip Hallam-Baker , draft-ietf-spfbis-4408bis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [secdir] SECDIR Review of draft-ietf-spfbis-4408bis-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 08:21:52 -0000 Hi Phillip, At 05:07 11-09-2013, Phillip Hallam-Baker wrote: >Minor issues. > >1.1.3. MAIL FROM Definition > >I found this section completely opaque and very confusing. It should >not be necessary to hunt through other specs to find a definition. >Particularly since the referenced specs do not give an explicit >definition for the term as used and the references point to the >whole spec rather than a particular section. The text below is to address the comment about Section 1.1.3 (credits to Rolf E. Sonneveld): 1.1.3. MAIL FROM Definition This document uses "MAIL FROM" to refer to RFC5321.MailFrom (reverse-path). The RFC5321.MailFrom is defined in Section 4.4 of RFC 5598 as an end-to-end string that specifies an email address for receiving return control information, such as returned messages. >The Security Considerations section is adequate for the purpose >except that no mention is made anywhere in the specification about >DKIM and how a mail receiver should interpret presence of DKIM and >SPF policy at the same time. This is a legitimate concern since DKIM >is already a standards track proposal and SPF is only now being >promoted to Standards Track. Thus the SPF document should address >the question of dual use. I commented about the above in my previous reply. >8.7. Permerror >"This signals an error condition that definitely requires operator >intervention to be resolved." > >I cannot imagine a circumstance which definitely requires a human to >be involved in mail delivery. These are permanent DNS errors or SPF record errors. For example, if an SPF record requires too many DNS lookups, someone has to change the record to make the error go away. The definitely was intended to distinguish from cases such as a DNS SERVFAIL that may or may not be permanent, but are temperrors in SPF. In the case of ambiguity about if an error is temporary or permanent, it's treated in the design as assumed to be temporary. >11.2. SPF-Authorized Email May Contain Other False Identities > > Do not construe the "MAIL FROM" and "HELO" identity authorizations to > provide more assurance than they do. > >Document has quasi normative language that should be worded as >statements of fact rather than as direction. The following change is proposed is response to the above: The "MAIL FROM" and "HELO" identity authorizations do not provide assurance about the authorization/authenticity of other identities used in the message. Regards, S. Moonesamy (as document shepherd) From radiaperlman@gmail.com Tue Sep 17 23:20:45 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C86611E8129; Tue, 17 Sep 2013 23:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVpX1y5Cm4x6; Tue, 17 Sep 2013 23:20:44 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DEB0011E8125; Tue, 17 Sep 2013 23:20:43 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id o14so6177526lbi.4 for ; Tue, 17 Sep 2013 23:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=35Jl2gO0do3e2NpIozUwz+yZqGGHn9ZQs8QVtOb34Iw=; b=0KecTctL7JVyjYWJJ/1lm8UV/G1wWYYdUlZKfTU0AXCQPUIGzY0n4c1HsdkScuwBZ4 Hy+S29bEQtXL+U8tnhb1vNdMotftt4/MouYRqJ/q6nxArtnbxeT+SbxZRUpoCEYUGmVU YeGptFRGOsRqDymU0SEusQAHwyJWY9VoAx8DayDEzmyQGKzY/tNwaSHdN868n35hr3PM u4w0XLBpVQ7ivPKlsX986Y6bui3I1mNw4iUL9oq+MF6qVV9l8r8Hoyms6WFyPM+do6UE 5ayrmcQBNrCLdvFXtAg5g+J9VGTqsgfiN28pvQjbvS4Mnic2HNN8qW9PmmvknXPCgV/Z S+PA== MIME-Version: 1.0 X-Received: by 10.112.167.3 with SMTP id zk3mr14221497lbb.23.1379485241594; Tue, 17 Sep 2013 23:20:41 -0700 (PDT) Received: by 10.112.188.197 with HTTP; Tue, 17 Sep 2013 23:20:41 -0700 (PDT) Date: Tue, 17 Sep 2013 23:20:41 -0700 Message-ID: From: Radia Perlman To: The IESG , "secdir@ietf.org" , draft-ietf-mmusic-delayed-duplication.all@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c264a4cc576404e6a26fc0 Subject: [secdir] secdir review of draft-ietf-mmusic-delayed-duplication X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 06:20:45 -0000 --001a11c264a4cc576404e6a26fc0 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is about allowing a sender of a multicast stream to advertise that it will be sending duplicate streams offset in time, so that receivers can receive multiple copies...so that if packets are lost they will hopefully receive it from the later stream(s). >From a security point of view, there's no reason to complain. However, I'm really dubious about what this will be used for, and whether this is the best way to solve the problem. How does one cope with loss? For instance... a) request retransmissions of specific missing pieces, perhaps not from the original source, but from a redistribution point (e.g., zillions of scalable reliable multicast protocols that were talked about/published years ago) b) send forward error correction so that the data can be reconstructed (e.g., Digital Fountain) c) cope with glitches on your video when in rare cases, e.g., network topology changes, some data gets lost I'm not sure multicast is used so much anyway. What are the applications today? It seems like most video is individual on-demand rather than multicast. And if there were some sort of multicast thing (like a sporting event), it seems like any combination of a), b), and c) above would be preferable to multicasting everything multiple times. A specific comment: In the security considerations section it says "the SDP description needs to be integrity protected..." Is this MUST be? SHOULD be? Radia --001a11c264a4cc576404e6a26fc0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's o= ngoing effort to review all IETF documents being processed by the IESG. =A0= These comments were written primarily for the benefit of the security area = directors. =A0Document editors and WG chairs should treat these comments ju= st like any other last call comments.

Thi= s document is about allowing a sender of a multicast stream to advertise th= at it will be sending duplicate streams offset in time, so that receivers c= an receive multiple copies...so that if packets are lost they will hopefull= y receive it from the later stream(s).

Fro= m a security point of view, there's no reason to complain. =A0However, = I'm really dubious about what this will be used for, and whether this i= s the best way to solve the problem. =A0How does one cope with loss? =A0For= instance...
a) request= retransmissions of specific missing pieces, perhaps not from the original = source, but from a redistribution point (e.g., zillions of scalable reliabl= e multicast protocols that were talked about/published years ago)
b) send fo= rward error correction so that the data can be reconstructed (e.g., Digital= Fountain)
c) cope with glitches on your video when in rare cases, e.g., = network topology changes, some data gets lost

I&#= 39;m not sure multicast is used so much anyway. =A0What are the application= s today? =A0It seems like most video is individual on-demand rather than mu= lticast. =A0And if there were some sort of multicast thing (like a sporting= event), it seems like any combination of a), b), and c) above would be pre= ferable to multicasting everything multiple times.

A s= pecific comment: =A0In the security considerations section it says "th= e SDP description needs to be integrity protected..." =A0Is this MUST = be? =A0SHOULD be?

Rad= ia
--001a11c264a4cc576404e6a26fc0-- From abegen@cisco.com Wed Sep 18 03:34:49 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B10611E80F8; Wed, 18 Sep 2013 03:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.099 X-Spam-Level: X-Spam-Status: No, score=-11.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rq5r1ah74afw; Wed, 18 Sep 2013 03:34:43 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4636A11E80E8; Wed, 18 Sep 2013 03:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2972; q=dns/txt; s=iport; t=1379500483; x=1380710083; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=P0yYq5mF7icR4l48VkF1l6FEqGHfRbQFs5zUivMEknc=; b=gOxPCJ8QxUoGjGXHm3FmX4qn1pHXOHqFvpcXvSwu4JPLUHkfKZKWE7ZC 14toFqWiEklRK3dbVIgYD4P+gQH106V0aRZzgjFkk9blWIqJZcKg5cukF 0vcMIwg5EPh4gT7EYVQ5/bMmrtE8sTdI/LFcCHTj0STUlrWCYV7S7dUla M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAGmBOVKtJV2a/2dsb2JhbABZgmYhgQrBKoEYFnSCJQEBAQMBeQULAgEIIiQhESUCBA4FCIdpAwkGAbBMDYkhjHuCOQIxB4MegQADiQCNEo4qhTODJIIq X-IronPort-AV: E=Sophos;i="4.90,929,1371081600"; d="scan'208";a="261388576" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 18 Sep 2013 10:34:42 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8IAYglw016588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Sep 2013 10:34:42 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 18 Sep 2013 05:34:42 -0500 From: "Ali C. Begen (abegen)" To: Radia Perlman Thread-Topic: secdir review of draft-ietf-mmusic-delayed-duplication Thread-Index: AQHOtDdAdN54ISzMl0uphv2lSYtXn5nLoFsA Date: Wed, 18 Sep 2013 10:34:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.222] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <461FF5A38E750849B960351E62C0AA5F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-mmusic-delayed-duplication X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 10:34:49 -0000 Hi Radia, On Sep 18, 2013, at 9:20 AM, Radia Perlman wrote: > I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. These = comments were written primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments just like = any other last call comments. >=20 > This document is about allowing a sender of a multicast stream to adverti= se that it will be sending duplicate streams offset in time, so that receiv= ers can receive multiple copies...so that if packets are lost they will hop= efully receive it from the later stream(s). >=20 > From a security point of view, there's no reason to complain. However, I= 'm really dubious about what this will be used for, and whether this is the= best way to solve the problem. How does one cope with loss? For instance= ... > a) request retransmissions of specific missing pieces, perhaps not from t= he original source, but from a redistribution point (e.g., zillions of scal= able reliable multicast protocols that were talked about/published years ag= o) > b) send forward error correction so that the data can be reconstructed (e= .g., Digital Fountain) > c) cope with glitches on your video when in rare cases, e.g., network top= ology changes, some data gets lost You are right, there are several different ways to deal with packet loss fo= r both multicast and unicast. Retransmission, FEC, error concealment are al= l options. But the main use case for duplication is when there is a network= outage for a period of time (i.e., bursty packet losses) like a route fail= ure, hardware failure, etc. and all the packets transmitted during the outa= ge will likely get lost until the route is repaired (could be 50 ms or 1 s = or longer). Ret, FEC cannot deal with such outages. Concealment is not an o= ption in most critical video apps, either. Duplication is a simple alternat= ive. It has been deployed, it works and it is proven for this use case. >=20 > I'm not sure multicast is used so much anyway. What are the applications= today? It seems like most video is individual on-demand rather than multi= cast. =20 heard IPTV? > And if there were some sort of multicast thing (like a sporting event), i= t seems like any combination of a), b), and c) above would be preferable to= multicasting everything multiple times. We deployed all options you listed above as well as duplication. As I said,= they provide resiliency in different use cases. >=20 > A specific comment: In the security considerations section it says "the = SDP description needs to be integrity protected..." Is this MUST be? SHOU= LD be? I dont think it deserves a 2119 keyword, there. Unless you have a strong ob= jection, I prefer to keep it as it is. many thanks. -acbegen >=20 > Radia From ynir@checkpoint.com Wed Sep 18 04:11:04 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF3B11E80FA; Wed, 18 Sep 2013 04:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.297 X-Spam-Level: X-Spam-Status: No, score=-10.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ck10FwXINddc; Wed, 18 Sep 2013 04:10:58 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E9E1C11E8210; Wed, 18 Sep 2013 04:10:57 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8IBAj7S027133; Wed, 18 Sep 2013 14:10:48 +0300 X-CheckPoint: {52398A35-9-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Wed, 18 Sep 2013 14:10:45 +0300 From: Yoav Nir To: The IESG , "" , "draft-ietf-dime-app-design-guide.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-dime-app-design-guide-19 Thread-Index: AQHOtF+44g/jQShNz0OzyehRUHf+Lg== Date: Wed, 18 Sep 2013 11:10:44 +0000 Message-ID: <6D79E5E4-BE74-4EDC-BAAC-E0A28FB0609E@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.94] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: <4FD2FACA2E5D2E4089B16F1D0819C2A8@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] SecDir review of draft-ietf-dime-app-design-guide-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 11:11:04 -0000 Do not be alarmed. I have reviewed this document as part of the security d= irectorate's ongoing effort to review all IETF documents being processed by= the IESG. These comments were written primarily for the benefit of the se= curity area directors. Document editors and WG chairs should treat these c= omments just like any other last call comments. Summary: The document is ready for publication This informational document provides guidance on extending Diameter applica= tions and on creating new ones. It contains advice such as to re-use existi= ng commands and AVPs, considerations for adding and deleting commands and A= VPs, and accounting. Section 5.11 talks about Diameter security mechanisms: (D)TLS or IPsec. Som= e might dislike that it still mentions IKEv1. I'm not sure why this section= is necessary at all, as these security mechanisms apply to the base protoc= ol rather than any particular extension. There is a 2-page section dealing with registration considerations, but onl= y a very short paragraph for security considerations. That section pretty m= uch says that extensions may be related to security functionality, but the = document does not give guidance on enhancing Diameter with respect to secur= ity. I agree that this is OK, and new security functionality should specify= its own considerations. I do wonder, though, whether it makes sense to inc= lude advice about the content in new data and applications as it relates to= security, specifically as it relates to data leakage or data aggregation o= r user privacy. Nit: Second sentence in the security considerations section: OLD: Although such an extension may related to security functionality, NEW: Although such an extension may be related to security functionality, Yoav= From jouni.nospam@gmail.com Wed Sep 18 06:39:12 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E00C11E82BE; Wed, 18 Sep 2013 06:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D10E-emxBb6N; Wed, 18 Sep 2013 06:39:11 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D142311E8287; Wed, 18 Sep 2013 06:39:09 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id u14so6681624lbd.16 for ; Wed, 18 Sep 2013 06:39:08 -0700 (PDT) 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:cc :content-transfer-encoding:message-id:references:to; bh=4fr5zhZ3sS45YkTbQNA48JODgP0r3IGhcoDz+55KWao=; b=Ro1/g54fl+fLFni6l/vaXiQrz6MncVEn79a1jwTsOIRvXEeDhCUHywOiIq4HKH5D5o ygXUTUlJ62Rg7xPzx+sWZl5rxAdgVeYOhxC/wuwCD2oMw6fqaOGIjsOlJ8yrSGvEnmLE 0YIbNmLv5c07mwLrZr5O2IletivqrElQxU/oyJp773GsIpsIQ1YV5sa9j0u2ADV4/82Y ibHy+V214kZ3/+XavhYO1xb2x+uiObtZqc+st7OZHe4daSUpYzmg/rm/dmBdsakmyx5v NYbmzWV58P71BWxcEucGhvxu2yi1T7QQMTEww6BmIbCBwZuAIlmd0pczHwuPwqn8HPmh sHoQ== X-Received: by 10.152.5.162 with SMTP id t2mr34802810lat.1.1379511548598; Wed, 18 Sep 2013 06:39:08 -0700 (PDT) Received: from [10.37.20.54] ([77.95.242.69]) by mx.google.com with ESMTPSA id vx8sm1576409lbb.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Sep 2013 06:39:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <6D79E5E4-BE74-4EDC-BAAC-E0A28FB0609E@checkpoint.com> Date: Wed, 18 Sep 2013 16:38:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2BC814F7-6863-4CD1-AE08-CEDB7F1F2575@gmail.com> References: <6D79E5E4-BE74-4EDC-BAAC-E0A28FB0609E@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1510) Cc: "draft-ietf-dime-app-design-guide.all@tools.ietf.org" , The IESG , "" Subject: Re: [secdir] SecDir review of draft-ietf-dime-app-design-guide-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 13:39:12 -0000 Thanks Yoav, I'll make sure the authors provide enough reasoning if they intend = keeping IKEv1 in the document. We also try to figure out whether expanding security considerations on = the points you mention would be justified within the context of this = document. - Jouni On Sep 18, 2013, at 2:10 PM, Yoav Nir wrote: > Do not be alarmed. I have reviewed this document as part of the = security directorate's ongoing effort to review all IETF documents being = processed by the IESG. These comments were written primarily for the = benefit of the security area directors. Document editors and WG chairs = should treat these comments just like any other last call comments. >=20 > Summary: The document is ready for publication >=20 > This informational document provides guidance on extending Diameter = applications and on creating new ones. It contains advice such as to = re-use existing commands and AVPs, considerations for adding and = deleting commands and AVPs, and accounting. >=20 > Section 5.11 talks about Diameter security mechanisms: (D)TLS or = IPsec. Some might dislike that it still mentions IKEv1. I'm not sure why = this section is necessary at all, as these security mechanisms apply to = the base protocol rather than any particular extension. >=20 > There is a 2-page section dealing with registration considerations, = but only a very short paragraph for security considerations. That = section pretty much says that extensions may be related to security = functionality, but the document does not give guidance on enhancing = Diameter with respect to security. I agree that this is OK, and new = security functionality should specify its own considerations. I do = wonder, though, whether it makes sense to include advice about the = content in new data and applications as it relates to security, = specifically as it relates to data leakage or data aggregation or user = privacy. >=20 >=20 > Nit: >=20 > Second sentence in the security considerations section: > OLD: > Although such an extension may related to security functionality, > NEW: > Although such an extension may be related to security functionality, >=20 > Yoav From kivinen@iki.fi Thu Sep 19 06:31:58 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE5E21F9477 for ; Thu, 19 Sep 2013 06:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DglxDWkmvnE for ; Thu, 19 Sep 2013 06:31:57 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 77C3B21F949F for ; Thu, 19 Sep 2013 06:31:56 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r8JDVrc7014631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 19 Sep 2013 16:31:53 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r8JDVpYA006983; Thu, 19 Sep 2013 16:31:51 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21050.64711.913399.28548@fireball.kivinen.iki.fi> Date: Thu, 19 Sep 2013 16:31:51 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 4 min X-Total-Time: 4 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2013 13:31:58 -0000 There seems to be some reviews that have been hanging in for there for long time, it would be nice to get those reviews done at some point (Cridland, DeKok, Hutzelman, Laganier, Waltermire, Weiler, Weis, Zorn). Even if the review does not have deadline (i.e. it is early assignment) the reviews should be done in few weeks time. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Dave Cridland is next in the rotation. For telechat 2013-09-26 Reviewer LC end Draft Rob Austein T 2013-08-29 draft-ietf-netext-update-notifications-08 Dan Harkins T 2013-09-02 draft-ietf-ccamp-gmpls-signaling-g709v3-12 David Harrington TR2013-09-03 draft-ietf-dhc-dhcpv6-solmaxrt-update-05 Julien Laganier T 2013-09-17 draft-ietf-ccamp-swcaps-update-03 Ondrej Sury T 2013-08-16 draft-nandakumar-rtcweb-stun-uri-07 Tina TSOU TR2013-08-16 draft-petithuguenin-behave-turn-uris-07 For telechat 2013-10-10 Rob Austein T 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Glen Zorn T 2013-09-27 draft-ietf-sipcore-rfc4244bis-callflows-06 Last calls and special requests: Derek Atkins 2013-10-01 draft-ietf-siprec-architecture-08 Rob Austein 2013-10-16 draft-kolkman-proposed-standards-clarified-03 Dave Cridland - draft-ietf-httpbis-p5-range-23 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-03-30 draft-ietf-roll-terminology-12 Donald Eastlake 2013-10-10 draft-mcgrew-tls-aes-ccm-ecc-07 Jeffrey Hutzelman 2013-07-16 draft-yusef-dispatch-ccmp-indication-04 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-04 Julien Laganier - draft-ietf-avtcore-rtp-security-options-06 Julien Laganier - draft-ietf-websec-key-pinning-08 Ben Laurie 2013-09-23 draft-ietf-idr-rfd-usable-03 Matt Lepinski 2013-09-24 draft-ietf-l2vpn-pbb-vpls-interop-05 Catherine Meadows 2013-09-23 draft-ietf-l2vpn-vpls-mcast-14 Alexey Melnikov - draft-ietf-payload-rtp-howto-05 Kathleen Moriarty 2013-10-01 draft-resnick-retire-std1-01 Sandy Murphy 2013-09-20 draft-ietf-6man-ext-transmit-03 Magnus Nystrom 2013-09-24 draft-ietf-insipid-session-id-reqts-08 Vincent Roca 2013-09-24 draft-ietf-mmusic-duplication-grouping-03 Joe Salowey 2013-09-23 draft-ietf-sidr-bgpsec-threats-06 Yaron Sheffer 2013-09-26 draft-ietf-clue-telepresence-use-cases-07 Ondrej Sury 2013-09-27 draft-ietf-ecrit-psap-callback-10 Tina TSOU 2013-09-27 draft-ietf-ecrit-unauthenticated-access-07 Carl Wallace 2013-09-30 draft-ietf-hip-reload-instance-08 David Waltermire - draft-ietf-repute-considerations-02 David Waltermire 2013-09-30 draft-ietf-intarea-flow-label-balancing-01 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-13 Sam Weiler 2013-09-30 draft-ietf-opsec-ip-options-filtering-05 Brian Weis - draft-ietf-radext-dtls-06 Brian Weis 2013-09-30 draft-ietf-p2psip-drr-10 Klaas Wierenga 2013-09-30 draft-ietf-p2psip-rpr-10 Tom Yu 2013-10-01 draft-ietf-sidr-origin-ops-21 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 -- kivinen@iki.fi From yaronf.ietf@gmail.com Thu Sep 19 10:09:30 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE36421F92C2; Thu, 19 Sep 2013 10:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.639 X-Spam-Level: X-Spam-Status: No, score=-102.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOlUFBqP92kY; Thu, 19 Sep 2013 10:09:30 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 37FB521F9344; Thu, 19 Sep 2013 10:09:27 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id w61so8348493wes.31 for ; Thu, 19 Sep 2013 10:09:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=IOdNDzbpi3IT1V/BAX63RI2UHN1xkrO8HHihudwDGsQ=; b=BLq36U+XKZXbNWXOQ5vU6lJqXrFhcyFvHG14rNjseuQuYv8mdCCuZXbwqU105RToDZ 6hTsLPm/z4MbQT+Kp1BmrLAUqvRMppJCoSitredsTNxKX16DC+MTxM51LocKWk0tPS53 BRZ8W2KLIypwdMWx/VeHJ3gkgP+ZK60Ao0fwDdoGwYIEJWZPd1sST5yL84Fg7t8ErLC9 V6u2ilh96adxZi6HT9SWtIqo+ecjNdkkesesi2fyJJQ9sU8l+uxE2E+iXUQ8rqj+z86F XNbKTUVbaGzLVImxCH9/irAj5d8SEx58ABWMQ4kkzAT7q8OaSHJ8+FMNJj5K7hCbXCWO x5Bw== X-Received: by 10.180.38.36 with SMTP id d4mr12373658wik.7.1379610566372; Thu, 19 Sep 2013 10:09:26 -0700 (PDT) Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id b11sm20356139wik.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Sep 2013 10:09:26 -0700 (PDT) Message-ID: <523B2FC4.4030402@gmail.com> Date: Thu, 19 Sep 2013 20:09:24 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: "secdir@ietf.org" , draft-ietf-clue-telepresence-use-cases.all@tools.ietf.org, The IESG References: <4FBFAE5F.8010305@gmail.com> In-Reply-To: <4FBFAE5F.8010305@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir review of draft-ietf-clue-telepresence-use-cases-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 17:09:31 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document lists use cases of telepresence scenarios (a.k.a. videoconferencing, for those of us are not following). I agree with the authors that such use cases do not need to include security considerations. There is often a fine line between use cases (or "problem statement") and requirements, and IMO requirements should include security issues or security expectations. But this document seems to be squarely on the use cases side of this line, and is fine as-is. Thanks, Yaron From catherine.meadows@nrl.navy.mil Thu Sep 19 11:21:19 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626BB21F90CC; Thu, 19 Sep 2013 11:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcKHQ16DoNCD; Thu, 19 Sep 2013 11:21:14 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFFA21F9123; Thu, 19 Sep 2013 11:21:13 -0700 (PDT) Received: from vpn212036.nrl.navy.mil (vpn212036.nrl.navy.mil [132.250.212.36]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id r8JIL6es000536; Thu, 19 Sep 2013 14:21:07 -0400 From: Catherine A Meadows Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Sep 2013 14:21:05 -0400 Message-Id: <69ED1CC5-F819-481A-BB90-FB2178A07DDD@nrl.navy.mil> To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-l2vpn-vpls-mcast.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Subject: [secdir] SecDir Review of draft-ietf-l2vpn-vpls-mcast-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 18:21:19 -0000 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. This ID describes a method by which service providers for Virtual = Private LANs can use multicast trees for routing muilticast messages to customers in VPLS. This extends RFC's 4761 = "Virtual Private LAN Service using BGP for Auto-Discovery and Signaling" and 4762, "Virtual Private LAN = Services over MPLS Label Distribution Protocol (LDP) Signaling". In these RFC's, = the ingress Provider Edge Device (ingress PE) replicates a copy of the message for each relevant exit PE. This can = become a performance bottleneck when the number of recipients is large. This ID addresses this problem. This ID addresses mainly internal network management, and so, as the = authors point out in the Security Considerations Section, it does not introduce many security problems other than already = discussed in those RFC's, which are mainly addressed by the security features of BGP, upon which the protocols rely. The main = security issue introduced by this draft is that neither BGP nor VPLS provide for secrecy of the multicast tree data. However, = as the authors point out, providing such security is the responsibility of the Service Provider managing the LAN, and this = is beyond the scope of VPLS. I do not think any modifications or extensions need to be made to the = security section, but I have a couple of other questions: This ID is described as being intended for use with RFC's 4761 and 4762, = but when I checked on 4761 in the ID tracker, it said that it is updated by 4762, although 4762 itself says nothing = about this. In that case, is there any reason to provide support for = 4761? Or was this an error in the ID tracker? Likewise, the ID refers to both 4761 and 4762 for definitions of terms. = What happens if the two RFC's don't agree on a definition? Should one default to 4762, or to the RFC the implementer = is using? According to RFC 4762, the protocol defined by the two RFC's, although they perform similar functions, are = independent and incompatible, so this could make possibly a difference. Cathy Meadows From aland@deployingradius.com Fri Sep 20 04:49:16 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFF721F8578 for ; Fri, 20 Sep 2013 04:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJVsI6Ih94cf for ; Fri, 20 Sep 2013 04:49:10 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 32E0521F856A for ; Fri, 20 Sep 2013 04:49:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 21DC92240109; Fri, 20 Sep 2013 13:48:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LR9AA9UPNUR8; Fri, 20 Sep 2013 13:48:11 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.218.116]) by power.freeradius.org (Postfix) with ESMTPSA id 987F922400E8; Fri, 20 Sep 2013 13:48:11 +0200 (CEST) Message-ID: <523C35FF.20509@deployingradius.com> Date: Fri, 20 Sep 2013 07:48:15 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "secdir@ietf.org" , jpv@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] Secdir Review of draft-ietf-roll-terminology-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 11:49:16 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document contains a list of terms and definitions. It has no security considerations. Alan DeKok. From stbryant@cisco.com Mon Sep 23 04:05:46 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890CF21F8EEA; Mon, 23 Sep 2013 04:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0yzT++7N70Y; Mon, 23 Sep 2013 04:05:34 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4910D21F9E40; Mon, 23 Sep 2013 04:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3444; q=dns/txt; s=iport; t=1379934284; x=1381143884; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LLmean/C2jHDHzzI9rYGxD0R80qtVPpIxuPyvjrDL84=; b=VD1xnM+vag0UJgW2k9+r9YV3oJ9wyGHEXzYYmzh+OkSMKMuQCqT1dsxh soQwp+gfIPMatnj8YpAz4zbm6js+GpM5WUEFn0iMUe1H9Yl5AhmNSwXaz QdMlzB6tldUKuHj+mfKhqvYIJzRkgZqRrL1LEfHjJPfwII6ff0mf9yN8K 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAAEfQFKQ/khR/2dsb2JhbABZgwc4wgOBHRZ0giUBAQEEOEABEAsYCRYPCQMCAQIBRQYBDAEHAQEQh3EMuymPQyIHhB4Dl3yRd4Ml X-IronPort-AV: E=Sophos;i="4.90,872,1371081600"; d="scan'208";a="17738379" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 23 Sep 2013 11:04:22 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8NB4K0I009930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Sep 2013 11:04:20 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r8NB4JQB018818; Mon, 23 Sep 2013 12:04:19 +0100 (BST) Message-ID: <52402033.2030604@cisco.com> Date: Mon, 23 Sep 2013 12:04:19 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yakov Rekhter , Catherine A Meadows References: <69ED1CC5-F819-481A-BB90-FB2178A07DDD@nrl.navy.mil> <201309222250.r8MMo9L61035@magenta.juniper.net> In-Reply-To: <201309222250.r8MMo9L61035@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-l2vpn-vpls-mcast.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir Review of draft-ietf-l2vpn-vpls-mcast-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 11:05:48 -0000 Cathy, Thank you for the review. The only update I can see, which only shows in the tools page and not the datatracker, is by RFC5462, and given the subject matter of RFC5462 the only change can be the renaming of the EXP bits to TC bits. This is well known in the MPLS community, and enhances rather than diminishes security. There were a few people that felt inclined to do production network experiments with these distinctly non-experimental bits and the purpose of RFC5462, was to stop that happening. There is no implication for this draft. - Stewart On 22/09/2013 23:50, Yakov Rekhter wrote: > Cathy, > >> 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 ID describes a method by which service providers for Virtual >> Private LANs can use multicast trees for routing >> muilticast messages to customers in VPLS. This extends RFC's >> 4761 "Virtual Private LAN Service using >> BGP for Auto-Discovery and Signaling" and 4762, "Virtual Private LAN Services >> over MPLS Label Distribution Protocol (LDP) Signaling". In these RFC's, the >> ingress Provider Edge Device (ingress PE) >> replicates a copy of the message for each relevant exit PE. This can become >> a performance bottleneck when the >> number of recipients is large. This ID addresses this problem. >> >> This ID addresses mainly internal network management, and so, as the authors >> point out in the Security Considerations Section, >> it does not introduce many security problems other than already discussed in >> those RFC's, which are mainly addressed by the >> security features of BGP, upon which the protocols rely. The main security >> issue introduced by this draft is that neither >> BGP nor VPLS provide for secrecy of the multicast tree data. However, as the >> authors point out, providing such security >> is the responsibility of the Service Provider managing the LAN, and this >> is beyond the scope of VPLS. >> >> I do not think any modifications or extensions need to be made to the >> security section, but I have a couple of other questions: >> >> This ID is described as being intended for use with RFC's 4761 and 4762, but >> when I checked on 4761 in the ID tracker, >> it said that it is updated by 4762, although 4762 itself says nothing >> about this. In that case, is there any reason to provide support for >> 4761? Or was this an error in the ID tracker? > If indeed the ID tracker said that 4761 is updated by 4762, then this > indeed is an error in the ID tracker. > >> Likewise, the ID refers to both 4761 and 4762 for definitions of terms. What >> happens if the two RFC's don't agree on >> a definition? Should one default to 4762, or to the RFC the implementer >> is using? According to RFC 4762, the protocol >> defined by the two RFC's, although they perform similar functions, >> are independent and incompatible, so this could >> make possibly a difference. > To the RFC the implementer is using. > > Yakov. > > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From yakov@juniper.net Sun Sep 22 15:50:21 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BDB21F9D7A; Sun, 22 Sep 2013 15:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.974 X-Spam-Level: X-Spam-Status: No, score=-104.974 tagged_above=-999 required=5 tests=[AWL=1.625, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deiGvMIWdc6M; Sun, 22 Sep 2013 15:50:15 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9749321F9A70; Sun, 22 Sep 2013 15:50:15 -0700 (PDT) Received: from mail12-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE012.bigfish.com (10.9.40.32) with Microsoft SMTP Server id 14.1.225.22; Sun, 22 Sep 2013 22:50:14 +0000 Received: from mail12-tx2 (localhost [127.0.0.1]) by mail12-tx2-R.bigfish.com (Postfix) with ESMTP id C3CA31601CE; Sun, 22 Sep 2013 22:50:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h1155h) Received-SPF: pass (mail12-tx2: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=yakov@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail12-tx2 (localhost.localdomain [127.0.0.1]) by mail12-tx2 (MessageSwitch) id 1379890212649586_21160; Sun, 22 Sep 2013 22:50:12 +0000 (UTC) Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.252]) by mail12-tx2.bigfish.com (Postfix) with ESMTP id 864B8100049; Sun, 22 Sep 2013 22:50:12 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.51) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 22 Sep 2013 22:50:12 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 22 Sep 2013 15:50:11 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r8MMo9L61035; Sun, 22 Sep 2013 15:50:09 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201309222250.r8MMo9L61035@magenta.juniper.net> To: Catherine A Meadows In-Reply-To: <69ED1CC5-F819-481A-BB90-FB2178A07DDD@nrl.navy.mil> References: <69ED1CC5-F819-481A-BB90-FB2178A07DDD@nrl.navy.mil> X-MH-In-Reply-To: Catherine A Meadows message dated "Thu, 19 Sep 2013 14:21:05 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <62598.1379890209.1@juniper.net> Date: Sun, 22 Sep 2013 15:50:09 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Mailman-Approved-At: Mon, 23 Sep 2013 05:24:51 -0700 Cc: draft-ietf-l2vpn-vpls-mcast.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir Review of draft-ietf-l2vpn-vpls-mcast-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 22:50:21 -0000 Cathy, > 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 ID describes a method by which service providers for Virtual > Private LANs can use multicast trees for routing > muilticast messages to customers in VPLS. This extends RFC's > 4761 "Virtual Private LAN Service using > BGP for Auto-Discovery and Signaling" and 4762, "Virtual Private LAN Services > over MPLS Label Distribution Protocol (LDP) Signaling". In these RFC's, the > ingress Provider Edge Device (ingress PE) > replicates a copy of the message for each relevant exit PE. This can become > a performance bottleneck when the > number of recipients is large. This ID addresses this problem. > > This ID addresses mainly internal network management, and so, as the authors > point out in the Security Considerations Section, > it does not introduce many security problems other than already discussed in > those RFC's, which are mainly addressed by the > security features of BGP, upon which the protocols rely. The main security > issue introduced by this draft is that neither > BGP nor VPLS provide for secrecy of the multicast tree data. However, as the > authors point out, providing such security > is the responsibility of the Service Provider managing the LAN, and this > is beyond the scope of VPLS. > > I do not think any modifications or extensions need to be made to the > security section, but I have a couple of other questions: > > This ID is described as being intended for use with RFC's 4761 and 4762, but > when I checked on 4761 in the ID tracker, > it said that it is updated by 4762, although 4762 itself says nothing > about this. In that case, is there any reason to provide support for > 4761? Or was this an error in the ID tracker? If indeed the ID tracker said that 4761 is updated by 4762, then this indeed is an error in the ID tracker. > Likewise, the ID refers to both 4761 and 4762 for definitions of terms. What > happens if the two RFC's don't agree on > a definition? Should one default to 4762, or to the RFC the implementer > is using? According to RFC 4762, the protocol > defined by the two RFC's, although they perform similar functions, > are independent and incompatible, so this could > make possibly a difference. To the RFC the implementer is using. Yakov. From new-work-bounces@ietf.org Mon Sep 23 04:10:38 2013 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 3C76C21F915C; Mon, 23 Sep 2013 04:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1379934638; bh=8Qcnql7099PGQuJIrJnDGeb7UMoMYbv6azWrfxio/nQ=; h=Date:To:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=X9mz07hpV3jnZPeXcUh4c/o224KZ22xLJGE+webj3lZiCAdAKNXcT3LTlfxRSwRed 9+xY9baTBLaEWdxwY/mqDWpd8AD86gaaPq2QkfCBSunB1HZXKlwZXQRog0Fgha+2Yc isayEJ0SoYhuJZqDSIjM2hX7F9nz+HnOVpQRci+U= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1A921F90AC for ; Mon, 23 Sep 2013 04:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ze-waLcxIa6J for ; Mon, 23 Sep 2013 04:10:20 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id D244F21F949F for ; Mon, 23 Sep 2013 04:10:15 -0700 (PDT) Received: from bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1VO41t-0007Ay-SS for new-work@ietf.org; Mon, 23 Sep 2013 07:10:14 -0400 Date: Mon, 23 Sep 2013 13:10:13 +0200 To: "new-work@ietf.org" MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 23 Sep 2013 05:24:54 -0700 Subject: [secdir] [new-work] Proposed W3C Charters: Web Application Security Working Group, and XML Security Working Group (until 2013-10-21) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 11:10:38 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Security Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Web Application Security Working Group and the XML Security Working Group: http://www.w3.org/2013/07/webappsec-charter.html http://www.w3.org/2013/02/xmlsec-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2013-10-21 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Wendy Seltzer, Team contact . Thank you, Coralie Mercier, W3C Communications [0] https://www.w3.org/Security/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +33643220001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From stephen.farrell@cs.tcd.ie Mon Sep 23 06:26:29 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB25421F9FB6 for ; Mon, 23 Sep 2013 06:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.876 X-Spam-Level: X-Spam-Status: No, score=-102.876 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBgmhuUr83Pt for ; Mon, 23 Sep 2013 06:26:23 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BC08221F9E9F for ; Mon, 23 Sep 2013 06:26:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7DD7CBE20; Mon, 23 Sep 2013 14:26:22 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uq-fKPD7z5tU; Mon, 23 Sep 2013 14:26:22 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5DF3EBDCA; Mon, 23 Sep 2013 14:26:22 +0100 (IST) Message-ID: <5240417E.4040508@cs.tcd.ie> Date: Mon, 23 Sep 2013 14:26:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: "secdir@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Coralie Mercier Subject: Re: [secdir] [new-work] Proposed W3C Charters: Web Application Security Working Group, and XML Security Working Group (until 2013-10-21) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 13:26:29 -0000 I wasn't sure what was changing here so I asked, and Coralie helpfully answered: "The XML Security group has completed its Recommendations and is re-chartered for maintenance only. WebAppSec adds deliverables: an extended version of the Content Security Policy specification, already in progress, and new Recommendations on Secure Mixed Content and Lighweight Isolated / Safe Content." Cheers, S. On 09/23/2013 12:10 PM, Coralie Mercier wrote: > > Hello, > > Today W3C Advisory Committee Representatives received a Proposal to > revise the Security Activity [0] (see the W3C Process > Document description of Activity Proposals [1]). This proposal includes > a draft charter for the Web Application Security Working Group and the > XML Security Working Group: > http://www.w3.org/2013/07/webappsec-charter.html > http://www.w3.org/2013/02/xmlsec-charter.html > > As part of ensuring that the community is aware of proposed work at W3C, > this draft charter is public during the Advisory > Committee review period. > > W3C invites public comments through 2013-10-21 on the proposed charter. > Please send comments to public-new-work@w3.org, which has a public archive: > http://lists.w3.org/Archives/Public/public-new-work/ > > Other than comments sent in formal responses by W3C Advisory Committee > Representatives, W3C cannot guarantee a response to comments. If you > work for a W3C Member [2], please coordinate your comments with your > Advisory Committee Representative. For example, you may wish to make > public comments via this list and have your Advisory Committee > Representative refer to it from his or her formal review comments. > > If you should have any questions or need further information, please > contact Wendy Seltzer, Team contact . > > Thank you, > > Coralie Mercier, W3C Communications > > [0] https://www.w3.org/Security/ > [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation > [2] http://www.w3.org/Consortium/Member/List > From prvs=297886a515=sandra.murphy@parsons.com Mon Sep 23 15:51:21 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D9621F9C4A; Mon, 23 Sep 2013 15:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3khfszIcAOmN; Mon, 23 Sep 2013 15:51:03 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id A983F21F9D30; Mon, 23 Sep 2013 15:51:03 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r8NMfjfW025908; Mon, 23 Sep 2013 17:51:02 -0500 Received: from uther.sparta.com (uther.sparta.com [157.185.0.2]) by txdal11mx03.parsons.com with ESMTP id 1f2qyvjsca-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 23 Sep 2013 17:51:02 -0500 Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id r8NMor8G002376; Mon, 23 Sep 2013 15:50:53 -0700 Received: from CVA-HUB001.centreville.ads.sparta.com ([10.62.108.11]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id r8NMonNP030542; Mon, 23 Sep 2013 15:50:53 -0700 Received: from CVA-MB002.centreville.ads.sparta.com ([fe80::6046:a82a:c500:c9ad]) by CVA-HUB001.centreville.ads.sparta.com ([fe80::20bf:20a8:2ee8:f749%11]) with mapi id 14.02.0342.003; Mon, 23 Sep 2013 18:50:47 -0400 From: "Murphy, Sandra" To: "draft-ietf-6man-ext-transmit.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: SecDir review of draft-ietf-6man-ext-transmit-03 Thread-Index: Ac64rbPvblufa5z/SpSQahVH+ho4QQ== Date: Mon, 23 Sep 2013 22:50:47 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F677CE96C5@CVA-MB002.centreville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-23_04:2013-09-22, 2013-09-23, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=132.136 compositescore=0.0515465056358588 urlsuspect_oldscore=0.515465056358588 suspectscore=0 recipient_domain_to_sender_totalscore=1933 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=8785 rbsscore=0.0515465056358588 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309230140 Subject: [secdir] SecDir review of draft-ietf-6man-ext-transmit-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 22:51:22 -0000 I have reviewed this document as part of the security directorate's=0A= ongoing effort to review all IETF documents being processed by the IESG.=0A= These comments were written primarily for the benefit of the security=0A= area directors. Document editors and WG chairs should treat these=0A= comments just like any other last call comments.=0A= =0A= Draft draft-ietf-6man-ext-transmit-03 describes some of the problems of=0A= deployment of new IPv6 extension header types. It updates RFC 2460 and=0A= RFC 2780 to clarify how extension headers, particularly unrecognized=0A= extension headers, should be treated by intermediate nodes. It also=0A= creates a new IANA registry for extension headers.=0A= =0A= The security considerations section discusses mandated behavior for=0A= firewalls in particular, but without explaining the security=0A= implications of that mandated behavior. The section also mentions the=0A= possibility of exercising previously unused code paths and slow=0A= deployment. Section 1 and 2.1 do a better job of describing the=0A= potential safety problem of accepting unknown extenstion header types=0A= and the connectivity problem of dropping them.=0A= =0A= RFC 4727 security considerations section speaks of the security=0A= concerns of experimental values that would apply to unrecognized=0A= extension headers as well. RFC6564 mentions the potential for a=0A= covert channel through forwarded unrecognized extension headers. The=0A= security considerations section here would be improved by using or=0A= referring to those sorts of discussions.=0A= =0A= Aside from the security considerations section, I puzzled over many=0A= parts of this document. I am not an IPv6 implementers (or of anything=0A= else), but I believe that some of the language would be ambiguous in=0A= implementing this draft.=0A= =0A= standardized vs standard vs experimental=0A= ----------------------------------------=0A= =0A= The draft text says "standardized" in many places where it appears it=0A= means "published in an IETF specification", and in other places where it=0A= appears it means "an extension header defined as a standard". Sometimes=0A= "standardized" and "experimental" seem to be mutually exclusive.=0A= Sometimes "experimental" seems to be one of the set of "standardized'=0A= extensions.=0A= =0A= That language should be cleared up.=0A= =0A= I read this presuming that "standard/standardized" and "experimental"=0A= mean "defined in an IETF Standards Track RFC" and "defined in an IETF=0A= Experimental RFC". That should be clearer.=0A= =0A= "by default" and "configuration" and "policy"=0A= --------------------------------------------=0A= =0A= Section 2.1 says:=0A= =0A= I found the text concerning configuration of policy to discard unrecognize= =0A= extensions and default behavior to be unclear:=0A= =0A= The section starts with:=0A= =0A= Exceptionally, if=0A= this node is designed to examine extension headers for any reason,=0A= such as firewalling, it MUST recognise and deal appropriately with=0A= all standardised IPv6 extension header types =0A= =0A= and then=0A= =0A= RFC 2460 requires destination hosts to discard packets containing=0A= unrecognised extension headers. However, intermediate forwarding=0A= nodes SHOULD NOT do this by default,=0A= =0A= and then=0A= =0A= Experimental IPv6 extension headers, including types 253 and 254=0A= defined by [RFC3692] and [RFC4727], SHOULD be treated in the same way=0A= as standardised extension headers, but they MAY be dropped by=0A= default.=0A= =0A= The text "SHOULD NOT do this by default" and "MAY be dropped by=0A= default" sound inconsistent to me.=0A= =0A= =0A= The text goes on to say:=0A= =0A= Forwarding nodes MUST be configurable to allow packets containing=0A= unrecognised extension headers, but such packets MAY be dropped by=0A= default.=0A= =0A= The text "SHOULD NOT do this by default" and "MAY be dropped by=0A= default" sound inconsistent to me.=0A= =0A= I'm not clear of the intent. The first paragraph above, I believe, is=0A= arguing against having a hard coded response to unrecognized extension=0A= headers. The later text mandating configurability is intended, I=0A= believe, to force/allow the operator to make a deliberate choice. But=0A= then allowing the configuration to have a default that would drop=0A= unrecognized extension headers seems to me to return to the situation=0A= the first paragraph warns against.=0A= =0A= =0A= =0A= IANA considerations section=0A= ---------------------------=0A= =0A= IANA is requested to clearly mark in the Assigned Internet Protocol =0A= Numbers registry those values which are also IPv6 Extension Header=0A= types defined by an IETF action, for example by adding an extra=0A= column to indicate this.=0A= =0A= I believe "an IETF action" is unclear. By RFC5237, these fields in the=0A= current registry are presently assigned by "IESG Approval or Standards=0A= Action". I don't know that you want IESG Approval (which requires no=0A= RFC) for new extension types. If I'm right that you expect standard=0A= extension headers to be defined in Standrads Track RFCs and experimental=0A= extension headers to be defined in Experimental RFCs, I believe that you=0A= want "Standards Action or IETF Review". But I'm not an expert in IANA=0A= registries, you probably should get another opinion.=0A= =0A= Additionally, IANA is requested to replace the existing empty IPv6=0A= Next Header Types registry by an IPv6 Extension Header Types=0A= registry.=0A= =0A= Given that the new registry has a new name, there is no need to replace=0A= the existing registry with the renamed registry. True, it is empty=0A= except for a reference to the protocol numbers registry, but there are=0A= references in documentation etc. to the Next Header Types registry that=0A= would become dangling references. Might as well leave it.=0A= =0A= Section 4.2 of RFC5226 has an explicit template for "What to Put in=0A= Documents That Create a Registry". The information in this section=0A= covers most of what is needed, but not all. It would be easiest to just=0A= follow the template.=0A= =0A= Section 2.1 says=0A= =0A= Packets containing=0A= standardised and undeprecated Routing Headers SHOULD be forwarded by=0A= default. At the time of writing, these include Type 2 [RFC6275],=0A= Type 3 [RFC6554],=0A= =0A= I am not certain what the new extension header IANA registry should=0A= say in this case. The protocol numbers registry lists only the type=0A= 43, with routing types in a subregistry of the Internet Protocol=0A= Version 6 (IPv6) Parameters registry.=0A= =0A= The IPv6 parameters registry also shows that some of the registered=0A= options for Destination Options and Hop-by-Hop Options are Standards=0A= Track and some are Experimental, so I'm not sure what the registry=0A= entries should say for those extension headers. That's particularly=0A= important given the encouragement to use these Destination Options in=0A= lieu of creating new extension headers. Not that it looks like anyone=0A= is paying any attention to that advice.=0A= =0A= =0A= Quibbles=0A= -------=0A= =0A= Section 1 says:=0A= =0A= This document focuses on clarifying how the header chain=0A= should be traversed in the current IPv6 architecture.=0A= =0A= I don't believe that this document changes how the header chain is=0A= traversed, but how unrecognzied headers are treated.=0A= =0A= =0A= In section 3 Security Considerations=0A= =0A= In particular, packets containing=0A= standard extension headers are only to be discarded as a result of a=0A= configurable policy.=0A= =0A= This disagrees with Section 2.1, which says that =0A= =0A= The default configuration=0A= SHOULD allow all standardised extension headers.=0A= =0A= =0A= and=0A= =0A= Forwarding nodes MUST be configurable to allow packets containing=0A= unrecognised extension headers, but such packets MAY be dropped by=0A= default.=0A= =0A= which both seem to allow discarding without an explicit configuration=0A= to discard.=0A= =0A= In Section 3=0A= =0A= will need to take account of them. =0A= =0A= I think you mean "take them into account".=0A= =0A= --Sandy=0A= =0A= Based on checking RFC4727, RFC3692, RFC6564, RFC2460, RFC5237, RFC2780, RFC= 5226, IANA registry for Assigned Internet Protocol Numbers, RFC6275, RFC655= 4, and IANA registry for Destination Options and Hop-by-Hop Options. So I = could easily be confused.=0A= From new-work-bounces@ietf.org Mon Sep 23 11:02:17 2013 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 A89AA21F9FB6; Mon, 23 Sep 2013 11:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1379959337; bh=TbDZdoNSNowhPiZwRTAiuYO/vbIpirvWjVItzzxmRGU=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=Tk0pi6JNdvJDSPYPD1fxaasRQsgYxfgfBrdRKuokFJLwgMmedU//WBW5XOPAFCDZm zJ10gX1JEKFImHwXvA8rp2of+ifFW/XQ50CixUzMA7mPQBaBBeaVnWWy/1xWUdXEda 01G8NkzRz4nkLwXrwb2vHkuO9WSVOvTM0DXlfh0k= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DB921F9FB6; Mon, 23 Sep 2013 11:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tX294H72BZAO; Mon, 23 Sep 2013 11:02:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EA321F8F4A; Mon, 23 Sep 2013 11:02:15 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130923180215.32168.95386.idtracker@ietfa.amsl.com> Date: Mon, 23 Sep 2013 11:02:15 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 23 Sep 2013 15:57:50 -0700 Subject: [secdir] [new-work] WG Review: IPv6 over Networks of Resource-constrained Nodes (6lo) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 18:02:17 -0000 A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-10-03. IPv6 over Networks of Resource-constrained Nodes (6lo) ------------------------------------------------ Current Status: Proposed WG Chairs: Ulrich Herberg Samita Chakrabarti Technical advisors: Ralph Droms Assigned Area Director: Brian Haberman Mailing list Address: 6lo@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/6lo Archive: http://www.ietf.org/mail-archive/web/6lo/current/maillist.html Charter: 6lo focuses on Internet Area work that is needed for constrained node networks with the characteristics of: * limited power, memory and processing resources * hard upper bounds on state, code space and processing cycles * optimization of energy and network bandwidth usage * lack of some layer 2 services like complete device connectivity and broadcast/multicast Specifically, 6lo will work on: 1. IPv6-over-foo adaptation layer specifications using 6LoWPAN technologies (RFC4944, RFC6282, RFC6775) for link layer technologies of interest in constrained node networks 2. Related MIB modules 3. Specifications, such as header compression, that are applicable to more than one adaptation layer specification 4. Maintenance and informational documents required for the existing IETF specifications in this space. Only specifications targeting constrained node networks are in scope. 6lo will work closely with the 6man working group, which will continue to work on IP-over-foo documents outside the constrained node network space and will continue to be the focal point for IPv6 maintenance. For adaptation layer specifications that do not have implications on IPv6 architecture, 6man will be notified about 6lo's working group last call. Specifications that might have such an impact (e.g., by using IPv6 addresses in a specific way or by introducing new ND options) will be closely coordinated with 6man, and/or specific parts will be fanned out to 6man documents. Beyond 6man, 6lo will also coordinate with LWIG and INTAREA. 6lo works on small, focused pieces of Internet Area work. 6lo does not take on larger cross-layer efforts. The working group will continue to reuse existing protocols and mechanisms whenever reasonable and possible. Security and management work that is not specific to the link layers being worked on is out of scope. Work related to routing is out of scope. 6lo will coordinate closely with the working groups in other areas that focus on constrained node networks, such as ROLL (RTG) and CoRE (APP). Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Mon Sep 23 13:12:37 2013 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 7652A21F9FF2; Mon, 23 Sep 2013 13:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1379967157; bh=KV5NpO/wgqVY2z9s2so+dDsKMB5yCqLQZQeeqQmtLbo=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=Y+MKvBLL6zpZGPBV9oEvkemdE55AAKpq+QYBSTUH8NbWNw5wNRWAVLTY0QUgubv3N lMI052Y55JktmX1XiZVtlQH8s7UrNpQJRZnH3SPTecTJt3hl80AzVmNzzGltp/StZQ E7fw/wMYxWZOrLQgNNj6qrXhS3cSVuZM/XT+88x4= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E8921F9DF7; Mon, 23 Sep 2013 13:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fg2wxmaAwj+N; Mon, 23 Sep 2013 13:12:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0976D21F9DD5; Mon, 23 Sep 2013 13:12:35 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130923201235.32168.66736.idtracker@ietfa.amsl.com> Date: Mon, 23 Sep 2013 13:12:35 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 23 Sep 2013 15:57:50 -0700 Subject: [secdir] [new-work] WG Review: MBONE Deployment (mboned) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 20:12:37 -0000 The MBONE Deployment (mboned) working group in the Operations and Management Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-10-03. MBONE Deployment (mboned) ------------------------------------------------ Current Status: Active WG Chairs: Greg Shepherd Leonard Giuliano Technical advisors: Scott Bradner Assigned Area Director: Joel Jaeggli Mailing list Address: mboned@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mboned Archive: http://www.ietf.org/mail-archive/web/mboned Charter: The MBONE Deployment Working Group is a forum for coordinating the deployment, engineering, and operation of multicast routing protocols and procedures in the global Internet, inter-domain and single domain. This activity will include, but not be limited to: - Document deployment of multicast routing in the global Internet. - Receive regular reports on the current state of the deployment of multicast technology. Create "practice and experience" documents that capture the experience of those who have deployed and are deploying various multicast technologies. - Based on reports and other information, provide feedback to other relevant working groups. - Develop mechanisms and procedures for sharing operational information to aid in operation of the multicast backbones and interconnects. - Analyze the need for IPv4 - IPv6 multicast transition solutions - Develop tools, extend protocols and provide operational and implementation advice that assists in multicast administration, diagnostics, troubleshooting and deployment between/within native and non-native environments. - Development of routing and group membership protocols is out of scope. This working group may develop requirements and assist in review and feedback of documents in other working groups responsible for such protocols. Goals and Milestones Nov 2013 Submit multicast transport guidelines for congestion control to IESG Nov 2013 Submit Mtracev2 to IESG for Proposed Standards Nov 2013 Submit Overview of Multicast in the Data Center to IESG for Informational _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From david.waltermire@nist.gov Mon Sep 23 17:28:58 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58B521F93B9; Mon, 23 Sep 2013 17:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4WryNCg+fuv; Mon, 23 Sep 2013 17:28:52 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8210221F9B25; Mon, 23 Sep 2013 17:28:52 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 23 Sep 2013 20:28:36 -0400 Received: from wsget1.nist.gov (129.6.13.150) by wsghub1.xchange.nist.gov (129.6.16.196) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Sep 2013 20:28:50 -0400 Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 23 Sep 2013 20:28:35 -0400 Received: from na01-bl2-obe.outbound.protection.outlook.com (207.46.163.156) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Sep 2013 20:28:50 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB037.namprd09.prod.outlook.com (10.255.211.139) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 24 Sep 2013 00:28:36 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.84]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.84]) with mapi id 15.00.0775.005; Tue, 24 Sep 2013 00:28:36 +0000 From: "Waltermire, David A." To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-repute-considerations-02.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-repute-considerations-02 Thread-Index: Ac64u5t95XJiNBiRTA+5CrvlI/WXLQ== Date: Tue, 24 Sep 2013 00:28:35 +0000 Message-ID: <7d1c197de6e1443daceaea419463c7a5@BLUPR09MB038.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 09796A1B83 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(74316001)(79102001)(33646001)(56816003)(76576001)(4396001)(76796001)(77096001)(74706001)(56776001)(19300405004)(59766001)(46102001)(83072001)(51856001)(81686001)(69226001)(19580395003)(47976001)(31966008)(50986001)(47736001)(74366001)(77982001)(76786001)(81542001)(47446002)(65816001)(63696002)(74502001)(80022001)(54356001)(74876001)(53806001)(16236675002)(83322001)(49866001)(81342001)(15202345003)(66066001)(76482001)(80976001)(76176001)(54316002)(74662001)(15975445006)(81816001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB037; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.224.152; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_7d1c197de6e1443daceaea419463c7a5BLUPR09MB038namprd09pro_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: [secdir] secdir review of draft-ietf-repute-considerations-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 00:28:59 -0000 --_000_7d1c197de6e1443daceaea419463c7a5BLUPR09MB038namprd09pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This draft discusses considerations for providers and consumers of reputati= on data systems targeted at traffic sources. This draft focuses primarily o= n email reputation systems, but provides guidance that is generally applica= ble to other traffic sources. After reviewing this informational document I have a few nits and some mino= r security-related concerns. This document is not ready as there are a few = points that need to be addressed. Areas of concern: Since reputation data is tied to identifiable traffic sources, should there= be privacy considerations discussed in this document? Section 1: Introduction, Paragraph 1: The last sentence refers to "several = operational concepts appear to be common to all of these", but it is not cl= ear what "common to all of these" means. Rating methods? Services? Problem= domains? Something else? Section 3: Evolution, Paragraph 3: There is no evidence presented to justify the claim that the problem space = is reduced by focusing on good actors as compared to bad actors. The author= makes the claim that there are "vastly more IP addresses and email address= es used by bad actors to generate problematic traffic than are used by good= actors to generate desirable traffic." I'd like to see some statistics fro= m one or more reputable studies (no humor intended) that defend this perspe= ctive. There is discussion that "manually edited whitelists" have shown some promi= sing results. It doesn't seem like this will scale well in the face of the = larger IPv6 address space and new GTLDs. Some discussion on this would be u= seful. Section 4: Reputation Clients: The text "For operational clients, this should prompt balanced and comparat= ive, rather than unilateral, use of the service" is confusing. I believe th= is is recommending to use multiple services in a balanced and comparative a= pproach instead of using a single service, but it doesn't read this way. Section 5: Reputation Service Providers: In paragraph 1 the text references "answer as many of the questions identif= ied in Section 4 as possible", but it is not clear what the referenced "ques= tions" are. In paragraph 3 the text asserts that "Reputations should be based on accura= te identifiers, i.e., some property of the content under analysis that is d= ifficult to falsify." Is there a general litmus test that can be applied he= re? Human verification? Automatable verification mechanisms? Is there a min= imum suggested/required practice? Section 6: Security Considerations: While the statement in this section is true, the document doesn't introduce= any new security issues, I was hoping for a summary of the security issues= discussed in the earlier subject matter with suggestions of security mecha= nisms that should be considered for use to address these concerns. Some examples: * Discuss using mechanisms to authenticate RSP services and to prov= ide integrity and confidentiality over exchanged data. Is there a need for = mutual authentication of clients and servers? * The case in Section 4, paragraph 2 is a significant security cons= ideration. Discuss communication mechanisms that enable RSPs to communicate= end-of-life for their services to differentiate from malicious activity. C= ould this be handled using DNS SRV records? If the service is no longer ann= ounced, this could signal end-of-life for the service. If this is too speci= fic for the scope of the document, a more general discussion could be inclu= ded describing the characteristics of any acceptable solution. A few nits: Abstract: s/reputation systems is has become/reputation systems has become/ Section 4: Reputation Clients: s/whether the reported reputation a scalar/whether the reported reputation = is a scalar/ s/capability to effect local overrides/capability to affect local overrides= / s/One choice is to query and cross-referencing multiple RSPs/One choice is = to query and cross-reference multiple RSPs/ Section 5: Reputation Service Providers s/found in a validated domain-level signature is./found in a validated doma= in-level signature is verifiable./ s/For example, it shoudl be possible for the reply to/For example, it shoul= d be possible for the reply to/ --_000_7d1c197de6e1443daceaea419463c7a5BLUPR09MB038namprd09pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the secu= rity directorate's ongoing effort to review all IETF documents being p= rocessed by the IESG.  These comments were written primarily for the b= enefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last= call comments.

 

This draft discusses considerations for providers an= d consumers of reputation data systems targeted at traffic sources. This dr= aft focuses primarily on email reputation systems, but provides guidance th= at is generally applicable to other traffic sources.

 

After reviewing this informational document I hav= e a few nits and some minor security-related concerns. This document is not= ready as there are a few points that need to be addressed.

 

Areas of concern:

 

Since reputation data is tied to identifiable tra= ffic sources, should there be privacy considerations discussed in this docu= ment?

 

Section 1: Introduction, Paragraph 1: The last se= ntence refers to “several operational concepts appear to be common to= all of these”, but it is not clear what “common to all of thes= e” means.  Rating methods? Services? Problem domains? Something else?

 

Section 3: Evolution, Paragraph 3:

 

There is no evidence presented to justify the cla= im that the problem space is reduced by focusing on good actors as compared= to bad actors. The author makes the claim that there are “vastly mor= e IP addresses and email addresses used by bad actors to generate problematic traffic than are used by good actors= to generate desirable traffic.” I’d like to see some statistic= s from one or more reputable studies (no humor intended) that defend this p= erspective.

 

There is discussion that “manually edited w= hitelists” have shown some promising results. It doesn’t seem l= ike this will scale well in the face of the larger IPv6 address space and n= ew GTLDs. Some discussion on this would be useful.

 

Section 4: Reputation Clients:

 

The text “For operational clients, this sho= uld prompt balanced and comparative, rather than unilateral, use of the ser= vice” is confusing. I believe this is recommending to use multiple se= rvices in a balanced and comparative approach instead of using a single service, but it doesn’t read this way.

 

Section 5: Reputation Service Providers:

 

In paragraph 1 the text references “answer = as many of the questions identified in Section 4 = as possible”, but it is not clear what the referenced “question= s” are.

 

In paragraph 3 the text asserts that “Reput= ations should be based on accurate identifiers, i.e., some property of the = content under analysis that is difficult to falsify.” Is there a gene= ral litmus test that can be applied here? Human verification? Automatable verification mechanisms? Is there a minimum sugg= ested/required practice?

 

Section 6: Security Considerations:

 

While the statement in this section is true, the = document doesn’t introduce any new security issues, I was hoping for = a summary of the security issues discussed in the earlier subject matter wi= th suggestions of security mechanisms that should be considered for use to address these concerns.

 

Some examples:

·         Discuss using mechanisms to authenticate RSP= services and to provide integrity and confidentiality over exchanged data.= Is there a need for mutual authentication of clients and servers?

·         The case in Section 4, paragraph 2 is a sign= ificant security consideration. Discuss communication mechanisms that enabl= e RSPs to communicate end-of-life for their services to differentiate from = malicious activity. Could this be handled using DNS SRV records? If the service is no longer announced, this= could signal end-of-life for the service. If this is too specific for the = scope of the document, a more general discussion could be included describi= ng the characteristics of any acceptable solution.

 

A few nits:

 

Abstract:

s/reputation systems is has become/reputation sys= tems has become/

 

Section 4: Reputation Clients:

s/whether the reported reputation a scalar/whethe= r the reported reputation is a scalar/

s/capability to effect local overrides/capability= to affect local overrides/

s/One choice is to query and cross-referencing mu= ltiple RSPs/One choice is to query and cross-reference multiple RSPs/<= /o:p>

 

Section 5: Reputation Service Providers

s/found in a validated domain-level signature is.= /found in a validated domain-level signature is verifiable./

s/For example, it shoudl be possible for the repl= y to/For example, it should be possible for the reply to/

 

--_000_7d1c197de6e1443daceaea419463c7a5BLUPR09MB038namprd09pro_-- From david.waltermire@nist.gov Mon Sep 23 18:02:24 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D7B11E80FE; Mon, 23 Sep 2013 18:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSvD3sBv9XG4; Mon, 23 Sep 2013 18:02:18 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 411E811E80FA; Mon, 23 Sep 2013 18:02:16 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 23 Sep 2013 21:01:55 -0400 Received: from wsget2.nist.gov (129.6.13.151) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 23 Sep 2013 21:02:09 -0400 Received: from WSGHUB2.xchange.nist.gov (129.6.42.35) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 23 Sep 2013 21:01:54 -0400 Received: from na01-bl2-obe.outbound.protection.outlook.com (207.46.163.207) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Sep 2013 21:02:09 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB037.namprd09.prod.outlook.com (10.255.211.139) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 24 Sep 2013 01:01:59 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.84]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.84]) with mapi id 15.00.0775.005; Tue, 24 Sep 2013 01:01:59 +0000 From: "Waltermire, David A." To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-intarea-flow-label-balancing-01.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-intarea-flow-label-balancing-01 Thread-Index: Ac64v+KAhPeWeWgeQa6vKt5AEf+R0w== Date: Tue, 24 Sep 2013 01:01:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 09796A1B83 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(74316001)(79102001)(33646001)(56816003)(76576001)(4396001)(76796001)(77096001)(74706001)(56776001)(19300405004)(59766001)(46102001)(51856001)(83072001)(81686001)(69226001)(19580395003)(47976001)(31966008)(50986001)(47736001)(74366001)(77982001)(76786001)(81542001)(47446002)(83322001)(65816001)(63696002)(74502001)(80022001)(54356001)(74876001)(53806001)(16236675002)(49866001)(81342001)(15202345003)(66066001)(76482001)(80976001)(76176001)(54316002)(74662001)(15975445006)(81816001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB037; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.224.152; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_ba7f719ed2c24ec585ff4a4f1ab3611dBLUPR09MB038namprd09pro_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: [secdir] secdir review of draft-ietf-intarea-flow-label-balancing-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 01:02:25 -0000 --_000_ba7f719ed2c24ec585ff4a4f1ab3611dBLUPR09MB038namprd09pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This informational ID describes applying the IPv6 flow label to enhance lay= er 3/4 load distribution for large server farms. The security consideration= s in this document build upon the security considerations discussed in RFC6= 437. The document is ready for publication. I have no additional security concerns beyond those listed in the document. Sincerely, Dave Waltermire --_000_ba7f719ed2c24ec585ff4a4f1ab3611dBLUPR09MB038namprd09pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the secu= rity directorate's ongoing effort to review all IETF documents being p= rocessed by the IESG.  These comments were written primarily for the b= enefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last= call comments.

 

This informational ID describes applying the IPv6 fl= ow label to enhance layer 3/4 load distribution for large server farms. The= security considerations in this document build upon the security considera= tions discussed in RFC6437.

 

The document is ready for publication.=

 

I have no additional security concerns beyond those = listed in the document.

 

Sincerely,

Dave Waltermire

 

 

--_000_ba7f719ed2c24ec585ff4a4f1ab3611dBLUPR09MB038namprd09pro_-- From jsalowey@cisco.com Mon Sep 23 23:00:12 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F1121F9E11; Mon, 23 Sep 2013 23:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i92BHvIWNVFZ; Mon, 23 Sep 2013 23:00:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4718321F9DCE; Mon, 23 Sep 2013 23:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1369; q=dns/txt; s=iport; t=1380002406; x=1381212006; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=7l9Rr4FPKv63LP382Ie28s3N+qeTt7yf/C6P2PuQXbA=; b=SQqUQZAKvIniyVuInUjE/v+QpEkaYUnRkNhqmycADtM65HUMdYXZeM4n r2BCyNld/Qp9DhjVp/OxZyRcF37dvY9A3nti9ShisiTypJpuTl6l1X5tV nTz+cder1L8/BhHAhD26Kcmz9tnLHoIjjvb/O7OksH7B4QxZwEVXsT3zI M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAEEpQVKtJV2c/2dsb2JhbABagweBCsEogSIWdIInAQQ6UQEqFEInBAEah328ZY8gg1aBAAOpc4Mkgio X-IronPort-AV: E=Sophos;i="4.90,968,1371081600"; d="scan'208";a="263653000" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 24 Sep 2013 06:00:06 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8O605xq028339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Sep 2013 06:00:05 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.212]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 01:00:05 -0500 From: "Joseph Salowey (jsalowey)" To: "" , The IESG , "draft-ietf-sidr-bgpsec-threats-06.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-sidr-bgpsec-threats-06 Thread-Index: AQHOuOtQNP014ejpdES76SMyLe+X8w== Date: Tue, 24 Sep 2013 06:00:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.127] Content-Type: text/plain; charset="us-ascii" Content-ID: <0551690C4CF3B342B69798D73EB9DD16@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-sidr-bgpsec-threats-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 06:00:12 -0000 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. This document discusses a threat model for BGP Path Security. The docume= nt contains a lot of good information, but I found it hard to follow in pla= ces =20 Some issues: 1. I found it difficult to link the threats in section 3 to the attacks i= n section 4. This is more of a consistency of terminology issue and is pr= obably just a nit.=20 2. The attacks in sections 4.1, 4.2, and 4.3 seem to be largely discounte= d as out of scope, yet they seem to impact the goals of PATHSEC. Is it as= sumed that there are countermeasures in place such as link protection betwe= en RGP peers? If other countermeasures besides PATHSEC are expected to b= e in place this should probably be mentioned in the security considerations= . =20 3. I found the argument against not including 'route leakage' a bit weak = since the documents seems to be able to define what it means. Wouldn't 'r= oute leakage' be a mechanism to realize one or more of the threats in secti= on 3? =20 Thanks, Joe From kwiereng@cisco.com Wed Sep 25 04:04:55 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5DC21F9FAE; Wed, 25 Sep 2013 04:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65AqJb9QTdWe; Wed, 25 Sep 2013 04:04:49 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF5B21E804C; Wed, 25 Sep 2013 04:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2170; q=dns/txt; s=iport; t=1380107087; x=1381316687; h=from:to:subject:date:message-id:mime-version; bh=FpkZSj+P/Pl7P/p3U/IjNyIEuCyaJ+Zy6dtq/JP/Ui0=; b=F9oXqW8J7TggPjNwIAGzMbEHxPm97OuI5WB5AvBtWRhSmNE7KMEvLNfU trAselng0br459xwmAfYFfUl775wxRrkZoPqaWvF5Rt+a+X00WozZSsu5 ThM28foUB81r6G4i+nEJIvXE2GyMZWhIwZGQdaOMfSrP+hjvlza2yBotj 4=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAMLCQlKtJXG8/2dsb2JhbABbgweBCsBFgR4WdIInAQSBCwEqVicEARoGh3i8EY4SgQ6DVYEAA5AmgS+YHoMkgWhC X-IronPort-AV: E=Sophos;i="4.90,977,1371081600"; d="asc'?scan'208";a="264263040" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 25 Sep 2013 11:04:46 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8PB4kwj029834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Sep 2013 11:04:46 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.246]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 06:04:46 -0500 From: "Klaas Wierenga (kwiereng)" To: "draft-ietf-p2psip-rpr-10.all@tools.ietf.org" , "secdir@ietf.org" , The IESG Thread-Topic: Secdir review of draft-ietf-p2psip-rpr-10 Thread-Index: AQHOud8L86vfRBD7dEabVZIus9pGkA== Date: Wed, 25 Sep 2013 11:04:45 +0000 Message-ID: <7E1636E02F313F4BA69A428B314B77C709FDEF46@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.105.222] Content-Type: multipart/signed; boundary="Apple-Mail=_9EA7185B-471B-4F30-9A51-49A5EC982895"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-p2psip-rpr-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 11:04:55 -0000 --Apple-Mail=_9EA7185B-471B-4F30-9A51-49A5EC982895 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. This document defines an optional extension to RELOAD to support Relay = Peer Routing (RPR) mode (as opposed to Symmetric Recursive Routing = (SRR). The document is straightforward and clear, but with respect to = the security considerations a few comments: - I am surprised that there is no discussion on the relay peer being the = single (or few) point of failure, and thus becoming an interesting = target for DoS attacks: the relay peer acts as a hub for all traffic = coming from the peers that have it as their relay. Especially when there = is a limited number of relays it becomes attractive to bring the relay = down.=20 - The other thing I wonder about is why there is the need to trust the = relay, why is this different from the DRR case (apart from the = observation in my previous comment)? It seems that the system would work = just fine without the explicit trust in the relay peer, in fact, the way = I understand it every peer in the overlay can in principle act as a = relay peer (I imagine a scenario where the relay peer acts as the = "established connection"). Cheers, Klaas Wierenga --Apple-Mail=_9EA7185B-471B-4F30-9A51-49A5EC982895 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 - http://gpgtools.org iEYEARECAAYFAlJCw0wACgkQH2Wy/p4XeFL32QCfb6d8vh45Hx1fgmY6zfLO/+HS VPsAoMqRh80Pujg8kduAnfXg2Mpm5qRo =xzwe -----END PGP SIGNATURE----- --Apple-Mail=_9EA7185B-471B-4F30-9A51-49A5EC982895-- From jsalowey@cisco.com Wed Sep 25 17:44:48 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00B411E8126; Wed, 25 Sep 2013 17:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JTy344RhtjC; Wed, 25 Sep 2013 17:44:38 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B2F8921F90E5; Wed, 25 Sep 2013 17:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5735; q=dns/txt; s=iport; t=1380156271; x=1381365871; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2WVmMswHmyE2BiSd1nU+GXZkDdIMIdQy+G5KLBxP3rU=; b=Xof/X+CTfAKgYK2UKMfM4i7gsMVe+Pivg22XmXB7t/Nq+CLej30FwudS 5w6xVkpbNtKwgJaV4oe3Y6jO4qO08MhiydlozZRf7d1kSmVbr1zTTBk5z Loi2fX9rSOUzziT9VYU5L9r5ejMtD/LuI0SrEkfeDU9gZ1u2P272JVqnv k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAPOCQ1KtJXG+/2dsb2JhbABbgwd+DMBWgR4WdIIlAQEBAwE6LRIFCwIBCCIUEDIlAgQOBQiHeAa8S48eAjEHgx2BAQOpc4MkgWokHA X-IronPort-AV: E=Sophos;i="4.90,981,1371081600"; d="scan'208";a="264343207" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 26 Sep 2013 00:44:30 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8Q0iUD3009506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Sep 2013 00:44:30 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.212]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 19:44:29 -0500 From: "Joseph Salowey (jsalowey)" To: "Chris Lonvick (clonvick)" Thread-Topic: SECDIR review of draft-ietf-emu-eap-tunnel-method-07.txt Thread-Index: AQHOulGOwb81HpkntUiUva5HUVpGwA== Date: Thu, 26 Sep 2013 00:44:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.127] Content-Type: text/plain; charset="us-ascii" Content-ID: <2B2215D6F9BB05478BB0095031E5D6F2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" Subject: Re: [secdir] SECDIR review of draft-ietf-emu-eap-tunnel-method-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 00:44:48 -0000 Hi Chris, Thanks for the review, I missed it earlier. responses inline below: On Jul 24, 2013, at 9:44 AM, Chris Lonvick wrote: > Hi, >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > Overall the document is well written and I found it to be complete. Since= the document is a bit on the long side, I focused on sections 1 through 3,= and 7. I scanned sections 4, 5, and 6. I did not review the Appendixes. = I did have a couple of issues that I want to raise: >=20 > In Section 3.6.1, point #2 says that the TEAP packet is to be "ignored" i= f the other fields are "wrong". > - What does "wrong" mean? [Joe] Wrong means inconsistent with the rest of the specification. new tex= t: "The entire TEAP packet will be ignored if other fields (version, length, f= lags, etc.) are inconsistent with this specification." > - Also, I'd like to see some more clarification of what is expected from = the carrier protocol if the TEAP packet is "ignored". Wouldn't the carrier= protocol just attempt redelivery if it doesn't get some sort of acknowldeg= ement of the delivery of the TEAP packet? >=20 [Joe] Yes, this is aligned with the behavior in RFC 3748. THis will result= in a timeout and termination of the conversation.=20 > Section 3.8 (second paragraph) says: > > TEAP implementations SHOULD have > > a configuration where authentication fails if mutual authentication > > cannot be achieved. > My personal feeling is that the SHOULD should be replaced with a MUST, bu= t I acknowledge that is an implementation detail. I then went looking for = a discussion of this in the Security Considerations section and found 7.1 o= n "Mutual Authentication and Integrity Protection". However I couldn't fin= d anything in that section on Mutual Authentication. Would you please add = some discussion to that section on the problems that could arise if an impl= ementation does not have mutual authentication? >=20 [Joe] The terminology in this section is misleading. It states peers must = mutually authenticate the server and the rest of the section should refer t= o server authentication new text: "Several TEAP services including server unauthenticated provisioning, PAC provisioning, certificate provisioning and channel binding depend on the peer trusting the TEAP server. Peers MUST=20 authenticate the server before these peer services are used. TEAP peers MUST track whether server authentication has taken place. Server authentication results if the peer trusts the provided server certificate. Typically this involves both validating the certificate to a trust anchor and confirming the entity named by the certificate is the intended server. Server authentication also results when the procedures of Section 3.3 are used to resume a session in which the the peer and server was previously mutually authenticated. Alternatively, if an inner EAP method providing mutual authentication and an Extended Master Session Key (EMSK) is executed and cryptographic binding with the EMSK compound MAC is present (Section 4.2.13), then the session is mutually authenticated and peer services can be used. =20 TEAP implementations SHOULD NOT use peer services by default unless the session is server authenticated. TEAP peer implementations MUST have a configuration where authentication fails if server authentication cannot be achieved. An additional complication arises when a tunnel method authenticates multiple parties such as authenticating both the peer machine and the peer user to the EAP server. Depending on how authentication is achieved, only some of these parties may have confidence in it. For example if a strong shared secret is used to mutually authenticate the user and the EAP server, the machine may not have confidence that the EAP server is the authenticated party if the machine cannot trust the user not to disclose the shared secret to an attacker. In these cases, the parties who participate in the authentication need to be considered when evaluating whether to use peer services. " >=20 > I also found a few nits that you may want to look at. >=20 > You mostly use "Type-Length-Value" but you have one instance of "Type Len= gth Value". >=20 > Section 3.1 says, > > MUST use a version field set to 1. > Throughout section 4 you sometimes use "set to 1", and sometimes use "set= to zero (0)", and in a few cases "set to (1)". This inconsistency just se= t my OCD value to one (1). ;-) >=20 > Section 3.3 > > If the server ignores the > > request, it proceeds with termination of the tunnel and send the > > clear text EAP Success or Failure message based on the Status field > > of the peer's Request-Action TLV. > Maybe: > If the server ignores the > request, it proceeds with termination of the tunnel and sends the > or "will send". >=20 > Typo in section 3.8.4 > > after it has succ;essfully authenticated the server and established >=20 > Section 7 > > greater. The threat model used for the security evaluation of TEAP > > is defined in the EAP [RFC3748]. > Maybe just "defined in EAP [RFC3748].", or "defined in the security consi= deration section in EAP [[RFC3748]." >=20 >=20 [Joe] Thanks, I'll address these.=20 > Regards, > Chris From brian.e.carpenter@gmail.com Wed Sep 25 22:21:39 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714C221F9CEA; Wed, 25 Sep 2013 22:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+juXxepBv4Q; Wed, 25 Sep 2013 22:21:38 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 53AC111E8146; Wed, 25 Sep 2013 22:21:38 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp2so637044pbb.14 for ; Wed, 25 Sep 2013 22:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1z44fY5xejgrqg56S0dL8nfqxIIRdEwyEfEEjW1O9tI=; b=mRWc+Xf6SvpOBDxyQ3ZlDSLaJCei/dD3Og7Uh5hxvb7t70NnLiumO4PPYy3U/qFnie bFbqgb5Ft4bJlKSpifFnHHPBOLzrdP7UAyI5BTVafx96jL9g5T8Ih83Ya0wJFkqhVwkU wFSxJd8LdVdCc4PwIobtERjv650tDgBzVTBWf80VMIZEdNGQsI8txUOH3hymsBFEIIH+ lS+g4u9auzCwbCEBkO4rZMHXTd6am2yARHL6bL39MtwYhY8bH3/MEHv55FkqT4lV8sDX Ek2S6QerKUb9oQjkIfqu1CaCpSF5pz/blRNBkwHtvspOzn+6CAWCi9wndxdrsjbrQe/s 8NXw== X-Received: by 10.68.96.130 with SMTP id ds2mr26996820pbb.99.1380172897969; Wed, 25 Sep 2013 22:21:37 -0700 (PDT) Received: from [192.168.178.20] (90.200.69.111.dynamic.snap.net.nz. [111.69.200.90]) by mx.google.com with ESMTPSA id dw3sm51641181pbc.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Sep 2013 22:21:37 -0700 (PDT) Message-ID: <5243C45A.3070708@gmail.com> Date: Thu, 26 Sep 2013 17:21:30 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Murphy, Sandra" References: <24B20D14B2CD29478C8D5D6E9CBB29F677CE96C5@CVA-MB002.centreville.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F677CE96C5@CVA-MB002.centreville.ads.sparta.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "draft-ietf-6man-ext-transmit.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-6man-ext-transmit-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 05:21:39 -0000 Sandy, Thanks again for the extensive review. We have a new version out: The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-ext-transmit There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-ext-transmit-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ext-transmit-04 Now some direct responses to your review: On 24/09/2013 10:50, Murphy, Sandra wrote: ... > The security considerations section discusses mandated behavior for > firewalls in particular, but without explaining the security > implications of that mandated behavior. A new paragraph has been added. ... > > RFC 4727 security considerations section speaks of the security > concerns of experimental values that would apply to unrecognized > extension headers as well. RFC6564 mentions the potential for a > covert channel through forwarded unrecognized extension headers. The > security considerations section here would be improved by using or > referring to those sorts of discussions. OK > > Aside from the security considerations section, I puzzled over many > parts of this document. I am not an IPv6 implementers (or of anything > else), but I believe that some of the language would be ambiguous in > implementing this draft. > > standardized vs standard vs experimental > ---------------------------------------- > > The draft text says "standardized" in many places where it appears it > means "published in an IETF specification", and in other places where it > appears it means "an extension header defined as a standard". I think that comes to the same thing. Some extension headers are hidden in broader specs, others have stand-alone RFCs. > Sometimes > "standardized" and "experimental" seem to be mutually exclusive. > Sometimes "experimental" seems to be one of the set of "standardized' > extensions. That, unfortunately, is reality. RFC5201 is an Experimental RFC that defines an extension header. RFC4727 is a Proposed Standard RFC that defines values for experimental use. RFC3692 is a BCP that does the same (and, I think, makes the assignment for RFC5201 illegal, if you're picky). > That language should be cleared up. > > I read this presuming that "standard/standardized" and "experimental" > mean "defined in an IETF Standards Track RFC" and "defined in an IETF > Experimental RFC". That should be clearer. We've defined and tried to clarify the terminology, but the confusion is intrinsic to the existing RFCs. We've attempted to be consistent, at least. > "by default" and "configuration" and "policy" > -------------------------------------------- > > Section 2.1 says: > > I found the text concerning configuration of policy to discard unrecognize > extensions and default behavior to be unclear: > > The section starts with: > > Exceptionally, if > this node is designed to examine extension headers for any reason, > such as firewalling, it MUST recognise and deal appropriately with > all standardised IPv6 extension header types > > and then > > RFC 2460 requires destination hosts to discard packets containing > unrecognised extension headers. However, intermediate forwarding > nodes SHOULD NOT do this by default, > > and then > > Experimental IPv6 extension headers, including types 253 and 254 > defined by [RFC3692] and [RFC4727], SHOULD be treated in the same way > as standardised extension headers, but they MAY be dropped by > default. > > The text "SHOULD NOT do this by default" and "MAY be dropped by > default" sound inconsistent to me. Yes, those ideas are squeezed into too few words. > > > The text goes on to say: > > Forwarding nodes MUST be configurable to allow packets containing > unrecognised extension headers, but such packets MAY be dropped by > default. > > The text "SHOULD NOT do this by default" and "MAY be dropped by > default" sound inconsistent to me. > > I'm not clear of the intent. What we are trying to do is reconcile the IPv6 architecture that *requires" all forwarding nodes to allow all extension headers with the firewall role that requires firewalls to drop suspect packets. We've tuned the language. There is a logical cascade here: All nodes MUST recognise all valid extension headers Firewalls MUST NOT discard extension headers without good reason (expressed as SHOULD NOT discard valid headers by default) Except that firewalls MAY discard experimental/unrecognised headers by default. > The first paragraph above, I believe, is > arguing against having a hard coded response to unrecognized extension > headers. The later text mandating configurability is intended, I > believe, to force/allow the operator to make a deliberate choice. But > then allowing the configuration to have a default that would drop > unrecognized extension headers seems to me to return to the situation > the first paragraph warns against. That's not intended, but we're ttrying to be realistic about what firewall vendors are likely to set as defaults. We don't think they would allow experimental values through by default, whatever we wrote. > > IANA considerations section > --------------------------- > > IANA is requested to clearly mark in the Assigned Internet Protocol > Numbers registry those values which are also IPv6 Extension Header > types defined by an IETF action, for example by adding an extra > column to indicate this. > > I believe "an IETF action" is unclear. By RFC5237, these fields in the > current registry are presently assigned by "IESG Approval or Standards > Action". IANA didn't query this, but you are right. We didn't put "Standards Action" because of experimental values. We need to put "Standards Action or IESG Approval" to match RFC5226. > I don't know that you want IESG Approval (which requires no > RFC) for new extension types. If I'm right that you expect standard > extension headers to be defined in Standrads Track RFCs and experimental > extension headers to be defined in Experimental RFCs, I believe that you > want "Standards Action or IETF Review". But I'm not an expert in IANA > registries, you probably should get another opinion. > > Additionally, IANA is requested to replace the existing empty IPv6 > Next Header Types registry by an IPv6 Extension Header Types > registry. > > Given that the new registry has a new name, there is no need to replace > the existing registry with the renamed registry. True, it is empty > except for a reference to the protocol numbers registry, but there are > references in documentation etc. to the Next Header Types registry that > would become dangling references. Might as well leave it. Good catch, but I think leaving it empty is also misleading. We have now asked IANA to insert a pointer to redirect the dangling reference. > > Section 4.2 of RFC5226 has an explicit template for "What to Put in > Documents That Create a Registry". The information in this section > covers most of what is needed, but not all. It would be easiest to just > follow the template. I'll check, but I think that following IANA's comments we have covered everthinng now. > > Section 2.1 says > > Packets containing > standardised and undeprecated Routing Headers SHOULD be forwarded by > default. At the time of writing, these include Type 2 [RFC6275], > Type 3 [RFC6554], > > I am not certain what the new extension header IANA registry should > say in this case. The protocol numbers registry lists only the type > 43, with routing types in a subregistry of the Internet Protocol > Version 6 (IPv6) Parameters registry. Yes, they don't seem to belong here. > > The IPv6 parameters registry also shows that some of the registered > options for Destination Options and Hop-by-Hop Options are Standards > Track and some are Experimental, so I'm not sure what the registry > entries should say for those extension headers. That's particularly > important given the encouragement to use these Destination Options in > lieu of creating new extension headers. Not that it looks like anyone > is paying any attention to that advice. The option headers themselves are standards track, being built into RFC2460. We really don't want to dive into individual options in this document. Admittedly, firewall developers may feel they have to do so, but we can't legislate everything. > > Quibbles > ------- > > Section 1 says: > > This document focuses on clarifying how the header chain > should be traversed in the current IPv6 architecture. > > I don't believe that this document changes how the header chain is > traversed, but how unrecognzied headers are treated. Correct. > > > In section 3 Security Considerations > > In particular, packets containing > standard extension headers are only to be discarded as a result of a > configurable policy. > > This disagrees with Section 2.1, which says that > > The default configuration > SHOULD allow all standardised extension headers. > > > and > > Forwarding nodes MUST be configurable to allow packets containing > unrecognised extension headers, but such packets MAY be dropped by > default. > > which both seem to allow discarding without an explicit configuration > to discard. For headers unknown to the firewall, yes. We don't seriously expect anything else as a factory default. > > In Section 3 > > will need to take account of them. > > I think you mean "take them into account". OK > > --Sandy > > Based on checking RFC4727, RFC3692, RFC6564, RFC2460, RFC5237, RFC2780, RFC5226, IANA registry for Assigned Internet Protocol Numbers, RFC6275, RFC6554, and IANA registry for Destination Options and Hop-by-Hop Options. So I could easily be confused. > From kivinen@iki.fi Thu Sep 26 04:27:46 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F3F21F9D1E for ; Thu, 26 Sep 2013 04:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxqdKarMGg8t for ; Thu, 26 Sep 2013 04:27:44 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAAC21F9433 for ; Thu, 26 Sep 2013 04:27:30 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r8QBRE1U017487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 26 Sep 2013 14:27:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r8QBRC5V002929; Thu, 26 Sep 2013 14:27:12 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21060.6672.765457.551629@fireball.kivinen.iki.fi> Date: Thu, 26 Sep 2013 14:27:12 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 11:27:46 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Shawn Emery is next in the rotation. For telechat 2013-09-26 Reviewer LC end Draft Rob Austein T 2013-08-29 draft-ietf-netext-update-notifications-08 Dan Harkins T 2013-09-02 draft-ietf-ccamp-gmpls-signaling-g709v3-12 David Harrington TR2013-09-03 draft-ietf-dhc-dhcpv6-solmaxrt-update-05 Julien Laganier T 2013-09-17 draft-ietf-ccamp-swcaps-update-03 Ondrej Sury T 2013-08-16 draft-nandakumar-rtcweb-stun-uri-07 Tina TSOU TR2013-08-16 draft-petithuguenin-behave-turn-uris-07 For telechat 2013-10-10 Rob Austein T 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Glen Zorn T 2013-09-27 draft-ietf-sipcore-rfc4244bis-callflows-06 Last calls and special requests: Derek Atkins 2013-10-01 draft-ietf-siprec-architecture-08 Rob Austein 2013-10-16 draft-kolkman-proposed-standards-clarified-03 Dave Cridland - draft-ietf-httpbis-p5-range-24 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Dave Cridland 2013-10-03 draft-ietf-dhc-option-guidelines-14 Alan DeKok 2013-10-18 draft-hethmon-mcmurray-ftpext-ftp-hosts-03 Donald Eastlake 2013-10-10 draft-mcgrew-tls-aes-ccm-ecc-07 Jeffrey Hutzelman 2013-07-16 draft-yusef-dispatch-ccmp-indication-04 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-04 Julien Laganier - draft-ietf-avtcore-rtp-security-options-06 Julien Laganier - draft-ietf-websec-key-pinning-08 Ben Laurie 2013-09-23 draft-ietf-idr-rfd-usable-03 Matt Lepinski 2013-09-24 draft-ietf-l2vpn-pbb-vpls-interop-05 Alexey Melnikov - draft-ietf-payload-rtp-howto-06 Kathleen Moriarty 2013-10-01 draft-resnick-retire-std1-01 Magnus Nystrom 2013-09-24 draft-ietf-insipid-session-id-reqts-08 Vincent Roca 2013-09-24 draft-ietf-mmusic-duplication-grouping-03 Ondrej Sury 2013-09-27 draft-ietf-ecrit-psap-callback-10 Tina TSOU 2013-09-27 draft-ietf-ecrit-unauthenticated-access-07 Carl Wallace 2013-09-30 draft-ietf-hip-reload-instance-08 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-13 Sam Weiler 2013-09-30 draft-ietf-opsec-ip-options-filtering-05 Brian Weis - draft-ietf-radext-dtls-06 Brian Weis 2013-09-30 draft-ietf-p2psip-drr-10 Tom Yu 2013-10-01 draft-ietf-sidr-origin-ops-21 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 -- kivinen@iki.fi From Tina.Tsou.Zouting@huawei.com Thu Sep 26 17:24:36 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D270D11E8113; Thu, 26 Sep 2013 17:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.38 X-Spam-Level: X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w07AiPYqP5hp; Thu, 26 Sep 2013 17:24:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E6C4411E810F; Thu, 26 Sep 2013 17:24:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVX13039; Fri, 27 Sep 2013 00:24:29 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 27 Sep 2013 01:23:31 +0100 Received: from SJCEML402-HUB.china.huawei.com (10.212.94.43) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 27 Sep 2013 01:24:12 +0100 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.42]) by sjceml402-hub.china.huawei.com ([10.212.94.43]) with mapi id 14.03.0146.000; Thu, 26 Sep 2013 17:24:09 -0700 From: Tina TSOU To: "draft-petithuguenin-behave-turn-uris@tools.ietf.org" , "Iesg@Ietf. Org" , "Secdir@Ietf. Org" Thread-Topic: SecDir review of draft-petithuguenin-behave-turn-uris-07 Thread-Index: AQHOuxfh+PMcgSiXZ0q6wEG+aitM2w== Date: Fri, 27 Sep 2013 00:24:08 +0000 Message-ID: <66CB93EA-25C1-4FB0-88EE-0CC22D01F1B2@huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [secdir] SecDir review of draft-petithuguenin-behave-turn-uris-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 00:24:37 -0000 Dear all, I have re-reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Draft-petithuguenin-behave-turn-uris-07 has addressed my review comments on= draft-petithuguenin-behave-turn-uris-06. Thank you for the effort from the= authors. Thank you, Tina From new-work-bounces@ietf.org Fri Sep 27 09:08:17 2013 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 42D3321E80FA; Fri, 27 Sep 2013 09:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1380298097; bh=IynmkXbmqZ0EzyBjvwYsKqpOp3vZLk6qWt5TMlDkpP0=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=eDY9Yw4qoUwi7AWKf++/Y72L1iPSa3AFIAqBt0fYt01jT1CwgxAzNweH4ut+3S/EL LE/qI8NrZs2tYR91D1luS+zUaVOlW4H+lpbN4Dc7yVnxcCFCcTAimGPiNV9vLOHiWl NcJ+GBqzYXthQiwv7g7IrL6I4jP6+yU8hSVrrwKc= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFF021F9C9A; Fri, 27 Sep 2013 09:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoS8Ckjk9dgD; Fri, 27 Sep 2013 09:08:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9132011E80D2; Fri, 27 Sep 2013 09:08:11 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130927160811.11230.25443.idtracker@ietfa.amsl.com> Date: Fri, 27 Sep 2013 09:08:11 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 27 Sep 2013 09:43:05 -0700 Subject: [secdir] [new-work] WG Review: INtermediary-safe SIP session ID (insipid) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 16:08:17 -0000 The INtermediary-safe SIP session ID (insipid) working group in the Real-time Applications and Infrastructure Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-10-07. INtermediary-safe SIP session ID (insipid) ------------------------------------------------ Current Status: Active WG Chairs: Gonzalo Salgueiro Keith Drage Assigned Area Director: Gonzalo Camarillo Mailing list Address: insipid@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/insipid Archive: http://www.ietf.org/mail-archive/web/insipid/ Charter: An end-to-end session identifier in SIP-based multimedia communication networks refers to the ability for endpoints, intermediate devices, and management and monitoring system to identify and correlate SIP messages and dialogs of the same higher-level end-to-end "communication session" across multiple SIP devices, hops, and administrative domains. Unfortunately, there are a number of factors that contribute to the fact that the current dialog identifiers defined in SIP are not suitable for end-to-end session identification. Perhaps the most important factor worth describing is that in real-world deployments of Back-to-Back User Agents (B2BUAs) devices like Session Border Controllers (SBC) often change the call identifiers (e.g., the From-tag and To-tag that are used in conjunction with the Call-ID header to make the dialog-id) as the session signaling passes through. An end-to-end session identifier should allow the possibility to identify the communication session from the point of origin, passing through any number of intermediaries, to the ultimate point of termination. It should have the same aim as the From-tag, To-tag and Call-ID conjunction, but should not be mangled by intermediaries. A SIP end-to-end session identifier has been considered as possible solution of different use cases like troubleshooting, billing, session recording, media and signaling correlation, and so forth. Some of these requirements come from other working groups within the RAI area (e.g., SIPRec). Moreover, other standards organizations have identified the need for SIP and H.323 to carry the same "session ID" value so that it is possible to identify a call end-to-end even when performing inter working between protocols. Troubleshooting SIP signalling end-to-end becomes impractical as networks grow and become interconnected, including connection via transit networks, because the path that SIP signalling will take between clients cannot be predicted and the signalling volume and geographical spread are too large. This group will focus on two documents: The first document will specify a SIP identifier that has the same aim as the From-tag, To-tag and Call-ID conjunction, but is less likely to be mangled by intermediaries. In doing this work, the group will pay attention to the privacy implications of a "session ID", for example considering the possibility to make it intractable for nodes to correlate "session IDs" generated by the same user for different sessions. The second document will define an indicator that can be added to the SIP protocol to indicate that signalling should be logged. The indicator will typically be applied as part of network testing controlled by the network operator and not used in regular client signalling. However, such marking can be carried end-to-end including the SIP terminals, even if a session originates and terminates in different networks. Milestones: Dec 2012 - Requirements and use cases for new identifier sent to IESG (as informational) Feb 2013 - Specification of the new identifier sent to the IESG (PS) _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From Tina.Tsou.Zouting@huawei.com Fri Sep 27 15:57:44 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E729221F9BF2; Fri, 27 Sep 2013 15:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.59 X-Spam-Level: X-Spam-Status: No, score=-5.59 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGTcfV7L7kUb; Fri, 27 Sep 2013 15:57:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C124621F9DED; Fri, 27 Sep 2013 15:57:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYI95421; Fri, 27 Sep 2013 22:57:34 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 27 Sep 2013 23:56:40 +0100 Received: from SJCEML401-HUB.china.huawei.com (10.212.94.42) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 27 Sep 2013 23:57:33 +0100 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.42]) by sjceml401-hub.china.huawei.com ([::1]) with mapi id 14.03.0146.000; Fri, 27 Sep 2013 15:57:27 -0700 From: Tina TSOU To: "draft-ietf-ecrit-unauthenticated-access@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: SecDir Review of draft-ietf-ecrit-unauthenticated-access-07 Thread-Index: Ac671O5/aaM/A3W3Ty2ARse4ihsI+g== Date: Fri, 27 Sep 2013 22:57:26 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.153] Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A8173B2256sjceml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [secdir] SecDir Review of draft-ietf-ecrit-unauthenticated-access-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 22:57:45 -0000 --_000_C0E0A32284495243BDE0AC8A066631A8173B2256sjceml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These 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. Draft-ietf-ecrit-unauthenticated-access-07 provides extensions to the emerg= ency services architecture described in other documents to allow emergency = services calling to proceed even when the caller is unauthenticated and una= uthorized. The draft is particularly relevant to mobile devices, where such= a situation is most likely to arise. It assumes separate entities provide = network access and process calls at the application level, and based on tha= t, deals with three cases, not necessarily mutually exclusive: -- no access authentication; -- no application service provider reachable; -- subscribed application service provider reachable but ordinary service denied because of zero credit balance or other reasons. Full understanding of this document required review of RFC 5069 (security r= equirements specifically for emergency call marking and mapping), RFC 6443,= the emergency calling framework, and RFC 6881, a BCP specifying requiremen= ts for various components of the emergency calling system beginning with th= e subscriber device. The draft states that it is forward-looking, and is input for other SDOs. O= ne example of this is the reliance on DHCP provisioning, which is at this p= oint little-implemented in cellular devices. General remark: the document is very heavy on abbreviations, which makes se= rious demands on the novice reader at some points. The terminology and abbr= eviations are introduced quite properly at the beginning of the document, b= ut the authors might still ease the reader's task by spelling out at least = the less-used abbreviations either whenever used (if only two or three time= s) or perhaps once per section. General assessment: The document is basically ready, but lacks a statement = of the specific points in RFCs 6443 and 6881 that need to be changed due to= lack of authentication or authorization. As a result, the NASP and NAA sec= tions are unmotivated. Editorial: Section 7 in a few places does not quite seem to say what I thin= k it means, hence the following suggestions: Suggestion, sec. 7, fourth para, first sentence: Currently: "We only illustrate a possible model." Suggested: "We illustrate just one possible model for obtaining the destina= tion addresses to which emergency callers should be restricted in the NAA c= ase." In the next sentence, missing some words: "... as well as the address of the LoST server itself." ^^^^^^^^^^^^^^ Suggestion, sec. 7, fifth para, first sentence: Currently: "For the ZBP case the additional aspect of fraud has to be consi= dered." Suggested: "The additional aspect of fraud also has to be considered for th= e ZBP case." Typos: Typo, sec. 5, first bullet: devices -> device Typo, sec. 7, second para, last sentence: lead -> led Typo, sec. 7, third para, fourth line: fraudulent -> fraudulently Thank you, Tina --_000_C0E0A32284495243BDE0AC8A066631A8173B2256sjceml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

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

 

Draft-ietf-ecrit-unauthenticated-access-07 provides = extensions to the emergency services architecture described in other docume= nts to allow emergency services calling to proceed even when the caller is = unauthenticated and unauthorized. The draft is particularly relevant to mobile devices, where such a situati= on is most likely to arise. It assumes separate entities provide network ac= cess and process calls at the application level, and based on that, deals w= ith three cases, not necessarily mutually exclusive:

   -- no access authentication;=

   -- no application service provider reac= hable;

   -- subscribed application service provi= der reachable but ordinary

      service denied becaus= e of zero credit balance or other reasons.

Full understanding of this document required review = of RFC 5069 (security requirements specifically for emergency call marking = and mapping), RFC 6443, the emergency calling framework, and RFC 6881, a BC= P specifying requirements for various components of the emergency calling system beginning with the subscriber d= evice.

 

The draft states that it is forward-looking, and is = input for other SDOs. One example of this is the reliance on DHCP provision= ing, which is at this point little-implemented in cellular devices.

 

General remark: the document is very heavy on abbrev= iations, which makes serious demands on the novice reader at some points. T= he terminology and abbreviations are introduced quite properly at the begin= ning of the document, but the authors might still ease the reader's task by spelling out at least the less-used = abbreviations either whenever used (if only two or three times) or perhaps = once per section.

 

General assessment: The document is basically ready,= but lacks a statement of the specific points in RFCs 6443 and 6881 that ne= ed to be changed due to lack of authentication or authorization. As a resul= t, the NASP and NAA sections are unmotivated.

 

Editorial: Section 7 in a few places does not quite = seem to say what I think it means, hence the following suggestions:

 

Suggestion, sec. 7, fourth para, first sentence:

Currently: "We only illustrate a possible model= ."

Suggested: "We illustrate just one possible mod= el for obtaining the destination addresses to which emergency callers shoul= d be restricted in the NAA case."

 

In the next sentence, missing some words: "... = as well

    as the address of the LoST server= itself."

       ^^^^^^^^^^^^^^<= o:p>

 

Suggestion, sec. 7, fifth para, first sentence:=

Currently: "For the ZBP case the additional asp= ect of fraud has to be considered."

Suggested: "The additional aspect of fraud also= has to be considered for the ZBP case."

 

 

Typos:

 

Typo, sec. 5, first bullet: devices -> device

 

Typo, sec. 7, second para, last sentence: lead ->= led

 

Typo, sec. 7, third para, fourth line: fraudulent -&= gt; fraudulently

 

Thank you,

Tina

 

--_000_C0E0A32284495243BDE0AC8A066631A8173B2256sjceml501mbschi_-- From kent@bbn.com Mon Sep 30 09:39:07 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DAA21F8B07; Mon, 30 Sep 2013 09:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-tMen3L0s5t; Mon, 30 Sep 2013 09:39:01 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9977C21F8E21; Mon, 30 Sep 2013 09:39:01 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:44650 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VQgUr-000FHa-6m; Mon, 30 Sep 2013 12:38:57 -0400 Message-ID: <5249A91F.6020003@bbn.com> Date: Mon, 30 Sep 2013 12:38:55 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: The IESG , "draft-ietf-sidr-bgpsec-threats-06.all@tools.ietf.org" , "" Subject: Re: [secdir] Secdir review of draft-ietf-sidr-bgpsec-threats-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 16:39:07 -0000 Joe, > Some issues: > > 1. I found it difficult to link the threats in section 3 to the attacks in section 4. This is more of a consistency of terminology issue and is probably just a nit. There is not 1-to-1 correspondence between threats and attacks. So, for each attacks in Section 4, there may be more than one threat that is motivated and capable of effecting the attack. > 2. The attacks in sections 4.1, 4.2, and 4.3 seem to be largely discounted as out of scope, yet they seem to impact the goals of PATHSEC. Is it assumed that there are countermeasures in place such as link protection between RGP peers? If other countermeasures besides PATHSEC are expected to be in place this should probably be mentioned in the security considerations. The text in 4.1, 4.2, and 4.3 does not say that those attacks are out of scope. In 4.1, there is little text because the attacks are not specific to the RPKI/PATHSEC context. Countermeasures are generic for IP and TCP layer attacks, as noted in the requirements doc. In 4.2 and 4.3 we give a number of examples of these classes of attacks, which is what this doc is intended to do. (Recall, it is not a requirements doc.) > 3. I found the argument against not including 'route leakage' a bit weak since the documents seems to be able to define what it means. Wouldn't 'route leakage' be a mechanism to realize one or more of the threats in section 3? There is not yet an accepted definition of route leak that represents a violation of BGP specs. The GROW WG is supposed to look into this issue. If it develops a suitable proposal, then IDR may elect to modify the BGP spec to address the concern. If IDR does so, SIDR's charter could be modified to develop countermeasures for the concern. But, for now, this is out of scope. So I disagree with the comment that the argument is weak. Also, your use of the term "threat" in the last sentence above is not consistent with the way the term is defined and used in Section 3; you seem to have switched "threat" and "attack" as well as section numbers. Steve