From kwiereng@cisco.com Mon Dec 2 02:32:47 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716751AE1CF; Mon, 2 Dec 2013 02:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LorLVEfPDls2; Mon, 2 Dec 2013 02:32:46 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCAE1AE10F; Mon, 2 Dec 2013 02:32:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1043; q=dns/txt; s=iport; t=1385980364; x=1387189964; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=gibKiDFcavtDKjo9FkHPb30HVgPIHC5QPPr77Wuwf8A=; b=L0LpjygxIVQI0HbWK6QZOOHYhYNO11hQ5i5d6vclR9FZl0+xufkQe5sL mLYHiX0LtJQ16dyGsRW6b4lrJoW9gSIWTDRXAA307vWe4wsenMYztfl/S sbd9k6hSyqmpuUKvDWcMbWUOM/f8+HDruIgnchihswW+iwCT1ft+axmpH g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAHhhnFKtJXG8/2dsb2JhbABZgwc4U7l5FnSCLDpRAT5CJwQBiBO/JheSL4ETA5gUkhODKYIq X-IronPort-AV: E=Sophos;i="4.93,810,1378857600"; d="scan'208";a="3592869" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-8.cisco.com with ESMTP; 02 Dec 2013 10:32:25 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB2AWPw5013227 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 10:32:25 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.149]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 04:32:25 -0600 From: "Klaas Wierenga (kwiereng)" To: "draft-ietf-httpbis-p4-conditional.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: draft-ietf-httpbis-p4-conditional-24 Thread-Index: AQHO70nKjm63YmI8kkuJgTcGop2QMA== Date: Mon, 2 Dec 2013 10:32:24 +0000 Message-ID: <48B2E229-DAF9-4FD5-BB42-3B9C55F995A3@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.103.112] Content-Type: text/plain; charset="us-ascii" Content-ID: <30E342E3E777464BA7D51EB10F58069D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] draft-ietf-httpbis-p4-conditional-24 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 10:32:47 -0000 Hi, 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 defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false. I had reviewed version 19 of this draft in the past and I am happy with the= changes since. I particularly appreciate the paragraph on privacy in the s= ecurity considerations. You might want to consider making that a separate s= ection since privacy and security are really not the same thing. Apart from= that I believe the document is in a good condition. Klaas= From adrian@olddog.co.uk Mon Dec 2 03:16:40 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1831AE368; Mon, 2 Dec 2013 03:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDr0aafZy-NJ; Mon, 2 Dec 2013 03:16:38 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 22DA51AE363; Mon, 2 Dec 2013 03:16:21 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB2BGI3T017754; Mon, 2 Dec 2013 11:16:18 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB2BGG9I017732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Dec 2013 11:16:17 GMT From: "Adrian Farrel" To: "'Charlie Kaufman'" References: <2b12ea7449014b53a4b4118929921b75@BL2PR03MB592.namprd03.prod.outlook.com> In-Reply-To: <2b12ea7449014b53a4b4118929921b75@BL2PR03MB592.namprd03.prod.outlook.com> Date: Mon, 2 Dec 2013 11:16:16 -0000 Message-ID: <0c0601ceef4f$ebe102d0$c3a30870$@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: AQIHav6dMGoNhrLf258GkpHEMqzPNpnPyaCQ Content-Language: en-gb Cc: draft-ietf-mpls-mldp-hsmp.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-mpls-hsmp-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 02 Dec 2013 11:16:40 -0000 Charlie, Thanks for the time and the nits. Work will be done. Adrian > -----Original Message----- > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Charlie Kaufman > Sent: 01 December 2013 07:11 > To: secdir@ietf.org; iesg@ietf.org; draft-ietf-mpls-mldp-hsmp.all@tools.ietf.org > Subject: [secdir] secdir review of draft-ietf-mpls-hsmp-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 document defines a new variation of MPLS for multipoint to multipoint > communication. The document does not state why anyone would prefer this > new variation over the existing one, though I can guess a few reasons. The new > variation is less efficient in that packets sent travel over many links twice instead > of once and packet delivery has longer latency in that most packets travel over > more links from their original source to ultimate destination. The two advantages > I can imagine are (1) in almost all cases, all packets will arrive at all destinations in > the same order (in the original protocol, packets from different sources could > arrive at different destinations in different orders); and (2) the root of the > multicast tree could filter messages - for example, to throttle the total volume of > messages from a single source. A third possible use that seems to be disavowed > by the document is to allow members of the multicast group to signal their status > only to the root node. It would be nice if the document was more explicit about > what this protocol was for, but it doesn't affect security considerations. > > The document correctly notes that there are no new security considerations > beyond those discussed in the protocol that this competes with. That protocol is > defined in RFC6388 and RFC6425. > > Nits: > > Last sentence of abstract reads "The communication among the leaf nodes are > not allowed." I believe the grammar is incorrect, but more importantly I believe it > should read "Direct communication among the leaf nodes is not allowed." > because communication among the leaf nodes is supported by this protocol with > all packets being relayed by the root node. > > Near the end of the introduction is the phrase "except that it follows the node of > reverse downstream path of the tree". I believe the word 'node' is incorrect > here, though I don't know what was intended. > > Page 11: "In some scenario," should be "In some scenarios," > > --Charlie From andrew.hutton@unify.com Mon Dec 2 05:54:16 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12921AE476; Mon, 2 Dec 2013 05:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LI9Tf3a4EPf; Mon, 2 Dec 2013 05:54:14 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 849DD1AE015; Mon, 2 Dec 2013 05:54:14 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 0BB6823F041C; Mon, 2 Dec 2013 14:54:12 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.126]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 14:54:11 +0100 From: "Hutton, Andrew" To: Derek Atkins Thread-Topic: sec-dir review of draft-ietf-siprec-architecture-08 Thread-Index: AQHO1wo8FpuNNNCQs06E2FZPbdmFCZpBHVIQ Date: Mon, 2 Dec 2013 13:54:11 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C67800@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF17BF527F@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF17C26825@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec-chairs@tools.ietf.org" , "secdir@ietf.org" , "krehor@cisco.com" , "iesg@ietf.org" , "leon.portman@gmail.com" , "rajnish.jain@outlook.com" Subject: Re: [secdir] sec-dir review of draft-ietf-siprec-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 13:54:17 -0000 I have updated the draft due to these comments and a couple of other minor = bug fixes discovered by the WG. See http://tools.ietf.org/html/draft-ietf-siprec-architecture-10 Hopefully this resolves the open issues and we can now progress this draft. Regards Andy > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: 01 November 2013 13:57 > To: Hutton, Andrew > Cc: Derek Atkins; iesg@ietf.org; secdir@ietf.org; siprec- > chairs@tools.ietf.org; krehor@cisco.com; rajnish.jain@outlook.com; > leon.portman@gmail.com > Subject: Re: sec-dir review of draft-ietf-siprec-architecture-08 >=20 > Hi, >=20 > "Hutton, Andrew" writes: >=20 > > Hi Derek, > > > > > > Would the following change in the security considerations section > > resolve your issue: > > > > > > "It is the responsibility of the SRS to protect the Replicated Media > > and Recording Metadata once it has been received and archived. The > > mechanism for protecting the storage and retrieval from the SRS is > out > > of scope of this work" > > > > To > > > > "It is the responsibility of the SRS to protect the Replicated Media > > and Recording Metadata once it has been received and archived. The > > stored content must be protected using a cipher at least as strong > (or > > stronger) than the original content however the mechanism for > > protecting the storage and retrieval from the SRS is out of scope of > > this work" >=20 > This is a good start. Could you also add something like: >=20 > The keys used to store the data must also be securely maintained by > the SRS and should only be released, securely, to authorized parties. > How to secure these keys, properly authorize a receiving party, or > securely distribute the keying material is out of scope of this work >=20 > > Regards > > Andy >=20 > -derek >=20 > >> -----Original Message----- > >> From: Derek Atkins [mailto:derek@ihtfp.com] > >> Sent: 24 October 2013 15:53 > >> To: Hutton, Andrew > >> Cc: Derek Atkins; iesg@ietf.org; secdir@ietf.org; siprec- > >> chairs@tools.ietf.org; krehor@cisco.com; rajnish.jain@outlook.com; > >> leon.portman@gmail.com > >> Subject: Re: sec-dir review of draft-ietf-siprec-architecture-08 > >> > >> Hi Andrew, > >> > >> Sorry for the delay in responding. > >> > >> I personally feel that there is a big difference between the > >> interactive, real-time SIP components versus a service that is > >> specifically designed to record and replay content later. The key > >> management of the real-time components is all immediate, there is no > >> storage required, once the keys get to the endpoints you're done and > >> all > >> you do is transmit encrypted content. > >> > >> However a storage system has significantly different requirements. > It > >> has to store the keys that protect the content, and it must store > those > >> keys securely. It then has to be able to securely distribute those > >> keys > >> only to authorized receipients. > >> > >> So yes, I think it is important to talk about at least the > requirements > >> for what the recording agent MUST do, even if you don't necessarily > >> specify HOW the agent must do it. E.g. I think it's okay to say > >> something like "the stored content must be protected using a cipher > at > >> least as strong (or stronger) than the original content" -- i.e., > you > >> don't need to specify "you MUST use AES-256". Yet I still think you > >> need to talk about the key management requirements of the storage > (and > >> more importantly retrieval). > >> > >> Thanks, > >> > >> -derek > >> > >> "Hutton, Andrew" writes: > >> > >> > Hi Derek, > >> > > >> > Thanks for your comment and sorry for taking a while to get back > to > >> you. > >> > > >> > The security considerations section contains the following text: > >> > > >> > " It is the responsibility of the Session Recording Server to > protect > >> > the Replicated Media and Recording Metadata once it has been > >> received > >> > and archived. The mechanism for protecting the storage and > >> retrieval > >> > from the SRS is out of scope of this work." > >> > > >> > > >> > Personally I think this is reasonable as we never say anything in > SIP > >> > related specifications what a UA should do with the media once it > has > >> > been received and this work is all about delivering the media and > >> > related metadata to the recording system not what it does with it > >> > afterwards. > >> > > >> > Is it really necessary to go any further than this? > >> > > >> > Regards > >> > Andy (SIPREC Co-Chair). > >> > > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From: Derek Atkins [mailto:derek@ihtfp.com] > >> >> Sent: 01 October 2013 16:34 > >> >> To: iesg@ietf.org; secdir@ietf.org > >> >> Cc: siprec-chairs@tools.ietf.org; krehor@cisco.com; > >> >> rajnish.jain@outlook.com; leon.portman@gmail.com; Hutton, Andrew > >> >> Subject: sec-dir review of draft-ietf-siprec-architecture-08 > >> >> > >> >> 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. > >> >> > >> >> Session recording is a critical requirement in many > >> communications > >> >> environments such as call centers and financial trading. In > some > >> of > >> >> these environments, all calls must be recorded for regulatory, > >> >> compliance, and consumer protection reasons. Recording of a > >> session > >> >> is typically performed by sending a copy of a media stream to > a > >> >> recording device. This document describes architectures for > >> >> deploying session recording solutions in an environment which > is > >> >> based on the Session Initiation Protocol (SIP). > >> >> > >> >> Retrieving recorded media is a potential Key Management problem > >> which > >> >> this document completely ignores (and even claims is out of > scope). > >> >> The key used to encrypt the recorded media (whether or not the > media > >> >> is re-encrypted) must be stored and retrieved as part of the > media > >> >> retrieval. How this important data is stored and retrieved is > left > >> >> out, leaving an implementation with no guidance on how to protect > >> that > >> >> valuable asset. In fact the document completely elides the > question > >> >> of how a retriever obtains the data encryption key. Even if it's > >> just > >> >> additional guidance the Security Considerations should at least > >> >> explain the problem even if it doesn't provide a solution. > >> >> > >> >> -derek > >> >> > >> >> -- > >> >> Derek Atkins 617-623-3745 > >> >> derek@ihtfp.com www.ihtfp.com > >> >> Computer and Internet Security Consultant > >> > > >> > > >> > >> -- > >> Derek Atkins 617-623-3745 > >> derek@ihtfp.com www.ihtfp.com > >> Computer and Internet Security Consultant > > > > >=20 > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From carl@redhoundsoftware.com Mon Dec 2 06:09:06 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F34A1AE42B for ; Mon, 2 Dec 2013 06:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJVd-dpl1MZK for ; Mon, 2 Dec 2013 06:09:05 -0800 (PST) Received: from mail-yh0-f52.google.com (mail-yh0-f52.google.com [209.85.213.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECCD1AE22A for ; Mon, 2 Dec 2013 06:09:04 -0800 (PST) Received: by mail-yh0-f52.google.com with SMTP id i72so8779139yha.39 for ; Mon, 02 Dec 2013 06:09:02 -0800 (PST) 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=9Ximp0YoezIVXx1YjBGjMF0M290fNGVPvbywAbIGpkc=; b=F3ntiVdyz/MrRxHL3MDlAe88KnDVOTUsMtGfX3aAqNaP6y0DrIPHPd0o5pnOsCI078 apDMwXsYoCtsvO0U/kMMx4YF+xpjGlFC7XEx+NW98XAPvw27ZPN9T8YOZ++pzAlJvuaB YKp7/L2OnzS3gApsE4qc5WmP0DIt7C7tGYBrelXrdBzqQKBD+6I2uddOfR0i2qLWTS7h P02Kh1IJxTFk119fxo7j5hyRScIeT9CKIZQNm4F2LT6TDfR7NJAQ/tZYtguj4TEjmwlv xLvJ0+AM2kQpff2qRxEDpUcyw1cWGUUaYCTs7vCfYLZjN5ZTOodRmhMNOlZCstZAUmJM +JYQ== X-Gm-Message-State: ALoCoQl6sY1hkhact6Rpjl3rB5qm6PeJMLIHtvOInzVLQHP6E/ZdyHH2Y29MBxtiNvK4YTL5lAKm X-Received: by 10.236.54.38 with SMTP id h26mr36260yhc.160.1385993342508; Mon, 02 Dec 2013 06:09:02 -0800 (PST) Received: from [192.168.2.9] (pool-173-79-121-197.washdc.fios.verizon.net. [173.79.121.197]) by mx.google.com with ESMTPSA id m29sm123955387yho.14.2013.12.02.06.08.59 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 02 Dec 2013 06:09:02 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Mon, 02 Dec 2013 09:08:57 -0500 From: Carl Wallace To: "secdir@ietf.org" , "iesg@ietf.org" , Message-ID: Thread-Topic: secdir review of draft-ietf-mmusic-sdp-g723-g729-04 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [secdir] secdir review of draft-ietf-mmusic-sdp-g723-g729-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 14:09:06 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document updates RFC 4856 to clarify the behavior when the annexa or annexb parameters to not match in the SDP offer and answer. The document asserts no security considerations beyond those described in RFC 4856 and this seems sufficient. From lizho.jin@gmail.com Sun Dec 1 19:00:15 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A33F1AE31C; Sun, 1 Dec 2013 19:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.45 X-Spam-Level: X-Spam-Status: No, score=0.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y72Oa6VmmXTa; Sun, 1 Dec 2013 19:00:13 -0800 (PST) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2671AE32E; Sun, 1 Dec 2013 19:00:13 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id uo5so17972858pbc.29 for ; Sun, 01 Dec 2013 19:00:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=F2Wu2eSNWgW5eMig8+rvbnkfJb96mfyST6sHnwqTyLk=; b=R+PHo5eLf55r1prHh5qPnOZ0ztVm8YkqxJZQr60IYx/C7ABvWZcwHntXJDpDIIhCt9 DMJfwwBQh5vL7E1XG64CyoA0VIIgTC4J7sNrAjr9rFOnlrf9PQKYYNtEHU3o5kI9DkJM +p0qh4gtjxXStBGo8aYQQ5Q6FK34HXSTGqTTTYKRLb7HCSWAhPjfv4hh1fEJDXuOFp01 HoFS5NgxOEVEJkdBc3spKur3Me560W2MtCUv+0UKL+OqpCfHXFHc4JFwYdAR5tHT/Rxl HDkvZdiRh7loMWtEx0ShgffsUGUw7GwXl/xVQWv254GB+Ma+NAxXmku0FSgLgDsDvMzA XE6A== X-Received: by 10.68.196.69 with SMTP id ik5mr28820154pbc.132.1385953210997; Sun, 01 Dec 2013 19:00:10 -0800 (PST) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id uf2sm118650051pbc.28.2013.12.01.19.00.08 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 01 Dec 2013 19:00:10 -0800 (PST) From: "Lizhong Jin" To: "'Charlie Kaufman'" , , , References: <2b12ea7449014b53a4b4118929921b75@BL2PR03MB592.namprd03.prod.outlook.com> In-Reply-To: <2b12ea7449014b53a4b4118929921b75@BL2PR03MB592.namprd03.prod.outlook.com> Date: Mon, 2 Dec 2013 11:00:05 +0800 Message-ID: <022201ceef0a$9cc3c470$d64b4d50$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIHav6dMGoNhrLf258GkpHEMqzPNpnPNLAw Content-Language: zh-cn X-Mailman-Approved-At: Mon, 02 Dec 2013 08:00:47 -0800 Subject: Re: [secdir] secdir review of draft-ietf-mpls-hsmp-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 03:00:15 -0000 Hi Charlie, Thank you for the review. See inline below. Regards Lizhong -----Original Message----- From: Charlie Kaufman [mailto:charliek@microsoft.com]=20 Sent: 2013=C4=EA12=D4=C21=C8=D5 15:11 To: secdir@ietf.org; iesg@ietf.org; draft-ietf-mpls-mldp-hsmp.all@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-mpls-hsmp-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 document defines a new variation of MPLS for multipoint to = multipoint communication. The document does not state why anyone would prefer this = new variation over the existing one, though I can guess a few reasons. The = new variation is less efficient in that packets sent travel over many links twice instead of once and packet delivery has longer latency in that = most packets travel over more links from their original source to ultimate destination. The two advantages I can imagine are (1) in almost all = cases, all packets will arrive at all destinations in the same order (in the original protocol, packets from different sources could arrive at = different destinations in different orders); and (2) the root of the multicast = tree could filter messages - for example, to throttle the total volume of messages from a single source. A third possible use that seems to be disavowed by the document is to allow members of the multicast group to signal their status only to the root node. It would be nice if the = document was more explicit about what this protocol was for, but it doesn't = affect security considerations. [Lizhong] The main function HSMP provided is the communication between = leaf and root in a hub & spoke network. If leaf to leaf communication is required, I don't think HSMP is a suitable candidate. Applications which require P2MP connection from root to every leaf and P2P connection from every leaf to root could use HSMP LSP. During the AD review process, = after discussed with Adrian, in this 04 version, we decided to remove the "Applications" section in 03 version (http://www.ietf.org/mail-archive/web/mpls/current/msg10959.html). The document correctly notes that there are no new security = considerations beyond those discussed in the protocol that this competes with. That protocol is defined in RFC6388 and RFC6425. Nits: Last sentence of abstract reads "The communication among the leaf nodes = are not allowed." I believe the grammar is incorrect, but more importantly I believe it should read "Direct communication among the leaf nodes is not allowed." because communication among the leaf nodes is supported by = this protocol with all packets being relayed by the root node. [Lizhong] accepted for the new text. But we do not recommend for the = root node to do relay. If leaf to leaf communication is required, MP2MP LSP (RFC6388) is recommended. Near the end of the introduction is the phrase "except that it follows = the node of reverse downstream path of the tree". I believe the word 'node' = is incorrect here, though I don't know what was intended. [Lizhong] to make it more clearly, change to "except that it follows the reverse direction of the downstream LSP". Page 11: "In some scenario," should be "In some scenarios," [Lizhong] accepted. --Charlie From housley@vigilsec.com Mon Dec 2 14:15:10 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D411ADFA2; Mon, 2 Dec 2013 14:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJbPw_9C5zis; Mon, 2 Dec 2013 14:15:08 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1805E1ADF9A; Mon, 2 Dec 2013 14:15:08 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 601F7F2409D; Mon, 2 Dec 2013 17:14:55 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id hGnvqncz0g-l; Mon, 2 Dec 2013 17:14:33 -0500 (EST) Received: from [192.168.2.110] (pool-96-241-225-66.washdc.fios.verizon.net [96.241.225.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 26BBFF24097; Mon, 2 Dec 2013 17:14:33 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-46--306630614 From: Russ Housley In-Reply-To: Date: Mon, 2 Dec 2013 17:14:22 -0500 Message-Id: References: To: Radia Perlman X-Mailer: Apple Mail (2.1085) Cc: The IESG , draft-housley-ct-keypackage-receipt-n-error.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-housley-ct-keypackage-receipt-n-error-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 22:15:10 -0000 --Apple-Mail-46--306630614 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Radia: Thanks for the very insightful review. Please see my comments below. > 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 >=20 > This document defines a syntax for two Cryptographic Message Syntax = (CMS) content types that can be used in responses to messages containing = key packages. One is for acknowledging receipt and the other is for = reporting errors. The exact syntax is unimportant to security and the = message purpose seems sensible and non-controversial. > =20 > A few thoughts (mostly on procedural rather than technical issues): > =20 > In addition to defining the key-package-receipt and key-package-error = content types, this document defines a KeyPkgIdentifierAndReceiptReq = attribute. It wasn=92t clear (at least to me) whether this document was = also defining this attribute or whether this information was included in = this document for the purpose of providing context. The KeyPkgIdentifierAndReceiptReq attribute is included in a key package = to request a receipt for that package. > The document defines a long list of error codes with the comment = =93Expect additional error codes=94 without specifying a mechanism for = additional error codes to be defined. It also says that there are no = IANA considerations, but I would assume that IANA would operate the = registry for things like the error codes listed here. If not IANA, where = would the definitive registry be? I do not think that an IANA registry is the way to go here. An = additional specification is needed to publish the ASN.1 module with the = additional values. The ASN.1 module in this specification includes: ... -- Expect additional error codes -- } so that receipt of a value in this list does not cause a decode error. > The KeyPkgReceiptReq includes a specification as to where to send the = receipts, and that specification is a sequence of distinguished names. = There is no specified limit on the number of distinguished names and no = stated requirement that the names have any relation to the sender of the = Key Package. This potentially represents a denial of service = amplification engine. Good point. I will add a sentence to the Security Considerations to = warn implementers. > There is no indication that the key package identifier be unguessable = or tied cryptographically to the key package contents. As a result, = there is the potential that an attacker could stop delivery of a key = package and send his own substitute key package with the same = identifier. This would result in the recipient acknowledging a key = package that he did not in fact receive. This could potentially confuse = the sender about the state of the exchange. This is a very good point. In S/MIME, the receipt includes the = signature of the signer to avoid this concern. In that environment, a = mail list agent might add a signature, but the original signature remain = in place. In this situation, there are senders, intermediaries, and recipients. = An intermediary might appear to be the signer to some recipients. So, = the S/MIME approach cannot be used directly. > minor typo? The last line of page 5 says =93which receivers of the key = package are expected to return receipts=94. I believe that should read = =93which receivers of the key package are requested to return receipts=94.= This will be corrected in -07. Russ --Apple-Mail-46--306630614 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

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.

<= /u> 

This document defines a syntax for two = Cryptographic Message Syntax (CMS) content types that can be used in = responses to messages containing key packages. One is for acknowledging = receipt and the other is for reporting errors. The exact syntax is = unimportant to security and the message purpose seems sensible and = non-controversial.
 
A = few thoughts (mostly on procedural rather than technical = issues):
 
... -- Expect additional error = codes -- }

so that receipt of a value = in this list does not cause a decode = error.


The KeyPkgReceiptReq = includes a specification as to where to send the receipts, and that = specification is a sequence of distinguished names. There is no = specified limit on the number of distinguished names and no stated = requirement that the names have any relation to the sender of the Key = Package. This potentially represents a denial of service amplification = engine.

Good point.  I will = add a sentence to the Security Considerations to warn = implementers.

There is no indication = that the key package identifier be unguessable or tied cryptographically = to the key package contents. As a result, there is the potential that an = attacker could stop delivery of a key package and send his own = substitute key package with the same identifier. This would result in = the recipient acknowledging a key package that he did not in fact = receive. This could potentially confuse the sender about the state of = the exchange.

This is a very good = point.  In S/MIME, the receipt includes the signature of the signer = to avoid this concern.  In that environment, a mail list agent = might add a signature, but the original signature remain in = place.

In this situation, there are senders, = intermediaries, and recipients.  An intermediary might appear to be = the signer to some recipients.  So, the S/MIME approach cannot be = used directly.

minor typo? The last line of page 5 says =93which = receivers of the key package are expected to return receipts=94. I = believe that should read =93which receivers of the key package are = requested to return = receipts=94.

This will be = corrected in = -07.

Russ

= --Apple-Mail-46--306630614-- From d3e3e3@gmail.com Mon Dec 2 14:32:04 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937DF1ADED9; Mon, 2 Dec 2013 14:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFFFPpoYb3mK; Mon, 2 Dec 2013 14:32:03 -0800 (PST) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 43E3B1ADBCD; Mon, 2 Dec 2013 14:32:03 -0800 (PST) Received: by mail-oa0-f46.google.com with SMTP id o6so13951664oag.19 for ; Mon, 02 Dec 2013 14:32:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=YfQLvNKqJuf9FI4auSwVgPoBgD34QFUtvL10I5Qty4U=; b=Wk6eYzxyJZzRKIabUZgD6kaEjAvRhUk54sXc2OqjIzSleScLHR7MjWGLfBPkC9b7l1 fekIa484XjedSZ8je2ATuD9SBBA75/oSRuCOI48Nw0s72Dmzu8bszYbMk0Ch+hHEHaiA CN34pqeUJx7/BTt3+TWCjmvUkheBEkVvQeAF6UuLFcTwSr9I5Jh8HlxkZ8Vdzdx5T6VJ eBd66aXEnrPvQ63OtlFAt2/5hlMy39y8ZI9ivYy9EZRaVgzP67R+OfrOFiTQaJSvEzOw mLLzshsR5pfwZBskyagIAzYO6loyfADKM5Hc8OWinRS9oMQOp6bCNnT4CIooXCNQDu+t VA5g== X-Received: by 10.182.142.229 with SMTP id rz5mr56659364obb.12.1386023519904; Mon, 02 Dec 2013 14:31:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.33.102 with HTTP; Mon, 2 Dec 2013 14:31:39 -0800 (PST) From: Donald Eastlake Date: Mon, 2 Dec 2013 17:31:39 -0500 Message-ID: To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-soc-load-control-event-package.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] SECDIR review of draft-ietf-soc-load-control-event-package-11.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 22:32:04 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This draft provides SIP capabilities (a load control event package) for filtering calls with the intent of better handling overload conditions. As you might expect for an extension to an existing protocol, there are many references to existing SIP RFCs. The Security Considerations Section appears to be adequate. It references RFCs 6665 and other sections of the draft and seems to summarize relevant threats. Minor points: The introductions (Section 1) give examples of anticipatable and unanticipatable causes of overload. I find it curious that denial of service attacks are not listed as a possible cause of unanticipated overload. In Section 10, in answer to REQ 17, there is a reference to Section 10 that, I believe, should be to Section 11. Editorial: Section 4 begins with what is said to be a list of requirements. And I think almost all of them are. But the first item is just not worded as a requirement. It says "... we focus ...". To be a requirement on the solution it should talk about the solution, not the authors. I think, it should be more like "For simplicity, the solution should focus on a method of controlling SIP load, rather than a generic application layer mechanism." Misc: The document contains lots of XML that I did not run through any formal syntax check. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From jhutz@cmu.edu Mon Dec 2 15:26:03 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53771ADF46; Mon, 2 Dec 2013 15:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2u-C9lHo5My; Mon, 2 Dec 2013 15:26:02 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 170181ADBCD; Mon, 2 Dec 2013 15:26:01 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id rB2NPveK018390 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 2 Dec 2013 18:25:57 -0500 (EST) Message-ID: <1386026757.9407.135.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Russ Housley Date: Mon, 02 Dec 2013 18:25:57 -0500 In-Reply-To: <22319_1386022511_rB2MFAWd022920_F81277D3-5F3B-4DEA-94B6-03FA65018CC4@vigilsec.com> References: <22319_1386022511_rB2MFAWd022920_F81277D3-5F3B-4DEA-94B6-03FA65018CC4@vigilsec.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 8bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: The IESG , "secdir@ietf.org" , draft-housley-ct-keypackage-receipt-n-error.all@tools.ietf.org, jhutz@cmu.edu Subject: Re: [secdir] Secdir review of draft-housley-ct-keypackage-receipt-n-error-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 23:26:04 -0000 On Mon, 2013-12-02 at 17:14 -0500, Russ Housley wrote: > > The document defines a long list of error codes with the comment “Expect additional error codes” without specifying a mechanism for additional error codes to be defined. It also says that there are no IANA considerations, but I would assume that IANA would operate the registry for things like the error codes listed here. If not IANA, where would the definitive registry be? > > I do not think that an IANA registry is the way to go here. An > additional specification is needed to publish the ASN.1 module with the > additional values. The ASN.1 module in this specification includes: > > ... -- Expect additional error codes -- } > > so that receipt of a value in this list does not cause a decode error. So, the key point here is that defining more error codes requires publishing a new version of the module, which is basically a linear progression -- each new version will necessarily incorporate all codes defined in previous versions, and there is no opportunity to "plug in" additional error codes in specifications that merely extend this one, rather than revising it. I think that's fine, provided there is a way to define and transmit additional error codes for unanticipated uses, site or vendor use, and so on. In this case, that comes from the other branch of ErrorCodeChoice, which allows any OID to be used as an error code. -- Jeff From clonvick@cisco.com Mon Dec 2 16:06:56 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72CE1ADFAA; Mon, 2 Dec 2013 16:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6RQcQQCEZIr; Mon, 2 Dec 2013 16:06:55 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 005BE1ADF9A; Mon, 2 Dec 2013 16:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=918; q=dns/txt; s=iport; t=1386029213; x=1387238813; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=MrK+y7lQ+yxhzwwMG16m6/FNmxyuhfXBxZ71XfBY2OI=; b=COZbs92iSmv0cFnbwTjfyQ6TK6p7gDkxI9gsOh1c3J2rryktGjhf9rwV So9UqG1lgMnIxMnBzint5qQKENC8EnXXIi2n277alOF1zxSz01lHAtqqv bk4x9xSeyQBEQMEsOdzWzJzD8Y8uDie1QQtLEFdOJn9DF2sIVTAv1RdLW k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAG8gnVKtJV2c/2dsb2JhbABZgweBC7hngScWdIInAQQ6UQEqFEImAQQBGod5wGUXjleDWIETA6ongymCKg X-IronPort-AV: E=Sophos;i="4.93,813,1378857600"; d="scan'208";a="3806874" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 03 Dec 2013 00:06:45 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB306jkv027439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 00:06:45 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.52]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 18:06:44 -0600 From: "Chris Lonvick (clonvick)" To: "draft-ietf-mmusic-rfc2326bis@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: secdir review of draft-ietf-mmusic-rfc2326bis-38 Thread-Index: Ac7vu4bQ+AfyoCPZRXihVXkn/C0tyQ== Date: Tue, 3 Dec 2013 00:06:43 +0000 Message-ID: <9BB92CB59918E1418A06FD4E3269FABE2AB64C64@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.201.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] secdir review of draft-ietf-mmusic-rfc2326bis-38 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 00:06:56 -0000 Hi,=0A= =0A= 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= =0A= This is a re-review as I initially reviewed version -35. I noted there tha= t this is a very long document and I was only able to review certain sectio= ns of that document. The subsequent revisions have not shortened this docu= ment any. Rather than attempt a new review, I checked the diffs from the v= ersion that I had previously reviewed up to this version.=0A= =0A= Again, I find the document to be very comprehensive and well written. I ca= n find no apparent security issues with this document.=0A= =0A= Best regards,=0A= Chris= From jsalowey@cisco.com Mon Dec 2 17:07:46 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0540A1AE004; Mon, 2 Dec 2013 17:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJeebK20FQbu; Mon, 2 Dec 2013 17:07:44 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 71F471ADFEF; Mon, 2 Dec 2013 17:07:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1565; q=dns/txt; s=iport; t=1386032862; x=1387242462; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=/nEH2JHa+wzVp3ozVbx5lVgJprJEPrHYe56JvhFlqMk=; b=kGM0+1F0wlaI2BBSjTp/kGjpoXT+zfRsM1uyNuChJpiCB/ILPBvYGVGA YmZLlhbYg66UFhTG53w59dFk4rQWgEOowUgxOulUXSb+BpXTSWi3K8nEr fea7D7ZNuoIZTzfJDWHyL73ct4zJbnIExvVDNZZesEXWcZUrS30lm4+TN Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEkunVKtJV2b/2dsb2JhbABQCYMHgQu6DRZ0giw6UQE+QicEAYgTwG8Xji2EAoETA5gUkhODKYIq X-IronPort-AV: E=Sophos;i="4.93,813,1378857600"; d="scan'208";a="3815312" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 03 Dec 2013 01:07:41 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB317fHW012286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 01:07:41 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 19:07:41 -0600 From: "Joseph Salowey (jsalowey)" To: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" , "" , The IESG Thread-Topic: Secdir review of draft-ietf-clue-telepresence-requirements-06 Thread-Index: AQHO78QQ0QnnZ7W5jU6TXQG+ShQBvw== Date: Tue, 3 Dec 2013 01:07:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.94.42] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-clue-telepresence-requirements-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 01:07:46 -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 draft is ready with some minor issues. =20 The draft discusses requirements for multi-stream telepresence. I don't k= now much about telepresence, but the draft seems straight forward. It does= include a single requirement about security and it does have a security co= nsiderations section. Although, I might like a bit more description about= what "secure exchange" means it think it is probably sufficient. The typ= e of information that might be useful is what type of attacks or threats is= of concern? For example, does the information need to be secured to discl= osure or modification by intermediaries or does have to allow modification = by intermediaries.=20 The one other question is whether the information about media captures has = any privacy considerations. For example is there geo-location or identity= information exchanged? Are there any long-term identifiers used? If ther= e is something that we know is going to be exchanged that is sensitive then= it would probably be worth including in the requirements. It didn't seem t= hat this type of data was required so this is probably more of a considerat= ion for the protocol spec. =20 Cheers, Joe From bew@cisco.com Tue Dec 3 18:32:03 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499151ADF96; Tue, 3 Dec 2013 18:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIaADrq7ox1m; Tue, 3 Dec 2013 18:32:01 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id E547D1ADF70; Tue, 3 Dec 2013 18:32:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2276; q=dns/txt; s=iport; t=1386124318; x=1387333918; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=syaf5UXX3slxS/+U/RNm+hsh58P3oQ3sDFyLzq8o+dk=; b=H4eQbjbLvvep1LcGz7tRoTQSqU7+Hf3hqlX3BnFCCxGAe466k2nGWq/C AjcgDjcgIajwU9e2NSaB0wOfKdW3gQtYrjsFW4c4eGzrNez/XDJv+g/cB 4z4qpfeG9ABQUTldubtNvrI1i3Nn/9RM8/dJa9eTj76k20B7baVtixiW+ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAAKTnlKrRDoI/2dsb2JhbABQCoMHuX6BIBZ0gmY/gT4BiBLBPReOIlyDJ4ETA4lCjlKGRYtOg0ob X-IronPort-AV: E=Sophos;i="4.93,821,1378857600"; d="scan'208";a="99390912" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 04 Dec 2013 02:31:58 +0000 Received: from [10.154.161.34] ([10.154.161.34]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB42VsIr005899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Dec 2013 02:31:56 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Dec 2013 18:31:54 -0800 Message-Id: <8BA650DC-B09E-48D3-852A-129E4592E2B5@cisco.com> To: "" , The IESG Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Cc: draft-ietf-ospf-rfc6506bis.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-ospf-rfc6506bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 02:32:03 -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 replaces (obsoletes) RFC 6506, which defines an = Authentication Trailer for OSPFv3. It makes modest changes to the = original specification, apparently as a result of deployment experience. = It includes a positive security improvement in requiring that expired = keys no longer be used rather than recommending that the expired key be = used indefinitely. The specification is generally ready to publish. I would suggest one rewording. The Introduction of RFC 6505 was = published with the following justification as to why ESP sometimes = cannot be used, and this was not changed in this draft: Since there is no deterministic way to differentiate between encrypted and unencrypted ESP packets by simply examining the packet, it could be difficult for some implementations to prioritize certain OSPFv3 packet types, e.g., Hello packets, over the other types. But now RFC 5879 ("Heuristics for Detecting ESP-NULL Packets") has been = published, which does describe some techniques to deterministically = detect an unencrypted ESP packet. It may be still be difficult to = prioritize certain OSPFv3 packets, but the justification is no longer = precisely accurate. I would suggest something like the following = rewording: Implementations desiring to prioritize certain OSPFv3 packet types,=20= e.g., Hello packets, over the other types, often perform the=20 prioritization prior to decryption. Parsing ESP packets is = problematic=20 when the prioritization code does not know whether the ESP packets=20 include an encryption algorithm, or are instead ESP-NULL packets = [RFC2410].=20 Techniques exist to identify ESP packets using ESP-NULL packets=20 [RFC5879], which would allow these packets to be examined and=20 prioritized. However, the techniques may not be practically applied=20= within the prioritization code. =20 Brian= From manav.bhatia@alcatel-lucent.com Wed Dec 4 08:29:28 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D367D1AE078; Wed, 4 Dec 2013 08:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJn7aeLL8UU8; Wed, 4 Dec 2013 08:29:26 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id C1CDE1AE2B9; Wed, 4 Dec 2013 08:29:26 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id rB4GTLvH011265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Dec 2013 10:29:22 -0600 (CST) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id rB4GTLgC028447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 11:29:21 -0500 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 4 Dec 2013 11:29:21 -0500 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.101]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Thu, 5 Dec 2013 00:29:18 +0800 From: "Bhatia, Manav (Manav)" To: Brian Weis , "" , "The IESG" Thread-Topic: Secdir review of draft-ietf-ospf-rfc6506bis-03 Thread-Index: AQHO8JlV9WFla24GnUezZsX6mO0MTppEKSUA Date: Wed, 4 Dec 2013 16:29:17 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E5265AF@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <8BA650DC-B09E-48D3-852A-129E4592E2B5@cisco.com> In-Reply-To: <8BA650DC-B09E-48D3-852A-129E4592E2B5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "draft-ietf-ospf-rfc6506bis.all@tools.ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ospf-rfc6506bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 16:29:29 -0000 Hi Brian, Thanks for the review. I have a comment inline. >=20 > But now RFC 5879 ("Heuristics for Detecting ESP-NULL Packets") has been > published, which does describe some techniques to deterministically > detect an unencrypted ESP packet. It may be still be difficult to > prioritize certain OSPFv3 packets, but the justification is no longer > precisely accurate. I would suggest something like the following > rewording: The justification still holds good as I don't think we will ever use heuris= tics for detecting ESP-NULL control packets that need to be consumed. Its afaik primarily meant for firewalls that want to deep inspect packets. = Obviously, there is nothing there in the standard that precludes it from be= ing implemented on router's CPU path, but I doubt if we will ever go down t= hat path. If this is really required on the routers, then WESP (RFC 5840) w= ill probably be the path to go down on -- but that would require protocol e= xtensions.=20 Cheers, Manav >=20 > Implementations desiring to prioritize certain OSPFv3 packet types, > e.g., Hello packets, over the other types, often perform the > prioritization prior to decryption. Parsing ESP packets is > problematic > when the prioritization code does not know whether the ESP packets > include an encryption algorithm, or are instead ESP-NULL packets > [RFC2410]. > Techniques exist to identify ESP packets using ESP-NULL packets > [RFC5879], which would allow these packets to be examined and > prioritized. However, the techniques may not be practically applied > within the prioritization code. >=20 > Brian From acee.lindem@ericsson.com Wed Dec 4 10:22:37 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F801AE2EA; Wed, 4 Dec 2013 10:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEbPI6c_cMqp; Wed, 4 Dec 2013 10:22:35 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 042711AE19C; Wed, 4 Dec 2013 10:22:34 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-95-529f72e598aa Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 39.2D.23183.6E27F925; Wed, 4 Dec 2013 19:22:30 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0347.000; Wed, 4 Dec 2013 13:22:31 -0500 From: Acee Lindem To: "Bhatia, Manav (Manav)" , Brian Weis , "" , The IESG Thread-Topic: Secdir review of draft-ietf-ospf-rfc6506bis-03 Thread-Index: AQHO8JlKwxs29bLmCk2zHqSVplJyjJpEjpKA//+ZhAA= Date: Wed, 4 Dec 2013 18:22:30 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470310EECD@eusaamb101.ericsson.se> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E5265AF@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-ID: <62AD87CD5BCB7A4A920549C64461B949@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLonXPdZ0fwgg74JkhZ9bxtZLZbM6Waz mPFnIrPFnHv3WC0+LHzI4sDq0fpsL6vHlN8bWT2WLPnJ5PHl8me2AJYoLpuU1JzMstQifbsE rowHs+4yFczmrzh6fjZzA+Nsni5GTg4JAROJVRMWMEPYYhIX7q1n62Lk4hASOMIocXXBTWYI ZxmjxIMZv9lBqtgEdCSeP/oHlhARmMcocab3DRtIglkgVeL43SZWEFtYwFri4e6TYA0iAjYS Z35sZISwrSS2LP8KFmcRUJHYtfc4C4jNK+Ar8bP5IFicUyBWYsK+82AnMQKd9P3UGiaI+eIS t57MZ4I4VUBiyZ7zUGeLSrx8/A9sr6iAnkT3rOWsEHFlie9zHrFA9OpILNj9CepOa4mJc2dA xbUlli18zQxxg6DEyZlPWCYwis9Csm4WkvZZSNpnIWmfhaR9ASPrKkaO0uLUstx0I4NNjMBY PCbBpruDcc9Ly0OM0hwsSuK8X946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgtH5fbLaB wdT/VLraS42mh6lW+69rRpRs4r+W9+arXNXvGTz9K06XHC69//3o9zsMiv49RqVtpcc68laz /C1oeZ7HUlPLdZT72Hdrtu4XKx2Yp//Ym7Z/e3bOO/lJQqK2x5Jc7gtcXNjRyNp9RjjFLDgk IL/G83jE7aTz+ybwxE/cNt+7fIWGEktxRqKhFnNRcSIAdgyTFpMCAAA= Cc: "draft-ietf-ospf-rfc6506bis.all@tools.ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ospf-rfc6506bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 18:22:38 -0000 I tend to agree with Manav - this seems to be a rather extreme measure and wouldn't be used by a router line card simply to prioritize a packet. Thanks, Acee On 12/4/13 8:29 AM, "Bhatia, Manav (Manav)" wrote: >Hi Brian, > >Thanks for the review. I have a comment inline. >>=20 >> But now RFC 5879 ("Heuristics for Detecting ESP-NULL Packets") has been >> published, which does describe some techniques to deterministically >> detect an unencrypted ESP packet. It may be still be difficult to >> prioritize certain OSPFv3 packets, but the justification is no longer >> precisely accurate. I would suggest something like the following >> rewording: > >The justification still holds good as I don't think we will ever use >heuristics for detecting ESP-NULL control packets that need to be >consumed. > >Its afaik primarily meant for firewalls that want to deep inspect >packets. Obviously, there is nothing there in the standard that precludes >it from being implemented on router's CPU path, but I doubt if we will >ever go down that path. If this is really required on the routers, then >WESP (RFC 5840) will probably be the path to go down on -- but that would >require protocol extensions. > >Cheers, Manav > >>=20 >> Implementations desiring to prioritize certain OSPFv3 packet types, >> e.g., Hello packets, over the other types, often perform the >> prioritization prior to decryption. Parsing ESP packets is >> problematic >> when the prioritization code does not know whether the ESP packets >> include an encryption algorithm, or are instead ESP-NULL packets >> [RFC2410]. >> Techniques exist to identify ESP packets using ESP-NULL packets >> [RFC5879], which would allow these packets to be examined and >> prioritized. However, the techniques may not be practically applied >> within the prioritization code. >>=20 >> Brian From bew@cisco.com Wed Dec 4 10:37:23 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1501AC862; Wed, 4 Dec 2013 10:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bM9ZRKyYCYmv; Wed, 4 Dec 2013 10:37:20 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 263F61A1EF9; Wed, 4 Dec 2013 10:37:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2503; q=dns/txt; s=iport; t=1386182237; x=1387391837; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=HNhyZwbBzidgJvoNiuFpfOf5RFxTqm4gjMcwCQfSccQ=; b=E5CVvFtSYWnZCdzroM1kYixD3BdMHqqpGi3bFPL2qVQRXRx2DTALyw+K diW7PFvB9hVKxbMcej4o2gmhryx/luJzrbRAb5uJSufa0khJ5t2GzXBqa /HQU811Z+8N3g9+8PPP3DFTB0kx4Tq7MCnYmpwv7V69XG/mhYzu+UkAPK I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABR1n1KrRDoJ/2dsb2JhbABQBwODB7lugSQWdIIlAQEBAwE6PwULCxguVwYTh3wFwXAXjhwGCwEdIxAHEYMPgRMDiUKOUoZFi06DShuBNQ X-IronPort-AV: E=Sophos;i="4.93,826,1378857600"; d="scan'208";a="96936480" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 04 Dec 2013 18:37:15 +0000 Received: from [10.155.144.179] ([10.155.144.179]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB4IbBRI002457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Dec 2013 18:37:14 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Weis In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE470310EECD@eusaamb101.ericsson.se> Date: Wed, 4 Dec 2013 10:37:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <15E31E00-23FA-47A4-BE3D-705D4519D2F1@cisco.com> References: <94A203EA12AECE4BA92D42DBFFE0AE470310EECD@eusaamb101.ericsson.se> To: Acee Lindem X-Mailer: Apple Mail (2.1510) Cc: "draft-ietf-ospf-rfc6506bis.all@tools.ietf.org" , "Bhatia, Manav \(Manav\)" , The IESG , "" Subject: Re: [secdir] Secdir review of draft-ietf-ospf-rfc6506bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 18:37:23 -0000 Hi Acee & Manav, On Dec 4, 2013, at 10:22 AM, Acee Lindem = wrote: > I tend to agree with Manav - this seems to be a rather extreme measure = and > wouldn't be used by a router line card simply to prioritize a packet. Agreed, but the current text essentially says "you can't do that', but = in fact "you can do that but it's too much work to do on the router line = card". I was suggesting you say that instead. Thanks, Brian >=20 > Thanks, > Acee >=20 > On 12/4/13 8:29 AM, "Bhatia, Manav (Manav)" > wrote: >=20 >> Hi Brian, >>=20 >> Thanks for the review. I have a comment inline. >>>=20 >>> But now RFC 5879 ("Heuristics for Detecting ESP-NULL Packets") has = been >>> published, which does describe some techniques to deterministically >>> detect an unencrypted ESP packet. It may be still be difficult to >>> prioritize certain OSPFv3 packets, but the justification is no = longer >>> precisely accurate. I would suggest something like the following >>> rewording: >>=20 >> The justification still holds good as I don't think we will ever use >> heuristics for detecting ESP-NULL control packets that need to be >> consumed. >>=20 >> Its afaik primarily meant for firewalls that want to deep inspect >> packets. Obviously, there is nothing there in the standard that = precludes >> it from being implemented on router's CPU path, but I doubt if we = will >> ever go down that path. If this is really required on the routers, = then >> WESP (RFC 5840) will probably be the path to go down on -- but that = would >> require protocol extensions. >>=20 >> Cheers, Manav >>=20 >>>=20 >>> Implementations desiring to prioritize certain OSPFv3 packet = types, >>> e.g., Hello packets, over the other types, often perform the >>> prioritization prior to decryption. Parsing ESP packets is >>> problematic >>> when the prioritization code does not know whether the ESP packets >>> include an encryption algorithm, or are instead ESP-NULL packets >>> [RFC2410]. >>> Techniques exist to identify ESP packets using ESP-NULL packets >>> [RFC5879], which would allow these packets to be examined and >>> prioritized. However, the techniques may not be practically = applied >>> within the prioritization code. >>>=20 >>> Brian >=20 --=20 Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From trammell@tik.ee.ethz.ch Wed Dec 4 10:52:35 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1F41AE171; Wed, 4 Dec 2013 10:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1VqKcxWCb4f; Wed, 4 Dec 2013 10:52:32 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9811AE13A; Wed, 4 Dec 2013 10:52:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 25FFED9304; Wed, 4 Dec 2013 19:52:28 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zRA7YqJbR73O; Wed, 4 Dec 2013 19:52:27 +0100 (MET) Received: from public-docking-pat-etx-2357.ethz.ch (public-docking-pat-etx-2357.ethz.ch [10.2.121.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id D7616D9303; Wed, 4 Dec 2013 19:52:27 +0100 (MET) Message-ID: <529F79EA.6050406@tik.ee.ethz.ch> Date: Wed, 04 Dec 2013 19:52:26 +0100 From: Brian Trammell User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Simon Josefsson References: <20131102224014.1aca13bf@latte.josefsson.org> In-Reply-To: <20131102224014.1aca13bf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, draft-trammell-ipfix-tcpcontrolbits-revision.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-trammell-ipfix-tcpcontrolbits-revision-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 18:52:35 -0000 Hi, Simon, all, Thanks for the review! I'm applying comments to a new -05 revision. Comments thereon inline. Simon Josefsson wrote: > Hi. > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Summary: This is an informational document fixing what appears as a bug > in the IPFIX IANA registry that was introduced in RFC 5102. The error > was that RFC 5102 used the wrong size for TCP header field, and did not > include three TCP header flags defined after RFC793 (but long before > RFC 5102). It also changes the semantics to be future proof in case > new TCP header flags are used. > > From a security review point of view, I see no significant issues with > this document. > > While reading the document, I noticed a couple of things. > > MAJOR: > > * The document says that processes that can't observe the ECN Nonce > Sum (NS) bit or Future Use bits "should" export the 8-byte value as > the old 8-bit value. I believe RFC 2119 terms is warranted here, as > it appears to influence bytes-on-the-wire. Is this SHOULD or MUST? This would be a SHOULD. One, the ADT is unsigned16, so we'll almost certainly get EPs that will ignore a MUST here and just export 16 bits always even if they only support the bottom 6. Two, there's already guidance on handling the ambiguity in the next paragraph. This was a should instead of a SHOULD because the text in this section goes into the IANA IPFIX Elements Registry, and (perhaps this is a bit pedantic) the registry does not contain a reference to 2119 to explain the meaning of the terms. However, on review, I see there is already 2119 language there, so SHOULD it is. > MINOR: > > * If the above SHOULD/MUST is honored, some information will be > potentially be lost. Consider a process that can observe the CWR/ECE > bits but not the NS or Future Use bits. That process would export > the tcpControlBits as a 8-bit value. However, earlier specifications > said that CWR/ECE bits must be zero even if observed. This means that > instead of being able to trust the CWR/ECE bit values, those fields > are unreliable. If instead a 16-bit value is always sent, the CWR/ECE > bits will be reliable. This is a good point. But given the inconsistent interpretation of this field by exporting process implementations, we'll have to deal with the ambiguity here anyway. > However, it may be that this aspect is entirely theoretical, and that > all implementations that support CWR/ECE also support NS or Future Use > bits. Nope. At this point I know of at least two implementations that ignore the current CWR/ECE must be zero and export them anyway (if one is lazy, it's a lot easier just to save the whole byte than to worry about which end of it to mask). This revision is in part an attempt to make the registry match this reality. > * The document says "Octets 12 and 13" throughout, however if I'm > counting the TCP header octets properly, it should be "Octets 13 and > 14". I call the first octet octet 1 rather than 0, maybe that was > the origin of the +-1 issue. Whenever you start counting on 0 rather > than 1, I think that should be spelled out; it might make things more > clear to spell that out regardless. I've never seen anyone count bits or octets from 1. But I'm happy to add a (counting from zero) note here to make that explicit. > * The acronym IE is not spelled out. Oops. We get sick of typing/saying Information Element all the time in IPFIX. Sometimes I forget to search/replace back. Thanks! > OLD: > length), the corresponding bits in this IE must be exported as > NEW: > length), the corresponding bits in this Information Element (IE) must > be exported as > > * The Security Considerations section could mention that this document > changes the size of the tcpControlBits IE from unsigned8 to > unsigned16, which is probably about the only thing you would want to > consider when studying the security aspect of this document. Yep. Done. > * In section 2 there is one sentence: > > The values of each bit are shown below, per the definition of the > bits in the TCP header [RFC0793]: > > That isn't really correct, since what is shown below the text above is > not consistent with RFC793 alone. I would instead say: > > The values of each bit are shown below, per the definition of the > bits in the TCP header [RFC0793][RFC3168][RFC3540]: Yep, fixed. > * The IANA-IPFIX reference looks bad in section 6.2. xml2rfc's reference handling isn't really designed for corporate authorship and undated documents. I'll hack the differences out of the resulting txt. Thanks again, best regards, Brian From hartmans@mit.edu Wed Dec 4 12:09:01 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353E41AE2BD; Wed, 4 Dec 2013 12:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7tqYt30swIn; Wed, 4 Dec 2013 12:08:59 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id C5B971AD8E1; Wed, 4 Dec 2013 12:08:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 986DA20178; Wed, 4 Dec 2013 15:08:00 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GX0IUt-GyAz; Wed, 4 Dec 2013 15:08:00 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 4 Dec 2013 15:08:00 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7050D831AE; Wed, 4 Dec 2013 15:08:55 -0500 (EST) From: Sam Hartman To: secdir@ietf.org,iesg@ietf.org Date: Wed, 04 Dec 2013 15:08:55 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-bfd-on-lans@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-bfd-on-lans X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 20:09:01 -0000 I seem to be getting easy documents of late. This document describes how to run BFD over LAGs. Multiple l2 links are combined into a larger l2 link for better throughput and load balancing and redundancy. >From the standpoint of /l3 these all appear to be a single interface. If you look at it funny and futz your tables so BFD gets to treat these interfaces as distinct, you can use BFD to make sure members of the LAG are up. If the universe valued good abstraction layers, entire civilizations would crumble in disgust every time you send one of these packets. However, it is a useful hack for performance and code re-use. The document claims that there are no new security considerations. As far as I can tell, that is true. I have no concerns. From adrian@olddog.co.uk Wed Dec 4 14:21:50 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C58C1ADF27; Wed, 4 Dec 2013 14:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v71rp3xwtixG; Wed, 4 Dec 2013 14:21:48 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 057A91A8032; Wed, 4 Dec 2013 14:21:47 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB4MLhQc018224; Wed, 4 Dec 2013 22:21:44 GMT Received: from 950129200 ([149.254.181.185]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB4MLTlV018167 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Dec 2013 22:21:43 GMT From: "Adrian Farrel" To: "'Sam Hartman'" , , References: In-Reply-To: Date: Wed, 4 Dec 2013 22:21:28 -0000 Message-ID: <11f901cef13f$35ac21b0$a1046510$@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: AQFeuEBJLwQ8Rs0wgrjZaO02+s0Ndpsk/RMA Content-Language: en-gb Cc: draft-ietf-bfd-on-lans@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-bfd-on-lans X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 04 Dec 2013 22:21:50 -0000 Thanks Sam, and sorry to disappoint you. Your quote is going in my Twitter file... > If the universe valued good abstraction layers, entire civilizations > would crumble in disgust every time you send one of these packets. > However, it is a useful hack for performance and code re-use. Cheers, Adrian From manav.bhatia@alcatel-lucent.com Wed Dec 4 16:53:57 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452FB1AE1D7; Wed, 4 Dec 2013 16:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvTkybjacPZu; Wed, 4 Dec 2013 16:53:55 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 846781ADF87; Wed, 4 Dec 2013 16:53:55 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rB50rm5f007177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Dec 2013 18:53:48 -0600 (CST) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id rB50rlKu019269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 19:53:47 -0500 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 4 Dec 2013 19:53:47 -0500 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.101]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Thu, 5 Dec 2013 08:53:44 +0800 From: "Bhatia, Manav (Manav)" To: Brian Weis , Acee Lindem Thread-Topic: Secdir review of draft-ietf-ospf-rfc6506bis-03 Thread-Index: AQHO8JlV9WFla24GnUezZsX6mO0MTppEKSUA//+rIQCAAAQdgIAA6Lvg Date: Thu, 5 Dec 2013 00:53:43 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E526B66@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <94A203EA12AECE4BA92D42DBFFE0AE470310EECD@eusaamb101.ericsson.se> <15E31E00-23FA-47A4-BE3D-705D4519D2F1@cisco.com> In-Reply-To: <15E31E00-23FA-47A4-BE3D-705D4519D2F1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "draft-ietf-ospf-rfc6506bis.all@tools.ietf.org" , The IESG , "" Subject: Re: [secdir] Secdir review of draft-ietf-ospf-rfc6506bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 00:53:57 -0000 Hi Brian, >=20 > > I tend to agree with Manav - this seems to be a rather extreme measure > > and wouldn't be used by a router line card simply to prioritize a > packet. >=20 > Agreed, but the current text essentially says "you can't do that', but > in fact "you can do that but it's too much work to do on the router line > card". I was suggesting you say that instead. While, we can add such a text, I am convinced nobody will *ever* use heuris= tics to figure out the kind of packet they're receiving at their line cards= . The most important reason being that using heuristics does not give you a= deterministic result. While it may be acceptable to get a few false positi= ves or negatives when forwarding traffic through the firewall, this will be= unacceptable when consuming packets by the router. Then the additional ove= rhead of applying heuristics is an issue that I am not even delving into. M= ost of the forwarding from line card to the main CPU card is done in HW. Yo= u cannot apply heuristics in HW. This means, we assume that all CPU bound p= ackets are being punted from the line card to the main CPM card via softwar= e. This is not how it happens today. Applying heuristics requires lot of flow information to be maintained, whic= h adds an additional complexity of flow maintenance (you need to decide whe= n a flow needs to be deleted if its not being hit often enough) in the line= cards. There are many more points that go against the heuristics, especially in th= e context that we're discussing here. If we are ever looking at disambiguat= ing ESP-NULL packets for router consumption, then I am pretty sure it's goi= ng to be Wrapped ESP. My point is that adding text about heuristics may just confuse the reader w= ho will most likely not understand the details of what it entails to do heu= ristics on a line card. While you (being the Security guru) and I (co-autho= red Wrapped ESP) understand that this is only theoretically possible and pr= actically will never make sense -- the same cannot be assumed from somebody= from the routing world, who is not so security savvy, going through this s= tandard. Cheers, Manav=20 From warren@kumari.net Wed Dec 4 17:16:09 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C911AE1E5; Wed, 4 Dec 2013 17:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cs3t7pHmjEzm; Wed, 4 Dec 2013 17:16:06 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817CB1AE1E3; Wed, 4 Dec 2013 17:16:06 -0800 (PST) Received: from [192.168.1.153] (unknown [66.84.81.107]) by vimes.kumari.net (Postfix) with ESMTPSA id A203E1B405C5; Wed, 4 Dec 2013 20:16:02 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: <20211F91F544D247976D84C5D778A4C32E526B66@SG70YWXCHMBA05.zap.alcatel-lucent.com> Date: Wed, 4 Dec 2013 20:16:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94A203EA12AECE4BA92D42DBFFE0AE470310EECD@eusaamb101.ericsson.se> <15E31E00-23FA-47A4-BE3D-705D4519D2F1@cisco.com> <20211F91F544D247976D84C5D778A4C32E526B66@SG70YWXCHMBA05.zap.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" X-Mailer: Apple Mail (2.1510) Cc: "" , "draft-ietf-ospf-rfc6506bis.all@tools.ietf.org" , Acee Lindem , The IESG Subject: Re: [secdir] Secdir review of draft-ietf-ospf-rfc6506bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 01:16:09 -0000 On Dec 4, 2013, at 7:53 PM, "Bhatia, Manav (Manav)" = wrote: > Hi Brian, >=20 >>=20 >>> I tend to agree with Manav - this seems to be a rather extreme = measure >>> and wouldn't be used by a router line card simply to prioritize a >> packet. >>=20 >> Agreed, but the current text essentially says "you can't do that', = but >> in fact "you can do that but it's too much work to do on the router = line >> card". I was suggesting you say that instead. >=20 > While, we can add such a text, I am convinced nobody will *ever* use = heuristics to figure out the kind of packet they're receiving at their = line cards. The most important reason being that using heuristics does = not give you a deterministic result. While it may be acceptable to get a = few false positives or negatives when forwarding traffic through the = firewall, this will be unacceptable when consuming packets by the = router. Then the additional overhead of applying heuristics is an issue = that I am not even delving into. Most of the forwarding from line card = to the main CPU card is done in HW. You cannot apply heuristics in HW. = This means, we assume that all CPU bound packets are being punted from = the line card to the main CPM card via software. This is not how it = happens today. Well, you could punt all packet to the CPU and examine them to see it = they are important enough to be punted to=85 Oh! hang on a sec :-) How about: "While techniques exist to identify ESP-NULL packets=20 [RFC5879], implementing these in line cards is not currently = feasible." ? >=20 > Applying heuristics requires lot of flow information to be maintained, = which adds an additional complexity of flow maintenance (you need to = decide when a flow needs to be deleted if its not being hit often = enough) in the line cards. >=20 > There are many more points that go against the heuristics, especially = in the context that we're discussing here. If we are ever looking at = disambiguating ESP-NULL packets for router consumption, then I am pretty = sure it's going to be Wrapped ESP. >=20 > My point is that adding text about heuristics may just confuse the = reader who will most likely not understand the details of what it = entails to do heuristics on a line card. While you (being the Security = guru) and I (co-authored Wrapped ESP) understand that this is only = theoretically possible and practically will never make sense -- the same = cannot be assumed from somebody from the routing world, who is not so = security savvy, going through this standard. >=20 > Cheers, Manav=20 >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >=20 -- The duke had a mind that ticked like a clock and, like a clock, it = regularly went cuckoo. -- (Terry Pratchett, Wyrd Sisters) From manav.bhatia@alcatel-lucent.com Wed Dec 4 17:38:45 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847E61AE2D8; Wed, 4 Dec 2013 17:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCGdgEyl-ESI; Wed, 4 Dec 2013 17:38:43 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 375311AE2DE; Wed, 4 Dec 2013 17:38:43 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rB51cYd1013327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Dec 2013 19:38:34 -0600 (CST) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id rB51cW8U003232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 20:38:33 -0500 Received: from SG70XWXCHHUB02.zap.alcatel-lucent.com (135.253.2.47) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 4 Dec 2013 20:38:32 -0500 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.101]) by SG70XWXCHHUB02.zap.alcatel-lucent.com ([135.253.2.47]) with mapi id 14.02.0247.003; Thu, 5 Dec 2013 09:38:05 +0800 From: "Bhatia, Manav (Manav)" To: Warren Kumari Thread-Topic: [secdir] Secdir review of draft-ietf-ospf-rfc6506bis-03 Thread-Index: AQHO8JlV9WFla24GnUezZsX6mO0MTppEKSUA//+rIQCAAAQdgIAA6Lvg//+GsgCAAItx4A== Date: Thu, 5 Dec 2013 01:38:03 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E526C02@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <94A203EA12AECE4BA92D42DBFFE0AE470310EECD@eusaamb101.ericsson.se> <15E31E00-23FA-47A4-BE3D-705D4519D2F1@cisco.com> <20211F91F544D247976D84C5D778A4C32E526B66@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "draft-ietf-ospf-rfc6506bis.all@tools.ietf.org" , Acee Lindem , The IESG , "" Subject: Re: [secdir] Secdir review of draft-ietf-ospf-rfc6506bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 01:38:45 -0000 Hi Warren, >=20 > Well, you could punt all packet to the CPU and examine them to see it > they are important enough to be punted to... Oh! hang on a sec :-) You cant do that. You look at the incoming packet at the line card, decide = what internal priority and queue the packet should take via the fabric. So = there is some level of deep inspecrion and differentiation that happens at = line cards. Without knowing what the ESP packet is carrying, it's hard to a= ssign it a meaningful priority.=20 > How about: > "While techniques exist to identify ESP-NULL packets > [RFC5879], implementing these in line cards is not currently > feasible." ? Sure, we can add something to this effect. Cheers, Manav > > > > Applying heuristics requires lot of flow information to be maintained, > which adds an additional complexity of flow maintenance (you need to > decide when a flow needs to be deleted if its not being hit often > enough) in the line cards. > > > > There are many more points that go against the heuristics, especially > in the context that we're discussing here. If we are ever looking at > disambiguating ESP-NULL packets for router consumption, then I am pretty > sure it's going to be Wrapped ESP. > > > > My point is that adding text about heuristics may just confuse the > reader who will most likely not understand the details of what it > entails to do heuristics on a line card. While you (being the Security > guru) and I (co-authored Wrapped ESP) understand that this is only > theoretically possible and practically will never make sense -- the same > cannot be assumed from somebody from the routing world, who is not so > security savvy, going through this standard. > > > > Cheers, Manav > > > > _______________________________________________ > > secdir mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > >=20 > -- > The duke had a mind that ticked like a clock and, like a clock, it > regularly went cuckoo. >=20 > -- (Terry Pratchett, Wyrd Sisters) >=20 From stephen.farrell@cs.tcd.ie Thu Dec 5 01:57:26 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CA91ADBD4; Thu, 5 Dec 2013 01:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZpkDEeleQQ4; Thu, 5 Dec 2013 01:57:24 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7261ACC7D; Thu, 5 Dec 2013 01:57:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B36F2BE9A; Thu, 5 Dec 2013 09:57:20 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRHkRIMiMLo1; Thu, 5 Dec 2013 09:57:20 +0000 (GMT) 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 89F04BE8B; Thu, 5 Dec 2013 09:57:20 +0000 (GMT) Message-ID: <52A04E01.500@cs.tcd.ie> Date: Thu, 05 Dec 2013 09:57:21 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'Sam Hartman' , secdir@ietf.org, iesg@ietf.org References: <11f901cef13f$35ac21b0$a1046510$@olddog.co.uk> In-Reply-To: <11f901cef13f$35ac21b0$a1046510$@olddog.co.uk> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-bfd-on-lans@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-bfd-on-lans X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 09:57:27 -0000 On 12/04/2013 10:21 PM, Adrian Farrel wrote: > Thanks Sam, and sorry to disappoint you. > > Your quote is going in my Twitter file... > >> If the universe valued good abstraction layers, entire civilizations >> would crumble in disgust every time you send one of these packets. >> However, it is a useful hack for performance and code re-use. That is good:-) S. > > Cheers, > Adrian > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From kivinen@iki.fi Thu Dec 5 02:36:32 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908291AD8F5; Thu, 5 Dec 2013 02:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jj-CgGdmDCi; Thu, 5 Dec 2013 02:36:29 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8D01ADE72; Thu, 5 Dec 2013 02:36:28 -0800 (PST) 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 rB5AaD3j023481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Dec 2013 12:36:13 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rB5AaC1o022282; Thu, 5 Dec 2013 12:36:12 +0200 (EET) 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: <21152.22300.316826.240504@fireball.kivinen.iki.fi> Date: Thu, 5 Dec 2013 12:36:12 +0200 From: Tero Kivinen To: "Bhatia\, Manav \(Manav\)" In-Reply-To: <20211F91F544D247976D84C5D778A4C32E526B66@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <94A203EA12AECE4BA92D42DBFFE0AE470310EECD@eusaamb101.ericsson.se> <15E31E00-23FA-47A4-BE3D-705D4519D2F1@cisco.com> <20211F91F544D247976D84C5D778A4C32E526B66@SG70YWXCHMBA05.zap.alcatel-lucent.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 12 min X-Total-Time: 23 min Cc: "draft-ietf-ospf-rfc6506bis.all@tools.ietf.org" , Acee Lindem , The IESG , "" Subject: Re: [secdir] Secdir review of draft-ietf-ospf-rfc6506bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 10:36:32 -0000 Bhatia, Manav (Manav) writes: > > Agreed, but the current text essentially says "you can't do that', but > > in fact "you can do that but it's too much work to do on the router line > > card". I was suggesting you say that instead. > > While, we can add such a text, I am convinced nobody will *ever* use > heuristics to figure out the kind of packet they're receiving at > their line cards. The most important reason being that using > heuristics does not give you a deterministic result. While it may be > acceptable to get a few false positives or negatives when forwarding > traffic through the firewall, this will be unacceptable when > consuming packets by the router. Then the additional overhead of > applying heuristics is an issue that I am not even delving into. > Most of the forwarding from line card to the main CPU card is done > in HW. You cannot apply heuristics in HW. This means, we assume that > all CPU bound packets are being punted from the line card to the > main CPM card via software. This is not how it happens today. First of all, heuristics is supposed to be done on hardware, but not all of it is done on the hardware. Hardware parts only consists the first few steps checking whether packet is ESP and whether we already know its parameters. If not (i.e. it is new ESP flow), then we drop to slowpath and do the full analysis. So slowpath processing is only done on the new ESP Flows. I.e. if you see SPI you have already analyzed you can check from your state table whether it is ESP null or not, and process it accordingly. If you see unknown ESP then you forward packets to the heuristics, until it returns parameters (or make a call to your IPsec module and ask definite answer from there :-) > Applying heuristics requires lot of flow information to be > maintained, which adds an additional complexity of flow maintenance > (you need to decide when a flow needs to be deleted if its not being > hit often enough) in the line cards. It needs to keep mapping from the IP addresses and SPI to whether it is ESP null (and parameters) or encrypted ESP flow. I.e few bytes per ESP flow (+ selector: src IP, dst IP, SPI). > There are many more points that go against the heuristics, > especially in the context that we're discussing here. If we are ever > looking at disambiguating ESP-NULL packets for router consumption, > then I am pretty sure it's going to be Wrapped ESP. Which most likely should also be mentioned in the draft. > My point is that adding text about heuristics may just confuse the > reader who will most likely not understand the details of what it > entails to do heuristics on a line card. While you (being the > Security guru) and I (co-authored Wrapped ESP) understand that this > is only theoretically possible and practically will never make sense > -- the same cannot be assumed from somebody from the routing world, > who is not so security savvy, going through this standard. -- kivinen@iki.fi From kivinen@iki.fi Thu Dec 5 02:52:59 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200D31ADF22 for ; Thu, 5 Dec 2013 02:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSJ_nfKNL7zP for ; Thu, 5 Dec 2013 02:52:57 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id F326D1ADEBB for ; Thu, 5 Dec 2013 02:52:56 -0800 (PST) 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 rB5AqqgJ008831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 5 Dec 2013 12:52:52 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rB5AqqMX027398; Thu, 5 Dec 2013 12:52:52 +0200 (EET) 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: <21152.23300.557016.882959@fireball.kivinen.iki.fi> Date: Thu, 5 Dec 2013 12:52:52 +0200 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.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 10:52:59 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Yoav Nir is next in the rotation. For telechat 2013-12-05 Reviewer LC end Draft Dave Cridland T 2013-11-28 draft-leiba-smime-type-registry-02 Dan Harkins T 2013-11-26 draft-ietf-trill-oam-framework-03 Julien Laganier T 2013-11-06 draft-ietf-forces-ceha-09 Ondrej Sury T 2013-11-18 draft-ietf-l2vpn-etree-reqt-05 Tom Yu T 2013-11-27 draft-ietf-sidr-rpki-rtr-impl-04 For telechat 2013-12-19 Dave Cridland T 2013-11-04 draft-ietf-httpbis-p5-range-25 Dorothy Gellert T 2013-12-06 draft-bundesbank-eurosystem-namespace-02 Tobias Gondrom T 2013-11-25 draft-ietf-json-rfc4627bis-08 Simon Josefsson T 2013-12-06 draft-ietf-jose-use-cases-05 Matt Lepinski T 2013-11-04 draft-ietf-httpbis-p2-semantics-25 For telechat 2014-01-09 Derek Atkins TR2013-10-01 draft-ietf-siprec-architecture-10 Adam Montville T 2013-12-31 draft-farrell-perpass-attack-02 Last calls and special requests: Rob Austein 2013-11-27 draft-turner-application-cms-media-type-07 Dave Cridland E 2013-11-21 draft-dunbar-armd-arp-nd-scaling-practices-07 Steve Hanna E 2013-11-28 draft-ietf-pcp-nat64-prefix64-04 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05 Jeffrey Hutzelman 2013-12-09 draft-ietf-avtcore-leap-second-06 Leif Johansson 2013-12-06 draft-ietf-ecrit-country-emg-urn-01 Scott Kelly 2013-12-10 draft-ietf-opsawg-rfc5066bis-06 Stephen Kent 2013-12-17 draft-ietf-ospf-manet-single-hop-or-03 Tero Kivinen 2013-12-06 draft-ietf-payload-rtp-aptx-04 Julien Laganier 2013-12-06 draft-ietf-avtcore-rtp-security-options-09 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-09 Julien Laganier 2013-12-11 draft-ietf-stox-core-07 Ben Laurie 2013-12-11 draft-ietf-stox-presence-06 Matt Lepinski 2013-12-09 draft-rosen-rph-reg-policy-01 Chris Lonvick E 2013-12-12 draft-ietf-roll-applicability-ami-07 Catherine Meadows E 2013-12-12 draft-ietf-roll-applicability-home-building-01 Alexey Melnikov E 2013-12-12 draft-ietf-roll-rpl-industrial-applicability-02 Kathleen Moriarty 2013-12-16 draft-ietf-opsec-vpn-leakages-02 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Vincent Roca 2013-04-26 draft-ietf-6man-stable-privacy-addresses-15 Yaron Sheffer 2013-11-27 draft-ietf-idr-extcomm-iana-02 Klaas Wierenga 2013-11-27 draft-ietf-pwe3-dynamic-ms-pw-20 Tom Yu R2013-12-09 draft-ietf-rtgwg-cl-requirement-13 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 Glen Zorn 2013-11-27 draft-turner-ct-keypackage-receipt-n-error-algs-04 -- kivinen@iki.fi From kivinen@iki.fi Thu Dec 5 04:47:22 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C101ADFAE; Thu, 5 Dec 2013 04:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mD5WamAW-co9; Thu, 5 Dec 2013 04:47:20 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id F04C31ADFA1; Thu, 5 Dec 2013 04:47:19 -0800 (PST) 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 rB5ClEP9008511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Dec 2013 14:47:14 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rB5ClDQx006664; Thu, 5 Dec 2013 14:47:13 +0200 (EET) 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: <21152.30161.542379.749064@fireball.kivinen.iki.fi> Date: Thu, 5 Dec 2013 14:47:13 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-payload-rtp-aptx.all@tools.ietf.org X-Edit-Time: 5 min X-Total-Time: 4 min Subject: [secdir] Secdir review of draft-ietf-payload-rtp-aptx-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 12:47:22 -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 how to transmit proprietary audio codec algorithms standard apt-X and enchanced apt-X in the RTP. The document has security considerations section which seems to be OK. If I have understood correctly the codec is constant bit rate codec, thus it is not vulnerable to the traffic analysis attacks described for example in the draft-ietf-avtcore-srtp-vbr-audio document. Perhaps the security considerations section could note that these codecs are not vulnerable to those attacks (if that is in deed true). -- kivinen@iki.fi From kleung@cisco.com Mon Dec 2 11:10:48 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545DA1ADE89 for ; Mon, 2 Dec 2013 11:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SYDMWf4quta for ; Mon, 2 Dec 2013 11:10:46 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 6705F1AD8ED for ; Mon, 2 Dec 2013 11:10:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1431; q=dns/txt; s=iport; t=1386011444; x=1387221044; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SGyyttWxNWH0pzxAFT+wicuVkjLN2HafhC8rNZIB+7A=; b=b+ugKTJWBHYdz4kJqlZbsztSLDLWwTCYD0r64RHvadbr+x9fyILOp6G7 g7HqZ8HbOm8tvulZFBd4oGvPO6SL8MGcgnOCCt8sAKZkbfebAKL+z6xxm YYiIetVljpkcoRntY6SURXtfQ4H/+lgEt9k1k1m5HZDnYUxrGzkxFHyqP U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOrZnFKtJXHA/2dsb2JhbABZgweBC7hngSUWdIIlAQEBBDo/DAQCAQgRBAEBCxQJBzIUCQgCBAENBQiHecABF45XMQcGgxqBEwOqJ4Mpgio X-IronPort-AV: E=Sophos;i="4.93,812,1378857600"; d="scan'208";a="3728803" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-7.cisco.com with ESMTP; 02 Dec 2013 19:10:44 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB2JAhXG028398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 19:10:43 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.155]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 13:10:43 -0600 From: "Kent Leung (kleung)" To: Shawn M Emery , "secdir@ietf.org" Thread-Topic: Review of draft-ietf-cdni-requirements-13 Thread-Index: AQHO7fGIVqIxWZsW8Uqa3e8Azg8q4ZpBSHKQ Date: Mon, 2 Dec 2013 19:10:43 +0000 Message-ID: References: <52158CF5.4050001@oracle.com> <529A2050.7090205@oracle.com> In-Reply-To: <529A2050.7090205@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.79.199] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 05 Dec 2013 06:14:25 -0800 Cc: "draft-ietf-cdni-requirements.all@tools.ietf.org" Subject: Re: [secdir] Review of draft-ietf-cdni-requirements-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 19:10:48 -0000 Thank you for the review. Kent -----Original Message----- From: Shawn M Emery [mailto:shawn.emery@oracle.com]=20 Sent: Saturday, November 30, 2013 9:29 AM To: secdir@ietf.org Cc: draft-ietf-cdni-requirements.all@tools.ietf.org Subject: Review of draft-ietf-cdni-requirements-13 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These 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 internet-draft describes the requirements to integrate m= ultiple Content Delivery Networks (CDNs) for Content Service Providers (CSP= s) so that end users have a single point of access for content. The security considerations section does exist and refers to a separate sec= tion for the discussion on security requirements. This section gives requi= rements priorities from high to low on the various types of attacks. The h= igh level priorities are for authentication, confidentiality, integrity pro= tection, protection against replay, spoofing, and DoS attacks. Since it is= a requirements specification there is purposefully no discussion on how to= mitigate against such attacks. General comments: None. Editorial comments: None. Shawn. -- From charles.newyork@gmail.com Wed Dec 4 08:32:18 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249C21AE167; Wed, 4 Dec 2013 08:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzfrDJfkEFZl; Wed, 4 Dec 2013 08:32:16 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5A91AE08C; Wed, 4 Dec 2013 08:32:16 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id wm4so16352493obc.14 for ; Wed, 04 Dec 2013 08:32:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=/cbCXamB/D5mk3leb0owfHwSADhZPk9z3exZCAc/QJo=; b=T7xyqwwVQGqVyN8S9gPWJ9Jpaw5ZkjiGAmmOPOQ/jcgY4rvEZ+rRq+iwENM0Ea3k2L fg/yLoK6tUxjCG+yET+I0Xn0sEVIf/t2mo/AOXCt+Oni3oftpgh6hbEBuoHp36fGs+QQ DrcTtKzAlGD2+iqEfzNutRI0Ngh/qDYEqUqMsQvEro8hxJQYyPLiNccwBTXK9HtjE6hf OSFg7EKG6XFy9TpIdfyA5xeXssKxHfN2Wekm/w+X4iwQK1FPUqo5mKA+fFUv02W/by5o pfi72SoErHKNQaQUsymOCKyeDYxdSZk0ri3iMly97MVytg8B0J7xfrdvTYslW/dxQhju 0N1Q== X-Received: by 10.182.220.99 with SMTP id pv3mr14908990obc.37.1386174733068; Wed, 04 Dec 2013 08:32:13 -0800 (PST) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.182.27.9 with HTTP; Wed, 4 Dec 2013 08:31:51 -0800 (PST) In-Reply-To: References: From: Charles Shen Date: Thu, 5 Dec 2013 00:31:51 +0800 X-Google-Sender-Auth: kMu903mGVqOAtlmMD6SseYDcHCc Message-ID: To: Donald Eastlake Content-Type: multipart/alternative; boundary=14dae9399ab98faf0104ecb7f42a X-Mailman-Approved-At: Thu, 05 Dec 2013 06:14:25 -0800 Cc: "draft-ietf-soc-load-control-event-package.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-soc-load-control-event-package-11.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 16:32:18 -0000 --14dae9399ab98faf0104ecb7f42a Content-Type: text/plain; charset=UTF-8 Hi Donald, thanks for reviewing, please see responses inline: On Tue, Dec 3, 2013 at 6:31 AM, Donald Eastlake 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. > > This draft provides SIP capabilities (a load control event package) > for filtering calls with the intent of better handling overload > conditions. As you might expect for an extension to an existing > protocol, there are many references to existing SIP RFCs. > > The Security Considerations Section appears to be adequate. It > references RFCs 6665 and other sections of the draft and seems to > summarize relevant threats. > > Minor points: > > The introductions (Section 1) give examples of anticipatable and > unanticipatable causes of overload. I find it curious that denial of > service attacks are not listed as a possible cause of unanticipated > overload. > Interestingly that thought occurred to me before. I think the ones we are listing now is slightly different from DoS in the sense that they are more real-people-calling overload vs. DoS where machine-made calling can be common. Also DoS is usually seen as an attack, while those listed examples seem all have legitimate causes. That said, I do think the network server still observes the fact of overload during DoS, so I have no problem adding it to the list. > > In Section 10, in answer to REQ 17, there is a reference to Section 10 > that, I believe, should be to Section 11. > Good catch! > > Editorial: > > Section 4 begins with what is said to be a list of requirements. And I > think almost all of them are. But the first item is just not worded as > a requirement. It says "... we focus ...". To be a requirement on the > solution it should talk about the solution, not the authors. I think, > it should be more like "For simplicity, the solution should focus on a > method of controlling SIP load, rather than a generic application > layer mechanism." > > Done. > Misc: > > The document contains lots of XML that I did not run through any > formal syntax check. > I ran them through xmlvalidation.com. thanks! Charles > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > --14dae9399ab98faf0104ecb7f42a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Donald, thanks for reviewing, please see responses inli= ne:


On Tue= , Dec 3, 2013 at 6:31 AM, Donald Eastlake <d3e3e3@gmail.com> = wrote:
I have reviewed this document as part of the= security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. =C2=A0Document editors and WG chairs should treat these comments just=
like any other last call comments.

This draft provides SIP capabilities (a load control event package)
for filtering calls with the intent of better handling overload
conditions. As you might expect for an extension to an existing
protocol, there are many references to existing SIP RFCs.

The Security Considerations Section appears to be adequate. It
references RFCs 6665 and other sections of the draft and seems to
summarize relevant threats.

Minor points:

The introductions (Section 1) give examples of anticipatable and
unanticipatable causes of overload. I find it curious that denial of
service attacks are not listed as a possible cause of unanticipated
overload.


Interestingly = that thought occurred to me before. I think the ones we are listing now is = slightly different from DoS in the sense that they are more real-people-cal= ling overload vs. DoS where machine-made calling can be common. Also DoS is= usually seen as an attack, while those listed examples seem all have legit= imate causes. That said, I do think the network server still observes the f= act of overload during DoS, so I have no problem adding it to the list. =C2= =A0
=C2=A0

In Section 10, in answer to REQ 17, there is a reference to Section 10
that, I believe, should be to Section 11.

Good catch!
=C2=A0

Editorial:

Section 4 begins with what is said to be a list of requirements. And I
think almost all of them are. But the first item is just not worded as
a requirement. It says "... we focus ...". To be a requirement on= the
solution it should talk about the solution, not the authors. I think,
it should be more like "For simplicity, the solution should focus on a=
method of controlling SIP load, rather than a generic application
layer mechanism."


Done.

=C2=A0<= /div>
Misc:

The document contains lots of XML that I did not run through any
formal syntax check.


I r= an them through xmlvalidation.com.= =C2=A0

thanks!

Charles


=C2=A0

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

--14dae9399ab98faf0104ecb7f42a-- From volker.hilt@bell-labs.com Thu Dec 5 06:08:51 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB471ADFF6; Thu, 5 Dec 2013 06:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTjVF-TF3vCk; Thu, 5 Dec 2013 06:08:49 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 10B391AE014; Thu, 5 Dec 2013 06:08:48 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rB5E8QKW007783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Dec 2013 08:08:26 -0600 (CST) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id rB5E8Olm017614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 09:08:25 -0500 Received: from [149.204.61.163] (135.5.27.17) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 5 Dec 2013 09:08:24 -0500 Message-ID: <52A088D5.1020804@bell-labs.com> Date: Thu, 5 Dec 2013 15:08:21 +0100 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Charles Shen , Donald Eastlake References: In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.17] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Mailman-Approved-At: Thu, 05 Dec 2013 06:14:26 -0800 Cc: "draft-ietf-soc-load-control-event-package.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-soc-load-control-event-package-11.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 14:08:51 -0000 Charles, Thanks for taking care of these comments! Volker On 04.12.2013 17:31, Charles Shen wrote: > Hi Donald, thanks for reviewing, please see responses inline: > > > On Tue, Dec 3, 2013 at 6:31 AM, Donald Eastlake > 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. > > This draft provides SIP capabilities (a load control event package) > for filtering calls with the intent of better handling overload > conditions. As you might expect for an extension to an existing > protocol, there are many references to existing SIP RFCs. > > The Security Considerations Section appears to be adequate. It > references RFCs 6665 and other sections of the draft and seems to > summarize relevant threats. > > Minor points: > > The introductions (Section 1) give examples of anticipatable and > unanticipatable causes of overload. I find it curious that denial of > service attacks are not listed as a possible cause of unanticipated > overload. > > > > Interestingly that thought occurred to me before. I think the ones we > are listing now is slightly different from DoS in the sense that they > are more real-people-calling overload vs. DoS where machine-made calling > can be common. Also DoS is usually seen as an attack, while those listed > examples seem all have legitimate causes. That said, I do think the > network server still observes the fact of overload during DoS, so I have > no problem adding it to the list. > > > In Section 10, in answer to REQ 17, there is a reference to Section 10 > that, I believe, should be to Section 11. > > > Good catch! > > > Editorial: > > Section 4 begins with what is said to be a list of requirements. And I > think almost all of them are. But the first item is just not worded as > a requirement. It says "... we focus ...". To be a requirement on the > solution it should talk about the solution, not the authors. I think, > it should be more like "For simplicity, the solution should focus on a > method of controlling SIP load, rather than a generic application > layer mechanism." > > > Done. > > Misc: > > The document contains lots of XML that I did not run through any > formal syntax check. > > > > I ran them through xmlvalidation.com . > > thanks! > > Charles > > > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > From mary.ietf.barnes@gmail.com Thu Dec 5 08:36:08 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F641AE0A3; Thu, 5 Dec 2013 08:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIEr81M-qxWt; Thu, 5 Dec 2013 08:36:06 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id A0CC71AE0D9; Thu, 5 Dec 2013 08:36:05 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id u57so11314258wes.9 for ; Thu, 05 Dec 2013 08:36:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U1maxBOQ3gsWuaw9Yx9K3NerEPHpCc73gDL0h6n3lHk=; b=fHJiClWsbnpQTWYum47Y09DH28uB7kDwmAFlEMK/i8xauuV9p4ZIs3N2BivL/4pRJR jCZyGz3aQfwMvwV//Pql0JpInBcM+yMdzhDYh0c47jxCUBIcKlJUNRL0akRmZZ45XxCl 0bKgnN5jcyjmpoox9SoMOPS9K/RXgpDpKM1xCpVjLVOXGcbfjhfE6q9ApQTkRpE/E35L ZzkaRnUmpGf3Bxt86QszMs2dk2yLVOkbZEHkCg0/saEuEIgeu47gaEBJXOorAETzOxs3 jmREyiqnmDGCXusoMujvMxk09pV0q/n54iCX1wLLpcv0WBtcj01nt2SB//y2ZYX98GB3 G73Q== MIME-Version: 1.0 X-Received: by 10.180.198.79 with SMTP id ja15mr12440397wic.36.1386261361785; Thu, 05 Dec 2013 08:36:01 -0800 (PST) Received: by 10.216.172.9 with HTTP; Thu, 5 Dec 2013 08:36:01 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Dec 2013 10:36:01 -0600 Message-ID: From: Mary Barnes To: "Joseph Salowey (jsalowey)" Content-Type: multipart/alternative; boundary=047d7b6242520902bb04eccc2093 X-Mailman-Approved-At: Thu, 05 Dec 2013 08:39:13 -0800 Cc: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" , The IESG , "" Subject: Re: [secdir] Secdir review of draft-ietf-clue-telepresence-requirements-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 16:36:08 -0000 --047d7b6242520902bb04eccc2093 Content-Type: text/plain; charset=ISO-8859-1 Hi Joe, Thanks for your review. Comments below [MB]. Mary. On Mon, Dec 2, 2013 at 7:07 PM, Joseph Salowey (jsalowey) < jsalowey@cisco.com> wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This draft is ready with some minor issues. > > The draft discusses requirements for multi-stream telepresence. I don't > know much about telepresence, but the draft seems straight forward. It > does include a single requirement about security and it does have a > security considerations section. Although, I might like a bit more > description about what "secure exchange" means it think it is probably > sufficient. The type of information that might be useful is what type of > attacks or threats is of concern? For example, does the information need to be secured to disclosure or > modification by intermediaries or does have to allow modification by > intermediaries. [MB] We had considered adding this sort of information to the security consideration section of this document, but it was extremely difficult as we really didn't have appropriate language terminology to be at all specific (even using the term "media capture" in the requirements is pushing it). So, more detail about the nature of the information and potential security and privacy concerns will be described in the CLUE Framework document (and of course, very specific details in the protocol documents). I wouldn't suggest you look at the framework document yet as we still have an outstanding action item to complete that section. [/MB] > > The one other question is whether the information about media captures has > any privacy considerations. For example is there geo-location or identity > information exchanged? Are there any long-term identifiers used? If there > is something that we know is going to be exchanged that is sensitive then > it would probably be worth including in the requirements. It didn't seem > that this type of data was required so this is probably more of a > consideration for the protocol spec. > [MB] Per my comment above, without the appropriate language and terminology, we found that we really couldn't be specific about the detailed information in the requirements document. Generally speaking the information about the media captures likely reveals less information about identity than does the information carried in the core signaling protocols upon which the CLUE solution will depend - i.e., SIP and SDP. We will of course, discuss the relevant privacy concerns and current limitations in the CLUE WG signaling solution document. [/MB] > > Cheers, > > Joe > > > --047d7b6242520902bb04eccc2093 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Joe,

Thanks fo= r your review. =A0Comments below [MB].

Mary.

=

On Mo= n, Dec 2, 2013 at 7:07 PM, Joseph Salowey (jsalowey) <= jsalowey@cisco.com<= /a>> wrote:
I have reviewed t= his document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. =A0These comments were written primarily for the benefit of the
security area directors. =A0Document editors and WG chairs should treat
these comments just like any other last call comments.

This draft is ready with some minor issues.

The draft discusses requirements for multi-stream telepresence. =A0 I don&#= 39;t know much about telepresence, but the draft seems straight forward. = =A0It does include a single requirement about security and it does have a s= ecurity considerations section. =A0 Although, I might like a bit more descr= iption about what "secure exchange" means it think it is probably= sufficient. =A0 The type of information that might be useful is what type = of attacks or threats is of concern? =A0=A0
For example, does the information need to be= secured to disclosure or modification by intermediaries or does have to al= low modification by intermediaries.=A0
=A0
[MB] We had considered adding this sort of informa= tion to the security consideration section of this document, but it was ext= remely difficult as we really didn't have appropriate language terminol= ogy to be at all specific (even using the term "media capture" in= the requirements is pushing it). =A0 So, more detail about the nature of t= he information and potential security and privacy concerns will be describe= d in the CLUE Framework document (and of course, very specific details in t= he protocol documents). =A0I wouldn't suggest you look at the framework= document yet as we still have an outstanding action item to complete that = section. =A0
[/MB]

The one other question is whether the information about media captures has = any privacy considerations. =A0 For example is there geo-location or identi= ty information exchanged? =A0Are there any long-term identifiers used? =A0I= f there is something that we know is going to be exchanged that is sensitiv= e then it would probably be worth including in the requirements. It didn= 9;t seem that this type of data was required so this is probably more of a = consideration for the protocol spec.
[MB] =A0Per my comment above, without the appropria= te language and terminology, we found that we really couldn't be specif= ic about the detailed information in the requirements document. Generally s= peaking the information about the media captures likely reveals less inform= ation about identity than does the information carried in the core signalin= g protocols upon which the CLUE solution will depend - i.e., SIP and SDP. = =A0We will of course, discuss the relevant privacy concerns and current lim= itations in the CLUE WG signaling solution document. =A0[/MB]=A0

Cheers,

Joe



--047d7b6242520902bb04eccc2093-- From warren@kumari.net Thu Dec 5 11:28:17 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C691AC829; Thu, 5 Dec 2013 11:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N29_ZeasbcTm; Thu, 5 Dec 2013 11:28:14 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CCA1A802A; Thu, 5 Dec 2013 11:28:14 -0800 (PST) Received: from [192.168.1.153] (unknown [66.84.81.107]) by vimes.kumari.net (Postfix) with ESMTPSA id CFA791B4061D; Thu, 5 Dec 2013 14:28:10 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: <20211F91F544D247976D84C5D778A4C32E526C02@SG70YWXCHMBA05.zap.alcatel-lucent.com> Date: Thu, 5 Dec 2013 14:28:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94A203EA12AECE4BA92D42DBFFE0AE470310EECD@eusaamb101.ericsson.se> <15E31E00-23FA-47A4-BE3D-705D4519D2F1@cisco.com> <20211F91F544D247976D84C5D778A4C32E526B66@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E526C02@SG70YWXCHMBA05.zap.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" X-Mailer: Apple Mail (2.1510) Cc: "" , "draft-ietf-ospf-rfc6506bis.all@tools.ietf.org" , Acee Lindem , The IESG Subject: Re: [secdir] Secdir review of draft-ietf-ospf-rfc6506bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 19:28:17 -0000 On Dec 4, 2013, at 8:38 PM, "Bhatia, Manav (Manav)" = wrote: > Hi Warren, >=20 >>=20 >> Well, you could punt all packet to the CPU and examine them to see it >> they are important enough to be punted to... Oh! hang on a sec :-) >=20 > You cant do that. You look at the incoming packet at the line card, = decide what internal priority and queue the packet should take via the = fabric. So there is some level of deep inspecrion and differentiation = that happens at line cards. Without knowing what the ESP packet is = carrying, it's hard to assign it a meaningful priority.=20 >=20 Yup. That was the point I was (unsuccessfully) trying to make -- I guess = the smiley was too subtle=85. >> How about: >> "While techniques exist to identify ESP-NULL packets >> [RFC5879], implementing these in line cards is not currently >> feasible." ? >=20 > Sure, we can add something to this effect. Cool. W >=20 > Cheers, Manav >=20 >>>=20 >>> Applying heuristics requires lot of flow information to be = maintained, >> which adds an additional complexity of flow maintenance (you need to >> decide when a flow needs to be deleted if its not being hit often >> enough) in the line cards. >>>=20 >>> There are many more points that go against the heuristics, = especially >> in the context that we're discussing here. If we are ever looking at >> disambiguating ESP-NULL packets for router consumption, then I am = pretty >> sure it's going to be Wrapped ESP. >>>=20 >>> My point is that adding text about heuristics may just confuse the >> reader who will most likely not understand the details of what it >> entails to do heuristics on a line card. While you (being the = Security >> guru) and I (co-authored Wrapped ESP) understand that this is only >> theoretically possible and practically will never make sense -- the = same >> cannot be assumed from somebody from the routing world, who is not so >> security savvy, going through this standard. >>>=20 >>> Cheers, Manav >>>=20 >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>>=20 >>=20 >> -- >> The duke had a mind that ticked like a clock and, like a clock, it >> regularly went cuckoo. >>=20 >> -- (Terry Pratchett, Wyrd Sisters) >>=20 >=20 --=20 No man is an island, But if you take a bunch of dead guys and tie them = together, they make a pretty good raft. --Anon. From bew@cisco.com Thu Dec 5 11:51:10 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830671A802A; Thu, 5 Dec 2013 11:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhnOR7nfNS9D; Thu, 5 Dec 2013 11:51:08 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCEA1A16F0; Thu, 5 Dec 2013 11:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2988; q=dns/txt; s=iport; t=1386273065; x=1387482665; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8WwhKLA/qbQ/a70b3P7B6edTPnRIqW5ohI9Rdj4QxnY=; b=ZeKxZifw0eq9jE4nlYxoxjiGh7lOMFTavHriJlEaOe7iO35kB6+O9leN wZ0cBV0otx+y7Gw9KvAIuda40an3gmkneoCfsHonUwj4UmJDP807w7Jxs pR6Nn7Zjr9i1knNbqGTsaKt44YAdPJQwkTWHuEHLkto8a7cdhkCzWn+zt E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAHvYoFKrRDoH/2dsb2JhbABPBwODBzi4ck6BHBZ0giUBAQEDAQEBAWsLEAsYLicwBhOHfAUOwUwXjh4GCwEdIxAHEYMPgRMDiUKOUoEwhRWLToNKG4E1 X-IronPort-AV: E=Sophos;i="4.93,835,1378857600"; d="scan'208";a="99604117" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 05 Dec 2013 19:51:05 +0000 Received: from [10.155.28.111] ([10.155.28.111]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB5Jo5vT008751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Dec 2013 19:51:02 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Weis In-Reply-To: Date: Thu, 5 Dec 2013 11:51:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <96652DAA-4E17-4451-BCED-454CDA819B21@cisco.com> References: <94A203EA12AECE4BA92D42DBFFE0AE470310EECD@eusaamb101.ericsson.se> <15E31E00-23FA-47A4-BE3D-705D4519D2F1@cisco.com> <20211F91F544D247976D84C5D778A4C32E526B66@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E526C02@SG70YWXCHMBA05.zap.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" X-Mailer: Apple Mail (2.1510) Cc: draft-ietf-ospf-rfc6506bis.all@tools.ietf.org, Acee Lindem , The IESG , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ospf-rfc6506bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 19:51:10 -0000 Hi Manav, On Dec 5, 2013, at 11:28 AM, Warren Kumari wrote: >=20 > On Dec 4, 2013, at 8:38 PM, "Bhatia, Manav (Manav)" = wrote: >=20 >> Hi Warren, >>=20 >>>=20 >>> Well, you could punt all packet to the CPU and examine them to see = it >>> they are important enough to be punted to... Oh! hang on a sec :-) >>=20 >> You cant do that. You look at the incoming packet at the line card, = decide what internal priority and queue the packet should take via the = fabric. So there is some level of deep inspecrion and differentiation = that happens at line cards. Without knowing what the ESP packet is = carrying, it's hard to assign it a meaningful priority.=20 >>=20 >=20 > Yup. That was the point I was (unsuccessfully) trying to make -- I = guess the smiley was too subtle=85. >=20 >>> How about: >>> "While techniques exist to identify ESP-NULL packets >>> [RFC5879], implementing these in line cards is not currently >>> feasible." ? >>=20 >> Sure, we can add something to this effect. >=20 > Cool. > W That sounds good to me too. Thanks, Brian >=20 >>=20 >> Cheers, Manav >>=20 >>>>=20 >>>> Applying heuristics requires lot of flow information to be = maintained, >>> which adds an additional complexity of flow maintenance (you need to >>> decide when a flow needs to be deleted if its not being hit often >>> enough) in the line cards. >>>>=20 >>>> There are many more points that go against the heuristics, = especially >>> in the context that we're discussing here. If we are ever looking at >>> disambiguating ESP-NULL packets for router consumption, then I am = pretty >>> sure it's going to be Wrapped ESP. >>>>=20 >>>> My point is that adding text about heuristics may just confuse the >>> reader who will most likely not understand the details of what it >>> entails to do heuristics on a line card. While you (being the = Security >>> guru) and I (co-authored Wrapped ESP) understand that this is only >>> theoretically possible and practically will never make sense -- the = same >>> cannot be assumed from somebody from the routing world, who is not = so >>> security savvy, going through this standard. >>>>=20 >>>> Cheers, Manav >>>>=20 >>>> _______________________________________________ >>>> secdir mailing list >>>> secdir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/secdir >>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>>>=20 >>>=20 >>> -- >>> The duke had a mind that ticked like a clock and, like a clock, it >>> regularly went cuckoo. >>>=20 >>> -- (Terry Pratchett, Wyrd Sisters) >>>=20 >>=20 >=20 > --=20 > No man is an island, But if you take a bunch of dead guys and tie them = together, they make a pretty good raft. > --Anon. >=20 >=20 --=20 Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From new-work-bounces@ietf.org Fri Dec 6 09:15:30 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 9EE781AE3C0; Fri, 6 Dec 2013 09:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1386350130; bh=wqhur9X0C/QacYk0zsMB+9hi/rfmsb4L2baB+Pw+AJI=; 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=uISOR7F3YHZsa8wSi4krkkcl/rdVJ5Is/itexlWICwfzclxoRFQIxgi4Tp4reHSl+ 3JQ51rHMnjKANlM++QgzE8+qsP0MAvcJ8lWKjjtSEKN9eMwz21Q5idGpTZl80UxgIB 2dF4v6j/3/XJ8fKXo1YBUPRuXk63khvM0bk1fXPk= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970FD1AE3B2; Fri, 6 Dec 2013 09:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0Xk_zMUaYGo; Fri, 6 Dec 2013 09:15:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7921AE0F7; Fri, 6 Dec 2013 09:15:23 -0800 (PST) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131206171523.28035.9498.idtracker@ietfa.amsl.com> Date: Fri, 06 Dec 2013 09:15:23 -0800 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" X-Mailman-Approved-At: Fri, 06 Dec 2013 09:25:18 -0800 Subject: [secdir] [new-work] WG Review: Multiple Interfaces (mif) 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, 06 Dec 2013 17:15:30 -0000 The Multiple Interfaces (mif) working group in the Internet 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-12-16. Multiple Interfaces (mif) ------------------------------------------------ Current Status: Active WG Chairs: Margaret Wasserman Hui Deng Assigned Area Director: Ted Lemon Mailing list Address: mif@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Charter: Nodes attached to multiple networks may encounter problems due to conflict of network configuration information and/or simultaneous use of the multiple available networks. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even indirectly through multiple default routers being on the same link. For instance, current laptops and smartphones typically have multiple access network interfaces. The MIF problem statement document [RFC6418] enumerates the problems into 3 categories: 1. Lack of consistent and distinctive management of configuration elements, associated with different networks. 2. Inappropriate mixed use of configuration elements, associated with different networks, in the course of a particular network activity / connection. 3. Use of a particular network, not consistent with the intent of the scenario / involved parties, leading to connectivity failure and / or other undesired consequences. The purpose of the MIF working group is to describe the architecture detailing how devices attach to and operate in multiple networks. The group shall also analyze how applications can be influenced by these existing mechanisms. The WG shall employ and refer to existing IETF work in this area, including, for instance, strong/weak models (RFC 1122), default address selection (RFC 6724), ICE and other mechanisms higher layers can use for address selection, DHCP mechanisms, Router Advertisement mechanisms, and DNS recommendations. The focus of the working group should be on documenting the system level effects to host IP stacks and identification of gaps between the existing IETF recommendations and existing practice. Having completed some of its initial goals the group is also developing the following: 1. An incrementally deployable architecture, defining a consistent approach and recommended practices for handling sets of network configuration objects by hosts, attached to multiple networks, which enable hosts to improve network connectivity for the host's applications and users. Each of these sets of network configuration objects is referred to collectively as a provisioning domain (PVD). 2. A set of requirements for changes to or the uses of protocols, that provide network configuration information, to enable improved handling of multiple sets of network configuration in networks and hosts. For example, requirements for DHCPv6 options, Neighbor Discovery options etc. to communicate association of the configuration information with particular networks. 3. In cooperation with other working groups, uses of existing protocols in accordance with the requirements produced under item 2. Any changes of function of protocols are out of scope. 4. A MIF API: While no changes are required for applications to run on multiple interface hosts, a new API could provide additional services to applications running on hosts attached to multiple networks. For instance, these services could assist advanced applications in having greater control over first-hop, source address and/or DNS resolver, interface and other network configuration element selection. This API will be defined as an abstract interface specification. That is, specific details about mapping to operating system primitives or programming languages will be left out, and the API will not be specified in terms of familiar APIs (e.g., "BSD sockets API"). In addition to the new API, the behavior of existing APIs may be changed to improve the behavior of unmodified applications. 5. Guidelines to applications, to provide an improved connectivity experience when the host is attached to multiple networks or there is a change in the set of networks the host is attached to, e.g., via MIF API usage. 6. The MIF working group will document either as part of the MIF API specification, as part of the MIF architecture document, or in a separate document, the issues and requirements for a high-level MIF user interface that would allow the user to exert control over how individual applications or application roles make use of different provisioning domains and network interfaces. 7. A specification for the format, generation and usage of PVD IDs. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. With the exception of identifying requirements for additional DHCPv6 and/or ND options, as well as requirements for possible related changes in these protocols, the group shall not assume any software beyond basic IP protocol support on its peers or in network hosts. No work will be done to enable traffic flows to move from one interface to another. The group recognizes existing work on mechanisms that require peer or network support for moving traffic flows such as RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile IPv6. This group does not work on or impact such mechanisms. Future work in this area requires rechartering the working group or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Milestones: Done - WG chartered Done - Initial draft on problem statement adopted by the WG Done - Initial draft on existing practices adopted by the WG Done - Initial draft on analysis of existing practices adopted by the WG Done - Problem statement draft submitted to the IESG for publication as an Informational RFC Done - Existing practices draft submitted to the IESG for publication as an Informational RFC Dec 2010 - Initial WG draft on DHCPv6 option for routing configuration Jan 2011 - Analysis draft submitted to the IESG for publication as an Informational RFC Jan 2011 - Initial WG draft on advanced DNS server selection solution Jan 2011 - Initial WG draft on MIF API extension Mar 2011 - Submit MIF API extension solution to IESG for publication as an Informational RFC Jun 2011 - Submit DHCPv6 routing configuration option to IESG for publication as a Proposed Standard RFC Nov 2011 - Submit advanced DNS server selection solution to IESG for publication as a Proposed Standard RFC _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From catherine.meadows@nrl.navy.mil Fri Dec 6 15:05:25 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028741AE12C; Fri, 6 Dec 2013 15:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pj1-hDYoom-l; Fri, 6 Dec 2013 15:05:22 -0800 (PST) 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 71C841AE123; Fri, 6 Dec 2013 15:05:21 -0800 (PST) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id rB6N5DO7020542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 6 Dec 2013 18:05:14 -0500 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_AAFF40F8-AFFD-47D2-8E2C-B09EFC7CA900" Date: Fri, 6 Dec 2013 18:07:14 -0500 Message-Id: <3569C749-6596-47BF-86EA-D40745364522@nrl.navy.mil> To: secdir@ietf.org, iesg@ietf.org, draft-ietf-roll-applicability-home-building.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) 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-roll-applicability-home-building-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 23:05:25 -0000 --Apple-Mail=_AAFF40F8-AFFD-47D2-8E2C-B09EFC7CA900 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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 gives recommendations on the use of the RPL protocol in building = and home environments, which are characterized as relatively small = networks that integrate a number of different devices, many including computers, = alarm systems, light switches, remote controls ,etc. Many of the = network components are resource and power-constrained. The ID characterizes = the different types of networks that can arise in these environments, and gives = recommendations such as which versions of the protocol to use and how to set the parameters, depending on the type of home network. For the security considerations the authors mainly refer the reader to = RFC6997, RFC6550, and I-D.ietf-roll-trickle-mcast. However, there is = one issue that these documents do not cover. RPL makes the assumption that all the members = of the network share a key, but intentionally does not give any = information as to how the key gets there. Thus this document includes a section on Security = Considerations for distribution of certificates required by RPL. It = explains that for RPL the credential is a shared key, and then goes on to say: Therefore, there MUST be a mechanism in place which allows secure distribution of a shared key and configuration of network identity. Both MAY be done using (i) pre-installation using an out-of-band method, (ii) delivered securely when a device is introduced into the network or (iii) delivered securely by a trusted neighboring device. The shared key MUST be stored in a secure fashion which makes it difficult to be read by an unauthorized party. An example of a method whereby this can be achieved is detailed in [SmartObj] I found the wording of this confusing. I took the =93this=94 in the = last sentence to refer to the storage of a key in a secure fashion, and wondered why it there were no references to means = of achieving secure key distribution. It wasn=92t until I looked at the = SmartOb reference that I found that it actually was such a reference. This should be made more clear, e.g. "An example of a method whereby this secure key distribution can be = achieved in detailed in [SmatObj]." I notice also that the SmartObj paper does not seem to be finished = (there are several sections labeled TODO), and that it also appears to be intended as an Internet Draft. What is the status of it? = Is it intended to be developed in tandem with this I-D? Also, it would be good to be more specific about what is meant by = =93securely=94 here. For example, the key must be authenticated and = kept secret between its intended users, and must not be repeated (replay protection).=20 It might also be helpful to include of a discussion as to when it is = more advantageous to use link encryption or group keys. In the case that a network consists of both highly security-relevant and = well-protected devices (such as alarm systems), and non-security relevant and not so well-protected devices (such as TV = remotes), group keying means that either the remote must be as well-protected as the alarm system, or the entire network must be = rekeyed if the remote is lost. I don=92t whether or not it would be necessary to give any MUST or SHOULD recommendations, but it = would be helpful to give the reader an understanding of the issues involved when making decisions about link encryption = versus group keys. As far as I can see this subject is not addressed in any of the documents cited at the beginning of the security = considerations. Cathy Meadows Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail=_AAFF40F8-AFFD-47D2-8E2C-B09EFC7CA900 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
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 gives = recommendations on the use of the RPL protocol in building and home = environments, which are characterized as relatively small = networks
that integrate a number of different devices, many = including computers, alarm systems, light switches, remote controls = ,etc.  Many of the network
components are resource and = power-constrained.   The ID  characterizes the different = types
of networks that can arise in these environments, and = gives recommendations such  as which versions of the protocol to = use and how
to set the parameters, depending on the type of home = network.

For the security considerations the = authors mainly refer the reader to RFC6997,  RFC6550, and = I-D.ietf-roll-trickle-mcast.  However, there is one issue that = these
documents do not cover.  RPL makes the assumption = that all the members of the network share a key, but intentionally does = not give any information as to how
the key gets there. =  Thus this document includes a section on Security Considerations = for distribution of certificates required by RPL.  It explains that = for RPL the
credential is a shared key, and then goes on to = say:

Therefore, there MUST be a mechanism in = place which
allows secure distribution of a shared key and = configuration of
network identity. Both MAY be done using (i) = pre-installation using
an out-of-band method, (ii) delivered securely = when a device is
introduced into the network or (iii) delivered = securely by a trusted
neighboring device. The shared key MUST be = stored in a secure
fashion which makes it difficult to be read by an = unauthorized party.
An example of a method whereby this can be = achieved is detailed in
[SmartObj]

I found = the wording of this confusing.  I took the =93this=94 in the last = sentence to refer to the storage of a key in
a secure fashion, = and wondered why it there were no references to means of achieving = secure key distribution.  It wasn=92t until I looked at the SmartOb = reference that I found that it
actually was such a reference. =  This should be made more clear,
e.g. "An example of a = method whereby this secure key distribution can be achieved in detailed = in [SmatObj]."

I notice also that the SmartObj =  paper does not seem to be finished (there are several sections = labeled TODO), and that it also
appears to be intended as an = Internet Draft.  What is the status of it?  Is it intended to = be developed in tandem with this I-D?

Also, it = would be good to be more specific about what is meant by =93securely=94 = here.  For example, the key must be authenticated and kept secret = between its intended users, and must not
be repeated (replay = protection). 


It might also = be helpful to include of a discussion as to when it is more advantageous = to use link encryption or group keys.
In the case that a = network consists of both highly security-relevant and well-protected = devices (such as alarm systems), and
non-security relevant and = not so well-protected devices (such as TV remotes), group keying means = that either the remote must
be as well-protected as the alarm = system, or the entire network must be rekeyed if the remote is lost. =  I don=92t whether or not
it would be necessary to give = any MUST or SHOULD recommendations, but it would be helpful to give the = reader an understanding
of the issues involved when making = decisions about link encryption versus group keys.  As far as I can = see this subject is not addressed
in any of the documents = cited at the beginning of the security = considerations.

Cathy = Meadows
= --Apple-Mail=_AAFF40F8-AFFD-47D2-8E2C-B09EFC7CA900-- From dgellert@silverspringnet.com Fri Dec 6 15:16:57 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3C21ADF63; Fri, 6 Dec 2013 15:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdD9KBaFCXdf; Fri, 6 Dec 2013 15:16:55 -0800 (PST) Received: from it-ipcorp-01.silverspringnet.com (it-ipcorp-01.silverspringnet.com [74.121.22.25]) by ietfa.amsl.com (Postfix) with ESMTP id 144BA1ADE87; Fri, 6 Dec 2013 15:16:55 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUEAD5aolIKOQxz/2dsb2JhbABZgkOBT7kOgTV0gicFaQEhAQweVicEARrIcxeOX4NYgRMDrVCCKg X-IronPort-AV: E=Sophos;i="4.93,843,1378882800"; d="scan'208,217";a="4270267" Received: from sfo-barrlb-01.silverspringnet.com (HELO mail.silverspringnet.com) ([10.57.12.115]) by it-ipcorp-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 06 Dec 2013 15:16:52 -0800 Received: from SFO-EXMB-03.silverspringnet.com ([fe80::e877:a0b0:2e8d:1b57]) by SFO-EXCA-02.silverspringnet.com ([::1]) with mapi id 14.02.0318.004; Fri, 6 Dec 2013 15:16:51 -0800 From: Dorothy Gellert To: "draft-bundesbank-eurosystem-namespace-02.all@tools.ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" Thread-Topic: Secdir review of draft-bundesbank-eurosystem-namespace-02 Thread-Index: AQHO8tk+/bReB0dT0k+ZU2dppNRULw== Date: Fri, 6 Dec 2013 23:16:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.57.12.115] Content-Type: multipart/alternative; boundary="_000_B01B11D1C8F1994AB77D0EF55A5030264373EESFOEXMB03silversp_" MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-bundesbank-eurosystem-namespace-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 23:16:57 -0000 --_000_B01B11D1C8F1994AB77D0EF55A5030264373EESFOEXMB03silversp_ 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 comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft registers a new URN Namespace, eurosystem, with IANA. The draft= is well written and straight forward and includes a security consideration= section referencing that in RFC 3986, 2141 and 3406. Additionally, its no= ted that non authorized resolvers will result in errors. This namespace wi= ll be owned and maintained by Eurosystem, and the URNs will be used in ISO2= 0022 message exchanges over IP networks. Perhaps it would be more comprehen= sive if any security concerns, threats or attacks from this protocol exchan= ge also be referenced within the security consideration section of this dra= ft. I believe this draft is Ready. Best Regards, Dorothy Gellert --_000_B01B11D1C8F1994AB77D0EF55A5030264373EESFOEXMB03silversp_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
I have reviewed t= his 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 dir= ectors.  Document editors and WG chairs should treat
these comments ju= st like any other last call comments. 

This draft regist= ers a new URN Namespace, eurosystem, with IANA.  The draft is well wri= tten and straight forward and includes a security consideration section ref= erencing that in RFC 3986, 2141 and 3406.  Additionally, its noted that non authorized resolvers will result in= errors.  This namespace will be owned and maintained by Eurosystem, a= nd the URNs will be used in ISO20022 message exchanges over IP networks. Pe= rhaps it would be more comprehensive if any security concerns, threats or attacks from this protocol exchange also be = referenced within the security consideration section of this draft. 

I believe this dr= aft is Ready.    

Best Regards,
Dorothy Gellert


 


--_000_B01B11D1C8F1994AB77D0EF55A5030264373EESFOEXMB03silversp_-- From catherine.meadows@nrl.navy.mil Fri Dec 6 15:20:48 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FDF1ADF93; Fri, 6 Dec 2013 15:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZPceIdwCIsv; Fri, 6 Dec 2013 15:20:45 -0800 (PST) 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 459441ADF63; Fri, 6 Dec 2013 15:20:45 -0800 (PST) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id rB6NKejv028611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 6 Dec 2013 18:20:41 -0500 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_67FB33E7-99BC-41B1-AF32-4036087030D1" Date: Fri, 6 Dec 2013 18:22:41 -0500 Message-Id: <5174B75F-0026-4A8E-B1C4-7A094371B7BD@nrl.navy.mil> To: secdir@ietf.org, iesg@ietf.org, draft-ietf-roll-applicability-home-building.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) 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-roll-applicability-home-building-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 23:20:48 -0000 --Apple-Mail=_67FB33E7-99BC-41B1-AF32-4036087030D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This is a resend of my review. I had incorrectly entered the alias for = the authors and it got bounced. My apologies to everyone who receives this twice. 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 gives recommendations on the use of the RPL protocol in building = and home environments, which are characterized as relatively small = networks that integrate a number of different devices, many including computers, = alarm systems, light switches, remote controls ,etc. Many of the = network components are resource and power-constrained. The ID characterizes = the different types of networks that can arise in these environments, and gives = recommendations such as which versions of the protocol to use and how to set the parameters, depending on the type of home network. For the security considerations the authors mainly refer the reader to = RFC6997, RFC6550, and I-D.ietf-roll-trickle-mcast. However, there is = one issue that these documents do not cover. RPL makes the assumption that all the members = of the network share a key, but intentionally does not give any = information as to how the key gets there. Thus this document includes a section on Security = Considerations for distribution of certificates required by RPL. It = explains that for RPL the credential is a shared key, and then goes on to say: Therefore, there MUST be a mechanism in place which allows secure distribution of a shared key and configuration of network identity. Both MAY be done using (i) pre-installation using an out-of-band method, (ii) delivered securely when a device is introduced into the network or (iii) delivered securely by a trusted neighboring device. The shared key MUST be stored in a secure fashion which makes it difficult to be read by an unauthorized party. An example of a method whereby this can be achieved is detailed in [SmartObj] I found the wording of this confusing. I took the =93this=94 in the = last sentence to refer to the storage of a key in a secure fashion, and wondered why it there were no references to means = of achieving secure key distribution. It wasn=92t until I looked at the = SmartOb reference that I found that it actually was such a reference. This should be made more clear, e.g. "An example of a method whereby this secure key distribution can be = achieved in detailed in [SmatObj]." I notice also that the SmartObj paper does not seem to be finished = (there are several sections labeled TODO), and that it also appears to be intended as an Internet Draft. What is the status of it? = Is it intended to be developed in tandem with this I-D? Also, it would be good to be more specific about what is meant by = =93securely=94 here. For example, the key must be authenticated and = kept secret between its intended users, and must not be repeated (replay protection).=20 It might also be helpful to include of a discussion as to when it is = more advantageous to use link encryption or group keys. In the case that a network consists of both highly security-relevant and = well-protected devices (such as alarm systems), and non-security relevant and not so well-protected devices (such as TV = remotes), group keying means that either the remote must be as well-protected as the alarm system, or the entire network must be = rekeyed if the remote is lost. I don=92t whether or not it would be necessary to give any MUST or SHOULD recommendations, but it = would be helpful to give the reader an understanding of the issues involved when making decisions about link encryption = versus group keys. As far as I can see this subject is not addressed in any of the documents cited at the beginning of the security = considerations. Cathy Meadows Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail=_67FB33E7-99BC-41B1-AF32-4036087030D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
This is  a resend of my review. =  I had incorrectly entered the alias for the authors and it got = bounced.
My apologies to everyone who receives this = twice.

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 gives = recommendations on the use of the RPL protocol in building and home = environments, which are characterized as relatively small = networks
that integrate a number of different devices, many = including computers, alarm systems, light switches, remote controls = ,etc.  Many of the network
components are resource and = power-constrained.   The ID  characterizes the different = types
of networks that can arise in these environments, and = gives recommendations such  as which versions of the protocol to = use and how
to set the parameters, depending on the type of home = network.

For the security considerations the = authors mainly refer the reader to RFC6997,  RFC6550, and = I-D.ietf-roll-trickle-mcast.  However, there is one issue that = these
documents do not cover.  RPL makes the assumption = that all the members of the network share a key, but intentionally does = not give any information as to how
the key gets there. =  Thus this document includes a section on Security Considerations = for distribution of certificates required by RPL.  It explains that = for RPL the
credential is a shared key, and then goes on to = say:

Therefore, there MUST be a mechanism in = place which
allows secure distribution of a shared key and = configuration of
network identity. Both MAY be done using (i) = pre-installation using
an out-of-band method, (ii) delivered securely = when a device is
introduced into the network or (iii) delivered = securely by a trusted
neighboring device. The shared key MUST be = stored in a secure
fashion which makes it difficult to be read by an = unauthorized party.
An example of a method whereby this can be = achieved is detailed in
[SmartObj]

I found = the wording of this confusing.  I took the =93this=94 in the last = sentence to refer to the storage of a key in
a secure fashion, = and wondered why it there were no references to means of achieving = secure key distribution.  It wasn=92t until I looked at the SmartOb = reference that I found that it
actually was such a reference. =  This should be made more clear,
e.g. "An example of a = method whereby this secure key distribution can be achieved in detailed = in [SmatObj]."

I notice also that the SmartObj =  paper does not seem to be finished (there are several sections = labeled TODO), and that it also
appears to be intended as an = Internet Draft.  What is the status of it?  Is it intended to = be developed in tandem with this I-D?

Also, it = would be good to be more specific about what is meant by =93securely=94 = here.  For example, the key must be authenticated and kept secret = between its intended users, and must not
be repeated (replay = protection). 


It might also = be helpful to include of a discussion as to when it is more advantageous = to use link encryption or group keys.
In the case that a = network consists of both highly security-relevant and well-protected = devices (such as alarm systems), and
non-security relevant and = not so well-protected devices (such as TV remotes), group keying means = that either the remote must
be as well-protected as the alarm = system, or the entire network must be rekeyed if the remote is lost. =  I don=92t whether or not
it would be necessary to give = any MUST or SHOULD recommendations, but it would be helpful to give the = reader an understanding
of the issues involved when making = decisions about link encryption versus group keys.  As far as I can = see this subject is not addressed
in any of the documents = cited at the beginning of the security = considerations.

Cathy = Meadows

Catherine Meadows
Naval = Research Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: 202-767-3490
fax: = 202-404-7942
email: catherine.meadows@nrl.navy.= mil

= --Apple-Mail=_67FB33E7-99BC-41B1-AF32-4036087030D1-- From leifj@sunet.se Mon Dec 9 00:28:15 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22711AE04C; Mon, 9 Dec 2013 00:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGHPru8pHLqS; Mon, 9 Dec 2013 00:28:13 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD3B1ADF10; Mon, 9 Dec 2013 00:28:12 -0800 (PST) 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 rB98S6fZ027986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Dec 2013 09:28:06 +0100 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 rB95iRmp021467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Dec 2013 06:44:29 +0100 (CET) X-Footer: c3VuZXQuc2U= Received: from [192.36.125.226] ([192.36.125.226]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.1) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256 bits)); Mon, 9 Dec 2013 09:28:01 +0100 Message-ID: <52A57F11.40502@sunet.se> Date: Mon, 09 Dec 2013 09:28:01 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: secdir@ietf.org, iesg@ietf.org, draft-ietf-ecrit-country-emg-urn.all@tools.ietf.org X-Enigmail-Version: 1.6 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: 09KXks65v - 24777189e211 - 20131209 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: [secdir] review of draft-ietf-ecrit-country-emg-urn-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 08:28: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. The issue I have with this document is that the Security Considerations section sais "TBD". At least say something like "This document does not update the Security Considerations of RFC 5031". Perhaps it could be argued that ECRIT URNs that are country-specific makes it more likely that they be targeted for local attacks but that may be a stretch. Cheers Leif From christer.holmberg@ericsson.com Mon Dec 9 01:19:08 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399861AE256; Mon, 9 Dec 2013 01:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCfprMvmrwXT; Mon, 9 Dec 2013 01:19:06 -0800 (PST) Received: from sessmg21.mgmt.ericsson.se (sessmg21.ericsson.net [193.180.251.40]) by ietfa.amsl.com (Postfix) with ESMTP id 71F251AD9AD; Mon, 9 Dec 2013 01:19:05 -0800 (PST) X-AuditID: c1b4fb28-b7fb38e000004238-58-52a58b03a1a4 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 38.5A.16952.30B85A25; Mon, 9 Dec 2013 10:18:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.26]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0347.000; Mon, 9 Dec 2013 10:18:59 +0100 From: Christer Holmberg To: Leif Johansson , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ecrit-country-emg-urn.all@tools.ietf.org" Thread-Topic: review of draft-ietf-ecrit-country-emg-urn-01 Thread-Index: AQHO9LicxboO2ApWEUi2pMwHArSoqJpLlfCP Date: Mon, 9 Dec 2013 09:18:58 +0000 Message-ID: References: <52A57F11.40502@sunet.se> In-Reply-To: <52A57F11.40502@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvrS5z99Iggx8vDC2WnDnMbDHjz0Rm iwW9W5ktPix8yOLA4rFkyU8mj72b+tg9vlz+zBbAHMVlk5Kak1mWWqRvl8CVMX9mYMF39oq7 k7MaGBewdTFyckgImEjc6X3LCGGLSVy4tx4ozsUhJHCCUeLctcPMEM4iRom3U5aydDFycLAJ WEh0/9MGiYsI3GGUWPVwF1i3sICVRP+idUwgtoiAtUT71bnsELaRxL/JTWDbWARUJBqn3GAB sXkF3CQ2TW0D6xUSUJX49LEFrIZTQE2iq2kRK4jNCHTR91NrwGYyC4hL3HoynwniUgGJJXvO M0PYohIvH/9jhajRk7gxdQobhK0tsWzha2aIXYISJ2c+YZnAKDILyahZSFpmIWmZhaRlASPL KkbJ4tTi4tx0I0O93PTcEr3Uoszk4uL8PL3i1E2MwJg5uOW3xg7G7mv2hxilOViUxHmrZnYG CQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamD0d931bntQ/oktT/SXXUs5c75vX7fGc4MCkWPq S98c13jYNrt7y+p9f+2PLPWZ57WfTfn/jEPOyX9PRVzPccy9Yzy1bP3Dya1X8qZu04nmuMNg IsZ7+nPgsTCe9eHX/J1e+P68NuPaMeUJqdMOf+bx1f2VvKLZomC3p4SfD8PpFNm93TL9EQ8K lViKMxINtZiLihMB1bMteGcCAAA= Subject: Re: [secdir] review of draft-ietf-ecrit-country-emg-urn-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 09:19:08 -0000 Hi Leif, The 'TBD' shall not be there. The document does not update the security con= siderations of RFC 5031, so I'll replace it with the sentence you suggested= . Thanks! Regards, Christer Sent from my Sony Ericsson Xperia arc S Leif Johansson wrote: I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The issue I have with this document is that the Security Considerations section sais "TBD". At least say something like "This document does not update the Security Considerations of RFC 5031". Perhaps it could be argued that ECRIT URNs that are country-specific makes it more likely that they be targeted for local attacks but that may be a stretch. Cheers Leif From leifj@sunet.se Mon Dec 9 04:08:18 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF31A1ADF57; Mon, 9 Dec 2013 04:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.127 X-Spam-Level: * X-Spam-Status: No, score=1.127 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frSc0XqU7P82; Mon, 9 Dec 2013 04:08:16 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6B81ADDD1; Mon, 9 Dec 2013 04:08:16 -0800 (PST) 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 rB9C86ho005425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Dec 2013 13:08:07 +0100 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 rB99ORT1025586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Dec 2013 10:24:30 +0100 (CET) X-Footer: c3VuZXQuc2U= Received: from [192.36.125.226] ([192.36.125.226]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.1) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256 bits)); Mon, 9 Dec 2013 13:08:02 +0100 Message-ID: <52A5B2A1.6080609@sunet.se> Date: Mon, 09 Dec 2013 13:08:01 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Christer Holmberg , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ecrit-country-emg-urn.all@tools.ietf.org" References: <52A57F11.40502@sunet.se> In-Reply-To: X-Enigmail-Version: 1.6 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: 09KXo87mU - 3d7b626ec759 - 20131209 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: Re: [secdir] review of draft-ietf-ecrit-country-emg-urn-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:08:19 -0000 On 12/09/2013 10:18 AM, Christer Holmberg wrote: > Hi Leif, > > The 'TBD' shall not be there. The document does not update the security considerations of RFC 5031, so I'll replace it with the sentence you suggested. Excellet. This turns this into a "no issues" document for me. > Thanks! > > Regards, > > Christer > > Sent from my Sony Ericsson Xperia arc S > > Leif Johansson wrote: > > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The issue I have with this document is that the Security Considerations > section sais "TBD". At least say something like "This document does not > update the Security Considerations of RFC 5031". > > Perhaps it could be argued that ECRIT URNs that are country-specific > makes it more likely that they be targeted for local attacks but that > may be a stretch. > > Cheers Leif > > From kathleen.moriarty@emc.com Mon Dec 9 14:21:50 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DEC1AE0F1; Mon, 9 Dec 2013 14:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drNvzBpUHUgR; Mon, 9 Dec 2013 14:21:47 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1181F1AE11F; Mon, 9 Dec 2013 14:21:46 -0800 (PST) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB9MLdRF031206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Dec 2013 17:21:41 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com rB9MLdRF031206 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1386627701; bh=iXgf8VUa9StmxZwxMeXNi5hWGIc=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=XOovJZxtjLRowNaENoSsW6Si55ENdYcHpC/PkaK61g/cG8MhiB6AuNcZqL52//5qI 7c3xFLF0susrZDSWWGXSrEn0Ce+FN+5PEu74eO3uyaKTSJjUoNLUqr+WdwQ7tXAcyR 6fEr8v74zl8MtH2rpRE9+QkGG4LglyR784urIy4Y= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com rB9MLdRF031206 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd52.lss.emc.com (RSA Interceptor); Mon, 9 Dec 2013 17:21:25 -0500 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB9MLNjc016254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 17:21:24 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Mon, 9 Dec 2013 17:21:23 -0500 From: "Moriarty, Kathleen" To: "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Date: Mon, 9 Dec 2013 17:21:23 -0500 Thread-Topic: Sec-Dir review of draft-ietf-opsec-vpn-leakages-02 Thread-Index: AQHO9Sz9Ph/A/AxGxUW94J8D5d0W7A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: DLM_1, public Cc: "fgont@si6networks.com" Subject: [secdir] Sec-Dir review of draft-ietf-opsec-vpn-leakages-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 22:21:50 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document is almost ready for publication, but could benefit from provin= g better descriptions in the introduction of the work. The Security Consid= erations probably has the most crisp statement of the draft purpose. The reference to VPN, never distinguishes if the document is referring to a= n IPSec or TLS VPN. I suspect IPSec from the document, but making this cle= ar would be helpful to the reader. TLS has become popular when providing r= estricted access and may be just an encrypted session to a particular servi= ce as opposed to a full VPN with routed traffic using IPSec. Unfortunately= , language has blurred here, mostly because of marketing, so clarity would = be helpful to avoid possible confusion for the reader. I would recommend introducing the comparison of slit-tunneling earlier in t= he document as this is a similar issue (IPv6 getting routed separately from= the VPN traffic), although split-tunneling is an intentional configuration= option. Is the draft intended for developers/implementers or operational teams/VPN = users -- or both? The proposed fixes could be done by the VPN software or = operators could disable interfaces, the former would obviously be preferred= and the abstract mentions products, so you may want to repeat that prefere= nce later in the document. =20 Thank you, Kathleen From fgont@si6networks.com Mon Dec 9 23:54:38 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940BF1AE13E; Mon, 9 Dec 2013 23:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35XRGKpY-BRM; Mon, 9 Dec 2013 23:54:36 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9931AE081; Mon, 9 Dec 2013 23:54:35 -0800 (PST) Received: from [186.137.77.127] (helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VqI95-0002hA-N6; Tue, 10 Dec 2013 08:54:19 +0100 Message-ID: <52A6C883.2080709@si6networks.com> Date: Tue, 10 Dec 2013 04:53:39 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Moriarty, Kathleen" , "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" , "iesg@ietf.org" , "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 Subject: Re: [secdir] Sec-Dir review of draft-ietf-opsec-vpn-leakages-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 07:54:38 -0000 Hi, Kathleen, Thanks so much for your feedback! Please find my comments in-line... On 12/09/2013 07:21 PM, Moriarty, Kathleen wrote: > The reference to VPN, never distinguishes if the document is > referring to an IPSec or TLS VPN. That's intentional. At the end of the day, what you use to tunnel your packets does not really affect the underlying issues. > I suspect IPSec from the document, > but making this clear would be helpful to the reader. TLS has become > popular when providing restricted access and may be just an encrypted > session to a particular service as opposed to a full VPN with routed > traffic using IPSec. Unfortunately, language has blurred here, > mostly because of marketing, so clarity would be helpful to avoid > possible confusion for the reader. As noted above, this is actually intentional, and I'd personally leave this "as is" -- put please let me know what you think. > I would recommend introducing the comparison of slit-tunneling > earlier in the document as this is a similar issue (IPv6 getting > routed separately from the VPN traffic), although split-tunneling is > an intentional configuration option. Could you please clarify what you have in mind? > Is the draft intended for developers/implementers or operational > teams/VPN users -- or both? Both. > The proposed fixes could be done by the > VPN software or operators could disable interfaces, the former would > obviously be preferred and the abstract mentions products, so you may > want to repeat that preference later in the document. So far, the I-D proposes that the fixes should be implemented by the VPN client. ONly the "Security Considerations" section mentions "disabling IPv6" as a mitigation (i.e., "last resort" thing). I guess possible options are: 1) Leaving the I-D "as is", or, 2) Have a "Mitigations" section where the current Section 6 ("Mitigations to VPN traffic-leakage vulnerabilities") is incorporated as subsection 6.1 (and possibly renamed "Fixing VPN client software"), and then adding another subsection entitled "Operational mitigations" or the like, essentially discussing manually disabling IPv6 on the local system. I'm inclined to "1)", but nevertheless open to "2)". Thoughts? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From kent@bbn.com Tue Dec 10 07:23:01 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB161AE169 for ; Tue, 10 Dec 2013 07:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtyTg6vT95NV for ; Tue, 10 Dec 2013 07:23:00 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 053931AE15E for ; Tue, 10 Dec 2013 07:23:00 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:51556) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VqP9C-000Mvj-Nr for secdir@ietf.org; Tue, 10 Dec 2013 10:22:54 -0500 Message-ID: <52A731CE.5010809@bbn.com> Date: Tue, 10 Dec 2013 10:22:54 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: secdir@ietf.org References: <52A6C883.2080709@si6networks.com> In-Reply-To: <52A6C883.2080709@si6networks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [secdir] Sec-Dir review of draft-ietf-opsec-vpn-leakages-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 15:23:01 -0000 Fernando, A quick look at your I-D suggests that the SSL VPN vs. IPsec VPN distinction is meaningful, and ought to be addressed. For example, in an SSL VPN the security model is based on higher level identifiers. Thus there are other ways that a user may find that traffic he thought was protected is not. I realize that your doc focuses only on the IPv6 vs. v4 issue, but given the title, a reader might be mislead by the lack of context. Steve From kathleen.moriarty@emc.com Tue Dec 10 08:25:33 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523CF1AE0B8; Tue, 10 Dec 2013 08:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BUP8tkNWlPz; Tue, 10 Dec 2013 08:25:29 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 691251AE08E; Tue, 10 Dec 2013 08:25:29 -0800 (PST) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBAGPHjF029409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Dec 2013 11:25:17 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com rBAGPHjF029409 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1386692718; bh=+7xKOuTbrRt2rX8CXjUZq4ratno=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=AF5ZIJnKTbYChNLTJe/mBucZEChJ7I+7au7cFD8RGAclpqasQYPa7zYih0Bk8vzmO fbyZy7JEek4YDTmW5zCQIf+liYdSbxP5BMlzhe5Mfr/cNfsHoDkkzvrGvaitRzs5kA yKdFZPj/gNEn23Ma4r5b6UAqNVnGhu5aZdrNUxzg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com rBAGPHjF029409 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd53.lss.emc.com (RSA Interceptor); Tue, 10 Dec 2013 11:25:06 -0500 Received: from mxhub25.corp.emc.com (mxhub25.corp.emc.com [10.254.110.181]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBAGP56h000931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 11:25:06 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub25.corp.emc.com ([10.254.110.181]) with mapi; Tue, 10 Dec 2013 11:25:05 -0500 From: "Moriarty, Kathleen" To: Fernando Gont , "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Date: Tue, 10 Dec 2013 11:25:04 -0500 Thread-Topic: Sec-Dir review of draft-ietf-opsec-vpn-leakages-02 Thread-Index: Ac71fRIrGaut42ohSSSR9g07uNS62gAQratg Message-ID: References: <52A6C883.2080709@si6networks.com> In-Reply-To: <52A6C883.2080709@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Subject: Re: [secdir] Sec-Dir review of draft-ietf-opsec-vpn-leakages-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 16:25:33 -0000 Hi Fernando, Thank you for the quick response! I'll answer in-line and do think it will = be important to address TLS vs. IPsec tunnels separately and will explain m= y reasoning to help you improve the draft. -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com]=20 Sent: Tuesday, December 10, 2013 2:54 AM To: Moriarty, Kathleen; draft-ietf-opsec-vpn-leakages.all@tools.ietf.org; i= esg@ietf.org; secdir@ietf.org Subject: Re: Sec-Dir review of draft-ietf-opsec-vpn-leakages-02 Hi, Kathleen, Thanks so much for your feedback! Please find my comments in-line... On 12/09/2013 07:21 PM, Moriarty, Kathleen wrote: > The reference to VPN, never distinguishes if the document is referring=20 > to an IPSec or TLS VPN. That's intentional. At the end of the day, what you use to tunnel your pack= ets does not really affect the underlying issues. KM> IPsec and TLS VPNs operate on different levels of the stack, hence the = issue you seek to address will be handled differently in each case. The us= e cases you describe are very specific to IPsec VPN tunnels in that IPsec V= PNs are intended to route all traffic from the client endpoint that has an = installed agent to a VPN gateway. This provides an opportunity for control= s to be managed through that application as well as on the client endpoint.= If you think about the split-tunneling example, this is a common configur= ation option for an IPsec VPN tunnel. A TLS VPN is typically application specific, wrapping the specific TCP prot= ocols, like HTTP to provide access to specific services on a network. TLS = VPNs are used when you want to restrict access and only provide remote user= s to very specific services on the network. TLS VPN services don't require= an agent and the policy is typically more liberal from organizations allow= ing access from anywhere via this access method. All other traffic on the = system may be routed directly to the destination, whether it is IPv4, IPv6,= or even other service level (HTTP) destination addresses. For these reasons, I think it is important to distinguish the type of VPN c= onsidered in the draft as it seems to be applicable to IPsec only. This can get a little confusing as vendors like Cisco developed methods to = transport IPsec traffic over TCP ports 80 and 443, but are still IPsec. Ot= her vendors may have used similar approaches to get around firewall issues = (Cisco Tunnel Control Protocol or cTCP), but the protocol is still IPsec an= d traffic is still routed through the gateway allowing for the options you = have specified in the draft as opposed to application level traffic to spec= ific services using HTTP/TLS for the VPN. > I suspect IPSec from the document, > but making this clear would be helpful to the reader. TLS has become=20 > popular when providing restricted access and may be just an encrypted=20 > session to a particular service as opposed to a full VPN with routed=20 > traffic using IPSec. Unfortunately, language has blurred here, mostly=20 > because of marketing, so clarity would be helpful to avoid possible=20 > confusion for the reader. As noted above, this is actually intentional, and I'd personally leave this= "as is" -- put please let me know what you think. KM> See above, thanks! > I would recommend introducing the comparison of slit-tunneling earlier=20 > in the document as this is a similar issue (IPv6 getting routed=20 > separately from the VPN traffic), although split-tunneling is an=20 > intentional configuration option. Could you please clarify what you have in mind? KM> Split-tunneling allows you to route traffic that is destined for the ne= twork you connect to with the VPN through the VPN and other traffic to reac= h its destination with a direct routing path. If you think about the IPv4 = vs. IPv6 traffic, you are in a similar situation if the IPv6 traffic is not= intended for the network on the other end of the VPN. Many organizations = will prevent split-tunneling in their VPN configurations if they would like= to make sure the users data goes through a gateway with protections (malwa= re detection, URL filtering, etc.), but others are more interested in perfo= rmance of the user's access or the ability for researchers to have options = to access sites they may not be able to through the gateway (I led security= for a research organization in the past and there are valid reasons that w= ould surprise some for this usage). Providing an up-front description could be helpful to the reader. > Is the draft intended for developers/implementers or operational=20 > teams/VPN users -- or both? Both. KM> OK, great, you may want to call out the specific recommendations for ea= ch, state when it applies to both, or state that all options apply to devel= opers/implementers, operational teams, and VPN end users. > The proposed fixes could be done by the VPN software or operators=20 > could disable interfaces, the former would obviously be preferred and=20 > the abstract mentions products, so you may want to repeat that=20 > preference later in the document. So far, the I-D proposes that the fixes should be implemented by the VPN cl= ient. ONly the "Security Considerations" section mentions "disabling IPv6" = as a mitigation (i.e., "last resort" thing). KM> I would suggest that you add in a statement then to make the objective = clear that the recommendations are for improvements in the VPN client to pr= event this issue and may involve configuration settings on the VPN gateway = that could apply out to all clients if they get updated over time. I guess possible options are: 1) Leaving the I-D "as is", or, 2) Have a "Mitigations" section where the current Section 6 ("Mitigations t= o VPN traffic-leakage vulnerabilities") is incorporated as subsection 6.1 (= and possibly renamed "Fixing VPN client software"), and then adding another= subsection entitled "Operational mitigations" or the like, essentially dis= cussing manually disabling IPv6 on the local system. I'm inclined to "1)", but nevertheless open to "2)". KM> If you want to target all user groups as stated above, then I think #2 = is the only option. If you want to restrict the draft to developers and VP= N client configuration options, then you can leave this part of the draft a= s-is and add that statement. Thank you, Kathleen Thoughts? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From housley@vigilsec.com Tue Dec 10 08:54:42 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53BD1AE171; Tue, 10 Dec 2013 08:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRmGJD8pVAIq; Tue, 10 Dec 2013 08:54:39 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 62A2D1AE1D6; Tue, 10 Dec 2013 08:54:39 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 2C3AC9A41D3; Tue, 10 Dec 2013 11:54:24 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id bMbJijDg4edu; Tue, 10 Dec 2013 11:54:02 -0500 (EST) Received: from [192.168.2.110] (pool-96-255-140-248.washdc.fios.verizon.net [96.255.140.248]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 8CC859A41DA; Tue, 10 Dec 2013 11:54:02 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-121-365338452 From: Russ Housley In-Reply-To: Date: Tue, 10 Dec 2013 11:53:51 -0500 Message-Id: <2544ADA6-AF4A-45F3-8D83-86BB4531053A@vigilsec.com> References: To: Radia Perlman X-Mailer: Apple Mail (2.1085) Cc: The IESG , draft-housley-ct-keypackage-receipt-n-error.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-housley-ct-keypackage-receipt-n-error-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 16:54:43 -0000 --Apple-Mail-121-365338452 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Radia: Here is my rewrite of the security considerations to include the = concerns that you raised. Let me know what you think. Russ - - - - - - - - - 8. Security Considerations The key package receipt and key package error contents are not necessarily protected. These content types can be combined with a security protocol to protect the contents of the package. The KeyPkgReceiptReq structure includes a receipts=46rom list and a receiptsTo list. Both lists contain SIREntityNames. The syntax does not specify a limit on the number of SIREntityNames that may be included in either of these lists. In addition, there is purposefully no requirement that the receiptTo entries have any relation to the sender of the key package. To avoid these features being used as part of a denial of service amplification, receipts should only be returned for key packages with a valid signature from a trusted signer. If an implementation is willing to accept key packages from more than one source, then there is a possibility that the same key package identifier could be used by more than one source. As a result, there is the potential for a receipt for one key package to be confused with the receipt for another, potentially leading to confusion about the keying material that is available to the recipient. In environments with multiple key sources, a convention for assignment of key package identifiers can avoid this potential confusion altogether. In some situations, returning very detailed error information can provide an attacker with insight into the security processing. Where this is a concern, the implementation should return the most generic error code that is appropriate. However, detailed error codes are very helpful during development, debugging, and interoperability testing. For this reason, implementations may want to have a way to configure the use of a generic error code or a detailed one. On Nov 10, 2013, at 1:09 AM, Radia Perlman 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 >=20 > This document defines a syntax for two Cryptographic Message Syntax = (CMS) content types that can be used in responses to messages containing = key packages. One is for acknowledging receipt and the other is for = reporting errors. The exact syntax is unimportant to security and the = message purpose seems sensible and non-controversial. > =20 > A few thoughts (mostly on procedural rather than technical issues): > =20 > In addition to defining the key-package-receipt and key-package-error = content types, this document defines a KeyPkgIdentifierAndReceiptReq = attribute. It wasn=92t clear (at least to me) whether this document was = also defining this attribute or whether this information was included in = this document for the purpose of providing context. > =20 > The document defines a long list of error codes with the comment = =93Expect additional error codes=94 without specifying a mechanism for = additional error codes to be defined. It also says that there are no = IANA considerations, but I would assume that IANA would operate the = registry for things like the error codes listed here. If not IANA, where = would the definitive registry be? > =20 > The KeyPkgReceiptReq includes a specification as to where to send the = receipts, and that specification is a sequence of distinguished names. = There is no specified limit on the number of distinguished names and no = stated requirement that the names have any relation to the sender of the = Key Package. This potentially represents a denial of service = amplification engine. > =20 > There is no indication that the key package identifier be unguessable = or tied cryptographically to the key package contents. As a result, = there is the potential that an attacker could stop delivery of a key = package and send his own substitute key package with the same = identifier. This would result in the recipient acknowledging a key = package that he did not in fact receive. This could potentially confuse = the sender about the state of the exchange. > =20 > minor typo? The last line of page 5 says =93which receivers of the key = package are expected to return receipts=94. I believe that should read = =93which receivers of the key package are requested to return receipts=94.= >=20 > Radia --Apple-Mail-121-365338452 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

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.

<= /u> 

This document defines a syntax for two = Cryptographic Message Syntax (CMS) content types that can be used in = responses to messages containing key packages. One is for acknowledging = receipt and the other is for reporting errors. The exact syntax is = unimportant to security and the message purpose seems sensible and = non-controversial.
 
A = few thoughts (mostly on procedural rather than technical = issues):
 
 
The KeyPkgReceiptReq includes a = specification as to where to send the receipts, and that specification = is a sequence of distinguished names. There is no specified limit on the = number of distinguished names and no stated requirement that the names = have any relation to the sender of the Key Package. This potentially = represents a denial of service amplification = engine.
 
minor typo? The last line of page 5 = says =93which receivers of the key package are expected to return = receipts=94. I believe that should read =93which receivers of the key = package are requested to return receipts=94.
Radia

= --Apple-Mail-121-365338452-- From kent@bbn.com Tue Dec 10 09:07:32 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2FD1AE1C1 for ; Tue, 10 Dec 2013 09:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-Qq9VZBjo8y for ; Tue, 10 Dec 2013 09:07:31 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C1A0D1AE1C5 for ; Tue, 10 Dec 2013 09:07:30 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:52349) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VqQmK-000PFQ-4j; Tue, 10 Dec 2013 12:07:24 -0500 Message-ID: <52A74A4B.7080908@bbn.com> Date: Tue, 10 Dec 2013 12:07:23 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: secdir , "sratliff@cisco.com" , aretana@cisco.com, Stewart Bryant , ospf-chairs@tools.ietf.org Content-Type: multipart/alternative; boundary="------------080702020303080807070408" Subject: [secdir] SECDIR review of draft-ietf-ospf-manet-single-hop-or-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 17:07:32 -0000 This is a multi-part message in MIME format. --------------080702020303080807070408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit SECDIR review of draft-ietf-ospf-manet-single-hop-or-03 I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments. As per the Abstract, this document describes use of the OSPF-MANET interface in single-hop broadcast networks. It is targeted as an Experimental RFC. It is a very brief I-D, only 8 pages. It updates RFC 5820 (Extensions to OSPF to Support MANETs) to describe use of the MANET interface in single-hop broadcast networks, consistent with the abstract. The Security Considerations section contains only one sentence, stating that there are no new security considerations beyond those expressed in RFC 5820. Since this is an update to that RFC, this text makes sense. RFC 5820 contains a two-page Security Considerations section. Much of the text from that section is taken from RFC 5614 (MANET Extension of OSPF). The Security Considerations text in 5820 is well written and is intended to address a broader range of MANET contexts that the single-hop broadcast networks address here. Thus citing that text in this document seems adequate. --------------080702020303080807070408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

SECDIR review of draft-ietf-ospf-manet-single-hop-or-03

 

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

 

As per the Abstract, this document describes use of the OSPF-MANET interface in single-hop broadcast networks. It is targeted as an Experimental RFC. It is a very brief I-D, only 8 pages. It updates RFC 5820 (Extensions to OSPF to Support MANETs) to describe use of the MANET interface in single-hop broadcast networks, consistent with the abstract.

 

The Security Considerations section contains only one sentence, stating that there are no new security considerations beyond those expressed in RFC 5820. Since this is an update to that RFC, this text makes sense. RFC  5820 contains a two-page Security Considerations section. Much of the text from that section is taken from RFC 5614 (MANET Extension of OSPF). The Security Considerations text in 5820 is well written and is intended to address a broader range of MANET contexts that the single-hop broadcast networks address here. Thus citing that text in this document seems adequate.

--------------080702020303080807070408-- From paul.hoffman@vpnc.org Tue Dec 10 09:17:08 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487971AE136; Tue, 10 Dec 2013 09:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sN38mv3Z9mJr; Tue, 10 Dec 2013 09:17:06 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 628061ADF73; Tue, 10 Dec 2013 09:17:06 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rBAHGwj9053701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Dec 2013 10:16:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: Date: Tue, 10 Dec 2013 09:16:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <69CF2337-AB98-4FE2-954B-748FAEB4401D@vpnc.org> References: <52A6C883.2080709@si6networks.com> To: "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" X-Mailer: Apple Mail (2.1822) Cc: "iesg@ietf.org" , secdir Subject: Re: [secdir] Sec-Dir review of draft-ietf-opsec-vpn-leakages-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 17:17:08 -0000 On Dec 10, 2013, at 8:25 AM, Moriarty, Kathleen = wrote: > KM> IPsec and TLS VPNs operate on different levels of the stack That really depends on what you mean by "TLS VPN" (more commonly still = called "SSL VPNs"). There are two architecturally different technologies = that both are called "SSL VPNs": - An SSL VPN portal is a front-end provided by the middlebox to add = security to a normally-unsecured site. A portal does not require any = changes to the browser: you connect to the portal just as you would any = https: URL. - An SSL VPN tunnel encapsulates traffic from a client to the middlebox. = In essence, an SSL VPN tunnel acts just like an IPsec client and server, = but is instead running TLS for encryption and some unspecified, = proprietary mumbly thing for encapsulation and routing. In order to do = this, the SSL VPN needs to push a proprietary plug-in / add-in / = application to the browser. The current SSL VPN market is split into two factions. Low-end SSL VPN = boxes do just SSL VPN tunnels and not portals; many of these tunnel = clients only work with IE as a browser. The middle- and high-end SSL = boxes all do both portal and tunnel mode, with the tunnel clients = working in many different browsers; the administrator decides which mode = to use for particular destinations. Many (but definitely not all) of the = latter boxes offer both IPsec and SSL VPNs; those that do usually have = them in the same admin GUI. Please note that I am *not* defending the amount of confusion sown by = mixing the two very different architectures under one name. SSL VPN = tunnel clients were originally created because IPsec clients were too = complicated, and these could just be pushed down with a single click in = a browser. Now these clients are often *more complicated* that IPsec = clients because they interact with browsers and operating systems in = more odd ways. For example, one company whom I work with uses a popular = SSL VPN system in tunnel mode. But I can't reach them now because they = have not updated the tunnel client to work with Windows 8 (much less = 8.1) because the client the vendor messed up that client and it no = longer works with XP. So this company has a company-wide rule that you = cannot upgrade to Windows 8 until the vendor fixes the SSL VPN client, = although the vendor says it already has. (The Mac client has never = worked reliably.) Yay for progress.=20 > , hence the issue you seek to address will be handled differently in = each case. The use cases you describe are very specific to IPsec VPN = tunnels in that IPsec VPNs are intended to route all traffic from the = client endpoint that has an installed agent to a VPN gateway. =20 ...and so are SSL VPN tunnels. > This provides an opportunity for controls to be managed through that = application as well as on the client endpoint. If you think about the = split-tunneling example, this is a common configuration option for an = IPsec VPN tunnel. ...and usually (but, unfortunately, not always) for SSL VPN tunnels. > A TLS VPN *in portal mode* > is typically application specific, wrapping the specific TCP = protocols, like HTTP to provide access to specific services on a = network. TLS VPNs are used when you want to restrict access and only = provide remote users to very specific services on the network. TLS VPN = services don't require an agent and the policy is typically more liberal = from organizations allowing access from anywhere via this access method. = All other traffic on the system may be routed directly to the = destination, whether it is IPv4, IPv6, or even other service level = (HTTP) destination addresses. >=20 > For these reasons, I think it is important to distinguish the type of = VPN considered in the draft as it seems to be applicable to IPsec only. ...as well as the quite common SSL VPNs in tunnel mode. >> I would recommend introducing the comparison of slit-tunneling = earlier=20 >> in the document as this is a similar issue (IPv6 getting routed=20 >> separately from the VPN traffic), although split-tunneling is an=20 >> intentional configuration option. >=20 > Could you please clarify what you have in mind? >=20 > KM> Split-tunneling allows you to route traffic that is destined for = the network you connect to with the VPN through the VPN and other = traffic to reach its destination with a direct routing path. If you = think about the IPv4 vs. IPv6 traffic, you are in a similar situation if = the IPv6 traffic is not intended for the network on the other end of the = VPN. Many organizations will prevent split-tunneling in their VPN = configurations if they would like to make sure the users data goes = through a gateway with protections (malware detection, URL filtering, = etc.), but others are more interested in performance of the user's = access or the ability for researchers to have options to access sites = they may not be able to through the gateway (I led security for a = research organization in the past and there are valid reasons that would = surprise some for this usage). >=20 > Providing an up-front description could be helpful to the reader. +1. Split tunneling (destined for the inside network / destined for the = Internet) confuses many security admins, and layering IPv4 / IPv6 on top = is also confusing, but it is definitely worth trying to explain. Just = don't make it IPsec specific, because some SSL VPN vendors use exactly = the same logic in the SSL VPNs as they do in the IPsec VPNs. --Paul Hoffman= From fgont@si6networks.com Tue Dec 10 09:48:17 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2691ADFE4; Tue, 10 Dec 2013 09:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZwz_5oYo_Vt; Tue, 10 Dec 2013 09:48:14 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF1A1AE13D; Tue, 10 Dec 2013 09:48:14 -0800 (PST) Received: from [186.137.77.127] (helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VqRPc-00005l-KR; Tue, 10 Dec 2013 18:48:00 +0100 Message-ID: <52A75046.7020008@si6networks.com> Date: Tue, 10 Dec 2013 14:32:54 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Moriarty, Kathleen" , "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" References: <52A6C883.2080709@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] Sec-Dir review of draft-ietf-opsec-vpn-leakages-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 17:48:17 -0000 Hi, Kathleen, Thanks so much for your prompt response! Please find my comments in-line... On 12/10/2013 01:25 PM, Moriarty, Kathleen wrote: > On 12/09/2013 07:21 PM, Moriarty, Kathleen wrote: >> The reference to VPN, never distinguishes if the document is >> referring to an IPSec or TLS VPN. > > That's intentional. At the end of the day, what you use to tunnel > your packets does not really affect the underlying issues. > > KM> IPsec and TLS VPNs operate on different levels of the stack, > hence the issue you seek to address will be handled differently in > each case. Both cases seem to "capture" traffic by installing more specific entries in the routing table (or replacing the existing ones) and employing e.g. a tun device.... > The use cases you describe are very specific to IPsec VPN > tunnels in that IPsec VPNs are intended to route all traffic from the > client endpoint that has an installed agent to a VPN gateway. Actually, this came up as a result with my experience with TLS-based OpenVPN... but the issues are very similar with IPsec -- e.g. this I-D resulted in corresponding patches in the OpenBSD IPsec implementation. [....] >> I suspect IPSec from the document, but making this clear would be >> helpful to the reader. TLS has become popular when providing >> restricted access and may be just an encrypted session to a >> particular service as opposed to a full VPN with routed traffic >> using IPSec. Unfortunately, language has blurred here, mostly >> because of marketing, so clarity would be helpful to avoid possible >> confusion for the reader. > > As noted above, this is actually intentional, and I'd personally > leave this "as is" -- put please let me know what you think. > > KM> See above, thanks! Please check the above. That said, for fairness sake, I'll love the input from others.. And, in case we go forward with your proposed change, what are the specific changes you envision? >> Is the draft intended for developers/implementers or operational >> teams/VPN users -- or both? > > Both. > > KM> OK, great, you may want to call out the specific recommendations > for each, state when it applies to both, or state that all options > apply to developers/implementers, operational teams, and VPN end > users. This I-D boils down to "When thinking about securiing data transfer t a remote site, you must keep both IPv6 and IPv4 in mind". I'm not sure I can see a real difference between what's the specific underlying technology you employ... >> The proposed fixes could be done by the VPN software or operators >> could disable interfaces, the former would obviously be preferred >> and the abstract mentions products, so you may want to repeat that >> preference later in the document. > > So far, the I-D proposes that the fixes should be implemented by the > VPN client. ONly the "Security Considerations" section mentions > "disabling IPv6" as a mitigation (i.e., "last resort" thing). > > KM> I would suggest that you add in a statement then to make the > objective clear that the recommendations are for improvements in the > VPN client to prevent this issue and may involve configuration > settings on the VPN gateway that could apply out to all clients if > they get updated over time. With "VPN ateway" you're referring to a single VPN "client" that is tunneling traffic for all local nodes? > > I guess possible options are: > > 1) Leaving the I-D "as is", or, > > 2) Have a "Mitigations" section where the current Section 6 > ("Mitigations to VPN traffic-leakage vulnerabilities") is > incorporated as subsection 6.1 (and possibly renamed "Fixing VPN > client software"), and then adding another subsection entitled > "Operational mitigations" or the like, essentially discussing > manually disabling IPv6 on the local system. > > I'm inclined to "1)", but nevertheless open to "2)". > > KM> If you want to target all user groups as stated above, then I > think #2 is the only option. If you want to restrict the draft to > developers and VPN client configuration options, then you can leave > this part of the draft as-is and add that statement. The only thing is that I can hear people complaining about the "disable IPv6" option... Although reality-wise, at times that the only option you have at hand (e.g., that's what I do when employing OpenVPN). Thoughts? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From kathleen.moriarty@emc.com Tue Dec 10 10:29:43 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDDC1AE171; Tue, 10 Dec 2013 10:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dHOQKVy_M6e; Tue, 10 Dec 2013 10:29:40 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 815ED1AE052; Tue, 10 Dec 2013 10:29:40 -0800 (PST) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBAITRKY019177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Dec 2013 13:29:27 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com rBAITRKY019177 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1386700168; bh=nokH4RrC/gv45TDDt6ZibPTQFac=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ODVcM1o7KN8KGyaVl/K5uChiaqOp6yxnVesH6FSpIg9JnPZHgp6eNoRvxcQpuF3tT +doyfBcgGtzcEqSvsZPHjwFzuzOTi9fKqnpBBkBfKBQu3fWjYjpIY5pTJGb+gZdKP4 5eoXFbyPNcaCCmaSCNbKDzYjvLjhSNEYWZpd7y98= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com rBAITRKY019177 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd52.lss.emc.com (RSA Interceptor); Tue, 10 Dec 2013 13:29:06 -0500 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBAIT45U023487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 13:29:04 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Tue, 10 Dec 2013 13:29:03 -0500 From: "Moriarty, Kathleen" To: Paul Hoffman , "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" Date: Tue, 10 Dec 2013 13:29:02 -0500 Thread-Topic: [secdir] Sec-Dir review of draft-ietf-opsec-vpn-leakages-02 Thread-Index: Ac71zDm4sVLZBpOjR1WErQbKMNdTvQABTpSA Message-ID: References: <52A6C883.2080709@si6networks.com> <69CF2337-AB98-4FE2-954B-748FAEB4401D@vpnc.org> In-Reply-To: <69CF2337-AB98-4FE2-954B-748FAEB4401D@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public, GIS Solicitation Cc: Fernando Gont , "iesg@ietf.org" , secdir Subject: Re: [secdir] Sec-Dir review of draft-ietf-opsec-vpn-leakages-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 18:29:43 -0000 Thanks for the additional input Paul. I am adding Fernando back to the dis= cussion as well since these distinctions are important and your summary cou= ld be helpful to him. Fernando - in the description, adding in the SSL Tunnel mode, which also us= es a client or an agent in a similar way to the IPsec VPN would be importan= t. I had actually done a search to find out if there was usage of TLS/SSL = to enable routing of traffic and didn't see anything, thanks Paul! I had p= reviously configured the IPsec over TCP port 80/443 in the past, so I was a= ble to confirm that easily. Documentation that covers VPN options from a f= ew sources did not cover the SSL Tunnel mode, which I think makes it more i= mportant to ensure this background is included as well as how it may apply = to the draft (any time you are routing traffic in a VPN). I'll respond to your (Fernando) message a little later as I have to do my d= ay job for a bit. :-) Thank you, Kathleen -----Original Message----- From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Tuesday, December 10, 2013 12:17 PM To: draft-ietf-opsec-vpn-leakages.all@tools.ietf.org Cc: iesg@ietf.org; secdir Subject: Re: [secdir] Sec-Dir review of draft-ietf-opsec-vpn-leakages-02 On Dec 10, 2013, at 8:25 AM, Moriarty, Kathleen = wrote: > KM> IPsec and TLS VPNs operate on different levels of the stack That really depends on what you mean by "TLS VPN" (more commonly still call= ed "SSL VPNs"). There are two architecturally different technologies that b= oth are called "SSL VPNs": - An SSL VPN portal is a front-end provided by the middlebox to add securit= y to a normally-unsecured site. A portal does not require any changes to th= e browser: you connect to the portal just as you would any https: URL. - An SSL VPN tunnel encapsulates traffic from a client to the middlebox. In= essence, an SSL VPN tunnel acts just like an IPsec client and server, but = is instead running TLS for encryption and some unspecified, proprietary mum= bly thing for encapsulation and routing. In order to do this, the SSL VPN n= eeds to push a proprietary plug-in / add-in / application to the browser. The current SSL VPN market is split into two factions. Low-end SSL VPN boxe= s do just SSL VPN tunnels and not portals; many of these tunnel clients onl= y work with IE as a browser. The middle- and high-end SSL boxes all do both= portal and tunnel mode, with the tunnel clients working in many different = browsers; the administrator decides which mode to use for particular destin= ations. Many (but definitely not all) of the latter boxes offer both IPsec = and SSL VPNs; those that do usually have them in the same admin GUI. Please note that I am *not* defending the amount of confusion sown by mixin= g the two very different architectures under one name. SSL VPN tunnel clien= ts were originally created because IPsec clients were too complicated, and = these could just be pushed down with a single click in a browser. Now these= clients are often *more complicated* that IPsec clients because they inter= act with browsers and operating systems in more odd ways. For example, one = company whom I work with uses a popular SSL VPN system in tunnel mode. But = I can't reach them now because they have not updated the tunnel client to w= ork with Windows 8 (much less 8.1) because the client the vendor messed up = that client and it no longer works with XP. So this company has a company-w= ide rule that you cannot upgrade to Windows 8 until the vendor fixes the SS= L VPN client, although the vendor says it already has. (The Mac client has = never worked reliably.) Yay for progress.=20 > , hence the issue you seek to address will be handled differently in each= case. The use cases you describe are very specific to IPsec VPN tunnels i= n that IPsec VPNs are intended to route all traffic from the client endpoin= t that has an installed agent to a VPN gateway. =20 ...and so are SSL VPN tunnels. > This provides an opportunity for controls to be managed through that appl= ication as well as on the client endpoint. If you think about the split-tu= nneling example, this is a common configuration option for an IPsec VPN tun= nel. ...and usually (but, unfortunately, not always) for SSL VPN tunnels. > A TLS VPN *in portal mode* > is typically application specific, wrapping the specific TCP protocols, l= ike HTTP to provide access to specific services on a network. TLS VPNs are= used when you want to restrict access and only provide remote users to ver= y specific services on the network. TLS VPN services don't require an agen= t and the policy is typically more liberal from organizations allowing acce= ss from anywhere via this access method. All other traffic on the system m= ay be routed directly to the destination, whether it is IPv4, IPv6, or even= other service level (HTTP) destination addresses. >=20 > For these reasons, I think it is important to distinguish the type of VPN= considered in the draft as it seems to be applicable to IPsec only. ...as well as the quite common SSL VPNs in tunnel mode. >> I would recommend introducing the comparison of slit-tunneling=20 >> earlier in the document as this is a similar issue (IPv6 getting=20 >> routed separately from the VPN traffic), although split-tunneling is=20 >> an intentional configuration option. >=20 > Could you please clarify what you have in mind? >=20 > KM> Split-tunneling allows you to route traffic that is destined for the = network you connect to with the VPN through the VPN and other traffic to re= ach its destination with a direct routing path. If you think about the IPv= 4 vs. IPv6 traffic, you are in a similar situation if the IPv6 traffic is n= ot intended for the network on the other end of the VPN. Many organization= s will prevent split-tunneling in their VPN configurations if they would li= ke to make sure the users data goes through a gateway with protections (mal= ware detection, URL filtering, etc.), but others are more interested in per= formance of the user's access or the ability for researchers to have option= s to access sites they may not be able to through the gateway (I led securi= ty for a research organization in the past and there are valid reasons that= would surprise some for this usage). >=20 > Providing an up-front description could be helpful to the reader. +1. Split tunneling (destined for the inside network / destined for the Int= ernet) confuses many security admins, and layering IPv4 / IPv6 on top is al= so confusing, but it is definitely worth trying to explain. Just don't make= it IPsec specific, because some SSL VPN vendors use exactly the same logic= in the SSL VPNs as they do in the IPsec VPNs. --Paul Hoffman _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From sajassi@cisco.com Tue Dec 10 16:54:25 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41441AE2F6; Tue, 10 Dec 2013 16:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DdvpWdo_A95; Tue, 10 Dec 2013 16:54:23 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 294A91AE2F3; Tue, 10 Dec 2013 16:54:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4021; q=dns/txt; s=iport; t=1386723258; x=1387932858; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=opr6wOT3KWAXzvKbO095rr6YZUFkRKK9eVN3MCN696A=; b=NUF3IYyw8ifPYTFkwkYZ3VKDCEGfqOCFaZAuaH6t4JHlQcHIeb4LoMuw kQEPsrK55UKwepBHwlq0OBzm8A2sQQXoboJx/25lrvqdaL8bnpMtatElH xpT7vQ4HeLUxv0+tDuBwFZUzNJd82Af/DReGZ67jKg7I7WSP9+50SIN1S g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAG+3p1KtJXG//2dsb2JhbABZgmYhgQu5IYEgFnSCLDorCB4BCDZCJQEBBAESG4dnAcFDF48MhDQEmBSSE4Mpgio X-IronPort-AV: E=Sophos;i="4.93,868,1378857600"; d="scan'208";a="5840908" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-6.cisco.com with ESMTP; 11 Dec 2013 00:54:12 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBB0sC4Y015669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 00:54:12 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Tue, 10 Dec 2013 18:54:11 -0600 From: "Ali Sajassi (sajassi)" To: Tina TSOU , "Org Iesg@Ietf." , "Org Secdir@Ietf." , "draft-ietf-l2vpn-evpn-req.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-l2vpn-evpn-req-05 Thread-Index: Ac7r4iSTTLuLU6ECRayqapxZmS2AZQKGJe6A Date: Wed, 11 Dec 2013 00:54:11 +0000 Message-ID: In-Reply-To: <36B74C19-0B78-40BC-8B7E-A161AD644DB3@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.128.2.142] Content-Type: text/plain; charset="us-ascii" Content-ID: <2BDD8814FB8E7042B16D7C1FCFA36133@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 11 Dec 2013 02:10:58 -0800 Subject: Re: [secdir] SecDir review of draft-ietf-l2vpn-evpn-req-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 00:54:25 -0000 Hi Tina, Thanks for your review. I have incorporated all your comments. Please refer inline for details on resolutions ... On 11/27/13 6:32 PM, "Tina TSOU" wrote: >Dear all, >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the IESG. >These comments were written primarily for the benefit of the security >area directors. Document editors and WG chairs should treat these >comments just like any other last call comments. > >This document specify the requirement for an Ethernet VPN (EVPN) >solution, to address the issues mentioned in this draft. > >Some comments are below. > >1. In Section 4.2, it says: > "The solution MUST also be able to leverage > work in the MPLS WG that is in progress to improve the load balancing > capabilities of the network based on entropy labels [RFC6790]." > > Since this work is already published as RFC, the sentence should be >rewritten as:=20 > "The solution MUST also be able to leverage the MPLS load balancing > capabilities based on entropy labels [RFC6790]." Agreed. >=20 > >2. In Section 4.2, it says: > "For example consider a scenario in which CE1 is multi-homed to PE1 > and PE2, and CE2 is multi-homed to PE3 and PE4 running in all-active > mode. Furthermore, consider that there exist three ECMPs between any > of the CE1's and CE2's multi-homed PEs. Traffic from CE1 to CE2 can > be forwarded on twelve different paths over MPLS/IP core as follow: > CE1 load balances traffic to both PE1 and PE2. Each of the PE1 and > PE2 have three ECMPs to PE3 and PE4 for the total of twelve paths. > Finally, when traffic arrives at PE3 and PE4, it gets forwarded to > CE2 over the Ethernet channel (aka link bundle)." > > It seems "ECMP", "ECMP path" and "path" are messed up in this paragraph. >To make it straight, the following is suggested: > "For example consider a scenario in which CE1 is multi-homed to PE1 > and PE2, and CE2 is multi-homed to PE3 and PE4 running in all-active > mode. Furthermore, consider that there exist three ECMP paths between >any=20 > of the CE1's and CE2's multi-homed PEs. Traffic from CE1 to CE2 can > be forwarded on twelve different paths over MPLS/IP core as follow: > CE1 load balances traffic to both PE1 and PE2. Each of the PE1 and > PE2 have three paths to PE3 and PE4 for the total of twelve paths. > Finally, when traffic arrives at PE3 and PE4, it gets forwarded to > CE2 over the Ethernet channel (aka link bundle)." Agreed. >=20 > >3. In Section 12 "Security Considerations", it says: > "...The requirement is to introduce no > new vulnerabilities beyond those of [RFC4761] and [RFC4762] when MAC > learning is performed in data-plane and beyond that of [RFC4364] when > MAC learning is performed in control plane." > >Though BGP is used similarly in E-VPN, some new vulnerabilities will >inevitably be introduced, such as MAC forgery in BGP, and how to protect >against individual MACs may pose a challenge. > >4. Section 12 "Security Considerations" >It is very brief. It does not mention when using multi-homing. I have updated the section 12 as follow: Any protocol extensions developed for the EVPN solution shall include the appropriate security analysis. Besides the security requirements covered in [RFC4761] and [RFC4762] when MAC learning is performed in data-plane and in [RFC4364] when MAC learning is performed in control plane, the following additional requirements need to be covered. (R13) A solution MUST be capable of detecting and properly handling a situation where the same MAC address appears behind two different Ethernet Segment (whether inadvertently or intentionally). (R14) A solution MUST be capable of associating a MAC address to a specific Ethernet Segment such that MAC mobility for this kind of MAC addresses are disallowed. Regards, Ali=20 > > >Thank you, >Tina From kathleen.moriarty@emc.com Wed Dec 11 08:45:23 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659FB1AE107; Wed, 11 Dec 2013 08:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIDcnXo7VdZX; Wed, 11 Dec 2013 08:45:19 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 319521AE139; Wed, 11 Dec 2013 08:45:19 -0800 (PST) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBBGj6HF007342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Dec 2013 11:45:07 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com rBBGj6HF007342 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1386780307; bh=He+sSKG9Vimum0S1dKK5sv8TaG8=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=rC/AmW1DxNDy7RMVBS8JbQxA4l7WTC0igNSijAPxVpNBqcvLdZUE6rLUXKBoRgFRN rxxD8v6Juia7HLJPwmjAPuoMotkeVYvE/Wgz46kEpbGMR0ObSAhiP1IPWBi4HE5gyu wsUM/IO24HmM7IfXef93OoRjZhmdjaU8Ktp4p9xM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com rBBGj6HF007342 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd54.lss.emc.com (RSA Interceptor); Wed, 11 Dec 2013 11:44:50 -0500 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBBGims9015613 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 11:44:48 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Wed, 11 Dec 2013 11:44:48 -0500 From: "Moriarty, Kathleen" To: Fernando Gont , "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Date: Wed, 11 Dec 2013 11:44:47 -0500 Thread-Topic: Sec-Dir review of draft-ietf-opsec-vpn-leakages-02 Thread-Index: Ac710AEH8327NT4TTPWkOfjwd7EIPgAubXNA Message-ID: References: <52A6C883.2080709@si6networks.com> <52A75046.7020008@si6networks.com> In-Reply-To: <52A75046.7020008@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Subject: Re: [secdir] Sec-Dir review of draft-ietf-opsec-vpn-leakages-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 16:45:23 -0000 Hello, Fernando. I believe you have also seen Paul & Steve's responses to this thread and I'= ll respond in-line. -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com]=20 Sent: Tuesday, December 10, 2013 12:33 PM To: Moriarty, Kathleen; draft-ietf-opsec-vpn-leakages.all@tools.ietf.org; i= esg@ietf.org; secdir@ietf.org Subject: Re: Sec-Dir review of draft-ietf-opsec-vpn-leakages-02 Hi, Kathleen, Thanks so much for your prompt response! Please find my comments in-line... On 12/10/2013 01:25 PM, Moriarty, Kathleen wrote: > On 12/09/2013 07:21 PM, Moriarty, Kathleen wrote: >> The reference to VPN, never distinguishes if the document is=20 >> referring to an IPSec or TLS VPN. >=20 > That's intentional. At the end of the day, what you use to tunnel your=20 > packets does not really affect the underlying issues. >=20 > KM> IPsec and TLS VPNs operate on different levels of the stack, > hence the issue you seek to address will be handled differently in=20 > each case. Both cases seem to "capture" traffic by installing more specific entries in= the routing table (or replacing the existing ones) and employing e.g. a tun device.... KM> OK, yes, an IPsec or an SSL Tunnel mode VPN are both subject to these i= ssues. It would be helpful to note that and include a description on the V= PN types that apply. It would also be helpful to narrow the scope to the a= reas where you would like this solution to apply (I believe, agents or soft= ware at the client system). > The use cases you describe are very specific to IPsec VPN tunnels in=20 > that IPsec VPNs are intended to route all traffic from the client=20 > endpoint that has an installed agent to a VPN gateway. Actually, this came up as a result with my experience with TLS-based OpenVP= N... but the issues are very similar with IPsec -- e.g. this I-D resulted i= n corresponding patches in the OpenBSD IPsec implementation. KM> Thank you, I had tried searching for solutions that used TLS to route a= ll traffic before sending my first message assuming someone had implemented= a solution, but only found the use of IPsec over TCP 80 and 443, so I stan= d corrected. I'll provide some text below with your request as I think it = is important to address these points to fully explain where this is applica= ble for it to be useful. If I had a hard time finding materials and knew w= hat I was looking for ('interesting' uses of protocols), then others will a= lso have a problem. [....] >> I suspect IPSec from the document, but making this clear would be=20 >> helpful to the reader. TLS has become popular when providing=20 >> restricted access and may be just an encrypted session to a=20 >> particular service as opposed to a full VPN with routed traffic using=20 >> IPSec. Unfortunately, language has blurred here, mostly because of=20 >> marketing, so clarity would be helpful to avoid possible confusion=20 >> for the reader. >=20 > As noted above, this is actually intentional, and I'd personally leave=20 > this "as is" -- put please let me know what you think. >=20 > KM> See above, thanks! Please check the above. That said, for fairness sake, I'll love the input f= rom others.. KM> I think you saw the response from Paul & Steve already. And, in case we go forward with your proposed change, what are the specific= changes you envision? KM> In the introduction, please add in a description of split-tunneling alo= ng with the description of this issue as there are similarities. =20 I recommend adding in a description of the types of VPNs for which this is = applicable at the start of the second paragraph. If you don't want to rest= rict the applicable types of VPN for this draft, listing the known applicab= le types as examples will be a very helpful stating point. Something like = the following could proceed the current text in that paragraph: In some cases, VPNs solutions are designed to route traffic at the IP layer= through to the destination gateway. Typically, these solutions are agent-= based, meaning that software is required on the client end point to establi= sh the tunnel and manage access control or routing rules. Split-tunneling = is an example of a routing option typically provided that can be set on the= gateway and pushed out to each of the attached clients. When enabled, spl= it-tunneling routes traffic destined for the network attached to the gatewa= y through the VPN and all other traffic is routed directly to through the I= nternet or default route for the client. The VPN gateway administrator may= choose to enable split-tunneling if performance is a primary concern for e= nd users Internet access. The administrator may choose to prevent split-tu= nneling if they have security concerns such as information leakage or would= prefer all client Internet traffic is screened for malware, for instance, = as it passes through the corporate firewall to access the Internet. Simila= rly, issues have been discovered with VPN solutions that route traffic at t= he IP layer when IPv6 is in use at the client. Since this issue is specific to VPN solutions that route IP layer traffic, = it may be applicable to the following types of VPN technologies: o IPsec VPN (include description) o SSL Tunnel VPN (include description and I recommend mentioning VPN Po= rtal to make sure readers don't get confused) =20 >> Is the draft intended for developers/implementers or operational=20 >> teams/VPN users -- or both? >=20 > Both. >=20 > KM> OK, great, you may want to call out the specific recommendations > for each, state when it applies to both, or state that all options=20 > apply to developers/implementers, operational teams, and VPN end=20 > users. This I-D boils down to "When thinking about securiing data transfer t a rem= ote site, you must keep both IPv6 and IPv4 in mind". I'm not sure I can see a real difference between what's the specific underl= ying technology you employ... KM> I think this should be more clear now with Paul's response. An agent v= s. browser based VPNs are an important distinction as the solutions that ro= ute IP layer traffic use an agent and provide a point at which mitigation o= ptions should be provided (like split-tunneling). >> The proposed fixes could be done by the VPN software or operators=20 >> could disable interfaces, the former would obviously be preferred and=20 >> the abstract mentions products, so you may want to repeat that =20 >> preference later in the document. >=20 > So far, the I-D proposes that the fixes should be implemented by the=20 > VPN client. ONly the "Security Considerations" section mentions=20 > "disabling IPv6" as a mitigation (i.e., "last resort" thing). >=20 > KM> I would suggest that you add in a statement then to make the > objective clear that the recommendations are for improvements in the=20 > VPN client to prevent this issue and may involve configuration=20 > settings on the VPN gateway that could apply out to all clients if=20 > they get updated over time. With "VPN ateway" you're referring to a single VPN "client" that is tunneli= ng traffic for all local nodes? KM> Feel free to replace the term with something else. When I use the term= VPN Gateway, I am referring to the end-point that clients connect to estab= lish the VPN session. The network being accessed by the clients is on the = other side of the gateway. Typically, options can be set at the gateway, l= ike the ability to prevent split-tunneling, so that a policy can be set for= access to the network being accessed. The configuration may get pushed to= the agents or may also be checked through the connect process to ensure po= licy is met (NAC). >=20 > I guess possible options are: >=20 > 1) Leaving the I-D "as is", or, >=20 > 2) Have a "Mitigations" section where the current Section 6=20 > ("Mitigations to VPN traffic-leakage vulnerabilities") is incorporated=20 > as subsection 6.1 (and possibly renamed "Fixing VPN client software"),=20 > and then adding another subsection entitled "Operational mitigations"=20 > or the like, essentially discussing manually disabling IPv6 on the=20 > local system. >=20 > I'm inclined to "1)", but nevertheless open to "2)". >=20 > KM> If you want to target all user groups as stated above, then I > think #2 is the only option. If you want to restrict the draft to=20 > developers and VPN client configuration options, then you can leave=20 > this part of the draft as-is and add that statement. The only thing is that I can hear people complaining about the "disable IPv= 6" option... Although reality-wise, at times that the only option you have = at hand (e.g., that's what I do when employing OpenVPN). KM> Since it is one of the options, I agree that it should be listed. If p= eople disagree with that option and want to address this another way for th= eir business requirements, that is fine too. This draft is meant to raise = awareness, provide options for software implementations to resolve the issu= e, resulting in options in software for operators to meet their policy need= s. Just like split-tunneling, operators/administrators will choose the opt= ions that work for their policy constraints. Thank you, Kathleen Thoughts? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From new-work-bounces@ietf.org Wed Dec 11 16:04:50 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 24B0F1AE228; Wed, 11 Dec 2013 16:04:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1386806690; bh=TuoPTfVhS9J6MbZTnpJI3TJawvp4trGbSlYAnGHwtvI=; 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=ZLGtDAbTT5RiAbvzyDNj1AB0XbpgD7keXe5VCrXB/F0fsgi8YXNmG+Mqgr+jGUJrE Fw1jGJyekRSEQpsxlhIIuW6xXgZYmZgofoK2fqXKijagHoKv2UuZx9c+DFeVFiUztQ tWttiVWwXZGl6gnL0e6zzEnThzYkJydvqzKpgfr8= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7368D1AE226; Wed, 11 Dec 2013 16:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r50kEUdKTSUK; Wed, 11 Dec 2013 16:04:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EBE1AE227; Wed, 11 Dec 2013 16:04:45 -0800 (PST) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131212000445.24584.65177.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2013 16:04:45 -0800 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" X-Mailman-Approved-At: Wed, 11 Dec 2013 16:26:55 -0800 Subject: [secdir] [new-work] WG Review: Service Function Chaining (sfc) 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: Thu, 12 Dec 2013 00:04:50 -0000 A new IETF working group has been proposed in the Routing 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-12-19. Service Function Chaining (sfc) ------------------------------------------------ Current Status: Proposed WG Chairs: Jim Guichard Thomas Narten Assigned Area Director: Adrian Farrel Mailing list Address: nsc@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/nsc Archive: http://www.ietf.org/mail-archive/web/nsc/ Charter: Network operators frequently utilize service functions such as packet filtering at firewalls, load-balancing and transactional proxies (for example spam filters) in the delivery of services to end users. Delivery of these types of services is undergoing significant change with the introduction of virtualization, network overlays, and orchestration. Deploying service functions to support service delivery is currently both a technical and an organizational challenge that involves significant modification to the network configuration, impacting the speed at which services can be deployed and increasing operational costs. Such services are typically implemented by the ordered combination of a number of service functions that are deployed at different points within a network. Today, common deployment models have service functions inserted on the data-forwarding path between communicating peers. Going forward, however, there is a need to move to a different model, where service functions, whether physical or virtualized, are not required to reside on the direct data path and traffic is instead steered through required service functions, wherever they are deployed. For a given service, the abstracted view of the required service functions and the order in which they are to be applied is called a Service Function Chain (SFC). An SFC is instantiated through selection of specific service function instances on specific network nodes to form a service graph: this is called a Service Function Path (SFP). The service functions may be applied at any layer within the network protocol stack (network layer, transport layer, application layer, etc.). The SFC working group will document a new approach to service delivery and operation. It will produce an architecture for service function chaining that includes the necessary protocols or protocol extensions to convey the Service Function Chain and Service Function Path information to nodes that are involved in the implementation of service functions and Service Function Chains, as well as mechanisms for steering traffic through service functions. The WG will examine existing identifier schemes, if there is a need for such identifiers in the context of the Generic SFC encapsulation, before defining any new identifier scheme. The working group will examine what information needs to be gathered from the network and service functions in support of Service Function Chaining and how that information may be made available to the components of the Service Function Chaining architecture. The SFC WG will closely consider and address the management and security implications when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 1. Problem Statement: This document will provide a summary of the problem space to be addressed by the SFC working group including example high-level use cases. Additionally, the working group will normalize nomenclature and definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC architectural building blocks and their relationships including interconnection, placement of SFC specific capabilities, management, diagnostics, design analysis, and security models, as well as requirements on the protocol mechanisms. The initial scope is restricted to a single administrative domain, keeping in mind that architectural decisions made for the intra-domain case may have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single service-level data plane encapsulation format that: - indicates the sequence of service functions that make up the Service Function Chain - specifies the Service Function Path, - communicates context information between nodes that implement service functions and Service Function Chains. It is intended that the encapsulation format be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function chain applied at the network layer or at any other layer, and the same encapsulation format will apply for the construction of Service Function Paths regardless of the actual service. The working group will consider using an existing encapsulation (with extensions as appropriate) if a suitable candidate is found. 4. Control Plane Mechanisms: A document will be developed to describe requirements for conveying information between control or management elements and SFC implementation points. All protocol extension work resulting from these requirements should be carried out in the working group responsible for the protocol being modified in coordination with this working group, but may be done in this working group under a revised charter after agreement with all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC components related to the support of Service Function Chaining will certainly be needed, but first needs to be better understood and scoped. Milestones: Apr 2014 - Submit to IESG Information document defining the SFC problem statement and core use cases Apr 2014 - Consult with OPS area on possible SFC charter modifications for management and configuration of SFC components related to the support of Service Function Chaining Jan 2015 - Submit to IESG Informational document defining the architecture for SFC Jan 2015 - Informational document defining the control plane requirements for conveying information between control or management elements and SFC implementation points Aug 2015 - Submit to IESG Standards Track document specifying the generic service function chaining header encapsulation _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From kivinen@iki.fi Thu Dec 12 03:15:16 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03381AE08D for ; Thu, 12 Dec 2013 03:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNAtargR-9ca for ; Thu, 12 Dec 2013 03:15:13 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7AD1AD937 for ; Thu, 12 Dec 2013 03:15:13 -0800 (PST) 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 rBCBF4hk019459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 12 Dec 2013 13:15:04 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rBCBF4KG013201; Thu, 12 Dec 2013 13:15:04 +0200 (EET) 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: <21161.39608.86572.134917@fireball.kivinen.iki.fi> Date: Thu, 12 Dec 2013 13:15:04 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 2 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 11:15:17 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Ondrej Sury is next in the rotation. For telechat 2013-12-19 Reviewer LC end Draft Dave Cridland T 2013-11-04 draft-ietf-httpbis-p5-range-25 Tobias Gondrom TR2013-11-25 draft-ietf-json-rfc4627bis-09 Simon Josefsson T 2013-12-06 draft-ietf-jose-use-cases-05 Scott Kelly T 2013-12-10 draft-ietf-opsawg-rfc5066bis-07 Julien Laganier T 2013-12-06 draft-ietf-avtcore-rtp-security-options-09 Matt Lepinski T 2013-11-04 draft-ietf-httpbis-p2-semantics-25 Matt Lepinski T 2013-12-09 draft-rosen-rph-reg-policy-01 Magnus Nystrom TR2013-11-06 draft-ietf-pim-explicit-tracking-09 For telechat 2014-01-09 Derek Atkins TR2013-10-01 draft-ietf-siprec-architecture-11 Adam Montville T 2013-12-31 draft-farrell-perpass-attack-02 For telechat 2014-01-23 Yoav Nir T 2014-01-21 draft-housley-number-registries-00 Last calls and special requests: Rob Austein 2013-11-27 draft-turner-application-cms-media-type-07 Dave Cridland E 2013-11-21 draft-dunbar-armd-arp-nd-scaling-practices-07 Steve Hanna E 2013-11-28 draft-ietf-pcp-nat64-prefix64-04 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05 Jeffrey Hutzelman 2013-12-09 draft-ietf-avtcore-leap-second-06 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-09 Julien Laganier 2013-12-11 draft-ietf-stox-core-08 Ben Laurie 2013-12-11 draft-ietf-stox-presence-06 Chris Lonvick E 2013-12-12 draft-ietf-roll-applicability-ami-07 Alexey Melnikov E 2013-12-12 draft-ietf-roll-rpl-industrial-applicability-02 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Magnus Nystrom 2014-01-05 draft-ietf-ccamp-oam-configuration-fwk-11 Hilarie Orman 2013-12-24 draft-ietf-isis-rfc1142-to-historic-00 Radia Perlman 2013-12-23 draft-ietf-netmod-iana-if-type-09 Vincent Roca 2013-12-25 draft-ietf-6man-stable-privacy-addresses-16 Vincent Roca 2013-12-23 draft-ietf-savi-send-10 Joe Salowey 2013-12-23 draft-ietf-soc-overload-control-14 Yaron Sheffer 2013-11-27 draft-ietf-idr-extcomm-iana-02 Yaron Sheffer 2013-12-23 draft-ietf-trill-o-pw-03 Zach Shelby 2013-12-23 draft-ietf-trill-rfc6327bis-02 Klaas Wierenga 2013-11-27 draft-ietf-pwe3-dynamic-ms-pw-20 Tom Yu R2013-12-09 draft-ietf-rtgwg-cl-requirement-13 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 Glen Zorn 2013-11-27 draft-turner-ct-keypackage-receipt-n-error-algs-04 -- kivinen@iki.fi From scott@hyperthought.com Thu Dec 12 04:27:20 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75D81AE284 for ; Thu, 12 Dec 2013 04:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Edx37YJVhGBO for ; Thu, 12 Dec 2013 04:27:18 -0800 (PST) Received: from smtp66.iad3a.emailsrvr.com (smtp66.iad3a.emailsrvr.com [173.203.187.66]) by ietfa.amsl.com (Postfix) with ESMTP id 100AB1AC85E for ; Thu, 12 Dec 2013 04:27:18 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp17.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 234232A00B3; Thu, 12 Dec 2013 07:27:12 -0500 (EST) X-Virus-Scanned: OK Received: from app41.wa-webapps.iad3a (relay.iad3a.rsapps.net [172.27.255.110]) by smtp17.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 071722A00A8; Thu, 12 Dec 2013 07:27:11 -0500 (EST) Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app41.wa-webapps.iad3a (Postfix) with ESMTP id D7FAE28004A; Thu, 12 Dec 2013 07:27:11 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Thu, 12 Dec 2013 04:27:11 -0800 (PST) Date: Thu, 12 Dec 2013 04:27:11 -0800 (PST) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-opsawg-rfc5066bis.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: <1386851231.882518471@apps.rackspace.com> X-Mailer: webmail7.0 Subject: [secdir] secdir review of draft-ietf-opsawg-rfc5066bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 12:27:20 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. 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:=0A=0A This document u= pdates RFC 5066. It amends that specification by=0A informing the intern= et community about the transition of the EFM-CU-=0A MIB module from the c= oncluded IETF Ethernet Interfaces and Hub MIB=0A Working Group to the Ins= titute of Electrical and Electronics=0A Engineers (IEEE) 802.3 working gr= oup.=0A=0AThe security considerations section appears to be identical to RF= C5066. Given the stated purpose of the document, this seems appropriate. = =0A=0A--Scott=0A From bclaise@cisco.com Thu Dec 12 04:48:18 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1241AE285; Thu, 12 Dec 2013 04:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRJxBZmQfaRm; Thu, 12 Dec 2013 04:48:16 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id A65251AD8F3; Thu, 12 Dec 2013 04:48:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1215; q=dns/txt; s=iport; t=1386852490; x=1388062090; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=XeUs10DHj4rRzfxzuh/FFEdEYbjsPQP8MTMgAD2YkMA=; b=lcEASxDIN1ZNOXEqX7X1jAMAPr87GVHeOuL6ncPdyqOlzxYsg8o7cJwi HGO/OwzuzmoFlUji+rrHOjs63gHb+uadZeLHi3F4Hr8OoFQbvmAdQeB9z ob8vVTaZMF6yTA3libwWazlDdErjUzUsfMLTuUw/cHx1jgIiPxNdBMhuG k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAFSvqVKQ/khR/2dsb2JhbABZgwqEELVYgR0WdIImAQEEIxVAEQsaAgUWCwICCQMCAQIBRQYBCQMIAQEQh3CyOJAeF4EpjXKCbIFIBJgVhkWLT4MqOw X-IronPort-AV: E=Sophos;i="4.93,878,1378857600"; d="scan'208";a="2084560" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 12 Dec 2013 12:48:09 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBCCm5v2030997; Thu, 12 Dec 2013 12:48:05 GMT Message-ID: <52A9B085.3050301@cisco.com> Date: Thu, 12 Dec 2013 13:48:05 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Scott G. Kelly" , "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-opsawg-rfc5066bis.all@tools.ietf.org, "Romascanu, Dan (Dan)" References: <1386851231.882518471@apps.rackspace.com> In-Reply-To: <1386851231.882518471@apps.rackspace.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [secdir] secdir review of draft-ietf-opsawg-rfc5066bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 12:48:18 -0000 Hi Scott, Please note, from section 1. Please note that IF-CAP-STACK-MIB module was not transfered to IEEE and remains as defined in RFC 5066. This memo provides an updated security considerations section for that module, since the original RFC did not list any security consideration for IF-CAP-STACK-MIB. Regards, Benoit > 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. > > >From the abstract: > > This document updates RFC 5066. It amends that specification by > informing the internet community about the transition of the EFM-CU- > MIB module from the concluded IETF Ethernet Interfaces and Hub MIB > Working Group to the Institute of Electrical and Electronics > Engineers (IEEE) 802.3 working group. > > The security considerations section appears to be identical to RFC5066. Given the stated purpose of the document, this seems appropriate. > > --Scott > > > From scott@hyperthought.com Thu Dec 12 05:38:25 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD43C1AE226 for ; Thu, 12 Dec 2013 05:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z415b4WTKak4 for ; Thu, 12 Dec 2013 05:38:23 -0800 (PST) Received: from smtp106.iad3a.emailsrvr.com (smtp106.iad3a.emailsrvr.com [173.203.187.106]) by ietfa.amsl.com (Postfix) with ESMTP id D97111AD9B6 for ; Thu, 12 Dec 2013 05:38:23 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B4BF52B80B6; Thu, 12 Dec 2013 08:38:17 -0500 (EST) X-Virus-Scanned: OK Received: from app8.wa-webapps.iad3a (relay.iad3a.rsapps.net [172.27.255.110]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 8F6522B80AF; Thu, 12 Dec 2013 08:38:17 -0500 (EST) Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app8.wa-webapps.iad3a (Postfix) with ESMTP id 7F7DA280042; Thu, 12 Dec 2013 08:38:17 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Thu, 12 Dec 2013 05:38:17 -0800 (PST) Date: Thu, 12 Dec 2013 05:38:17 -0800 (PST) From: "Scott G. Kelly" To: "Benoit Claise" 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 In-Reply-To: <52A9B085.3050301@cisco.com> References: <1386851231.882518471@apps.rackspace.com> <52A9B085.3050301@cisco.com> Message-ID: <1386855497.519617520@apps.rackspace.com> X-Mailer: webmail7.0 Cc: =?utf-8?Q?Romascanu=2C_Dan_=28Dan=29?= , "iesg@ietf.org" , draft-ietf-opsawg-rfc5066bis.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-opsawg-rfc5066bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 13:38:25 -0000 On Thursday, December 12, 2013 4:48am, "Benoit Claise" = said:=0A=0A> Hi Scott,=0A> =0A> Please note, from section 1.=0A> =0A> P= lease note that IF-CAP-STACK-MIB module was not transfered to IEEE=0A> = and remains as defined in RFC 5066. This memo provides an updated=0A> = security considerations section for that module, since the original=0A> = RFC did not list any security consideration for IF-CAP-STACK-MIB.=0A> =0A>= Regards, Benoit=0A=0AWow, really sorry about my error. On a train, in a hu= rry, and I had the same document open in 2 tabs, so I compared it with itse= lf. No wonder the sections were identical (doh!).=0A=0AI read through the s= ecurity considerations section, and it seems reasonable to me. =0A=0A--Scot= t=0A=0A=0A>> I have reviewed this document as part of the security director= ate's ongoing=0A>> effort to review all IETF documents being processed by t= he IESG. These comments=0A>> were written primarily for the benefit of the= security area directors. Document=0A>> editors and WG chairs should treat= these comments just like any other last call=0A>> comments.=0A>>=0A>> >Fro= m the abstract:=0A>>=0A>> This document updates RFC 5066. It amends th= at specification by=0A>> informing the internet community about the tra= nsition of the EFM-CU-=0A>> MIB module from the concluded IETF Ethernet= Interfaces and Hub MIB=0A>> Working Group to the Institute of Electric= al and Electronics=0A>> Engineers (IEEE) 802.3 working group.=0A>>=0A>>= The security considerations section appears to be identical to RFC5066. Gi= ven the=0A>> stated purpose of the document, this seems appropriate.=0A>>= =0A>> --Scott=0A>>=0A>>=0A>>=0A> =0A> =0A From bclaise@cisco.com Thu Dec 12 06:22:25 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4731AE2DD; Thu, 12 Dec 2013 06:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIuDU113nUY8; Thu, 12 Dec 2013 06:22:21 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5104F1ADBD5; Thu, 12 Dec 2013 06:22:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1903; q=dns/txt; s=iport; t=1386858135; x=1388067735; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=bo2+bQHXJJsoypYQFYta1rlbO+ZNLzGKAtnRjFwF09I=; b=MrIGc13lwN1OT/oDcibWasshderJIY6cFL9gFpTszoRpY7yqv/rLuM61 6XKbAvzbQgdfE6+KzYPw7q41c99BUOrhI7BxKPlYL+cdZ9a4DGJHTnBVW sM/3hHoBr4IHILwVlF6E56Z/i8EMfPR0nlOeiU5qmh/hUNLg+2Q+61Udp g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAJXFqVKQ/khL/2dsb2JhbABZgwqEELVYgRwWdIImAQEEIxVAARALGgIFFgsCAgkDAgECAUUGCgMBBQIBARCHcLJIkB4XgSmNaweCbIFIBJgVhkWLT4MqOw X-IronPort-AV: E=Sophos;i="4.93,878,1378857600"; d="scan'208";a="1488230" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 12 Dec 2013 14:22:14 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBCEMBW0019225; Thu, 12 Dec 2013 14:22:11 GMT Message-ID: <52A9C693.3040506@cisco.com> Date: Thu, 12 Dec 2013 15:22:11 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Scott G. Kelly" References: <1386851231.882518471@apps.rackspace.com> <52A9B085.3050301@cisco.com> <1386855497.519617520@apps.rackspace.com> In-Reply-To: <1386855497.519617520@apps.rackspace.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Romascanu, Dan \(Dan\)" , "iesg@ietf.org" , draft-ietf-opsawg-rfc5066bis.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-opsawg-rfc5066bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 14:22:25 -0000 Scott, Many thanks for your review. Ed, It might make sense to update the abstract to express: provides an updated security considerations section forIF-CAP-STACK-MIB module Regards, Benoit > On Thursday, December 12, 2013 4:48am, "Benoit Claise" said: > >> Hi Scott, >> >> Please note, from section 1. >> >> Please note that IF-CAP-STACK-MIB module was not transfered to IEEE >> and remains as defined in RFC 5066. This memo provides an updated >> security considerations section for that module, since the original >> RFC did not list any security consideration for IF-CAP-STACK-MIB. >> >> Regards, Benoit > Wow, really sorry about my error. On a train, in a hurry, and I had the same document open in 2 tabs, so I compared it with itself. No wonder the sections were identical (doh!). > > I read through the security considerations section, and it seems reasonable to me. > > --Scott > > >>> 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. >>> >>> >From the abstract: >>> >>> This document updates RFC 5066. It amends that specification by >>> informing the internet community about the transition of the EFM-CU- >>> MIB module from the concluded IETF Ethernet Interfaces and Hub MIB >>> Working Group to the Institute of Electrical and Electronics >>> Engineers (IEEE) 802.3 working group. >>> >>> The security considerations section appears to be identical to RFC5066. Given the >>> stated purpose of the document, this seems appropriate. >>> >>> --Scott >>> >>> >>> >> > > . > From yaronf.ietf@gmail.com Thu Dec 12 12:51:08 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D481AE4B4; Thu, 12 Dec 2013 12:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8jSEzfvjf3I; Thu, 12 Dec 2013 12:51:07 -0800 (PST) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AF5311AE4B1; Thu, 12 Dec 2013 12:51:06 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b57so488193eek.3 for ; Thu, 12 Dec 2013 12:51:00 -0800 (PST) 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 :content-type:content-transfer-encoding; bh=/42bGsXg+GeIUKU4yTMXweQZQiyIGTrP8JatY+ys6rw=; b=jAD6xJ7sJa5BHRCua5vtENUpJ18CRV7rJaCEfS/5KDhG/Q2phuexZuP/7aoMwKmLLg n5lQ10AW35tIfcqOIRGeL/fZImsDZIU7M1LtrDgtBtt6b0RleA8nNClzjtL9EMd1PBuD wU4g/6CQ7wlJR/Ur1UJMA2RTxKjhrDDCfCi5bTYB2j8rXz4dlnt/G+zbtgoat3SjBUXt XYEIUDxT1H23WTYu1nDEx8hPNMhxJ2mnOoMFG29vcVlrJZN9Njvssc6g2/qm4Layis2/ rTUW8inrHm7Bm5byKCcJGx7KaLTu7aErJgvzMGeV0z5ohyb/8Seocc2e86mXLOPIvk4S 03gw== X-Received: by 10.14.175.131 with SMTP id z3mr10089496eel.65.1386881460137; Thu, 12 Dec 2013 12:51:00 -0800 (PST) Received: from [10.0.0.2] (bzq-109-65-142-155.red.bezeqint.net. [109.65.142.155]) by mx.google.com with ESMTPSA id h48sm70019086eev.3.2013.12.12.12.50.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Dec 2013 12:50:59 -0800 (PST) Message-ID: <52AA21B1.6090508@gmail.com> Date: Thu, 12 Dec 2013 22:50:57 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: secdir@ietf.org, iesg@ietf.org, draft-ietf-idr-extcomm-iana.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir review of draft-ietf-idr-extcomm-iana-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 20:51: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 reorganizes some IANA registries related to BGP Extended Communities. Summary The authors state that this document has no security implications. I concur. Thanks, Yaron From yaronf.ietf@gmail.com Thu Dec 12 13:58:23 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7B41AE00C; Thu, 12 Dec 2013 13:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zZD-d9VKmlO; Thu, 12 Dec 2013 13:58:21 -0800 (PST) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9F01AD8E2; Thu, 12 Dec 2013 13:58:20 -0800 (PST) Received: by mail-ea0-f173.google.com with SMTP id o10so515157eaj.32 for ; Thu, 12 Dec 2013 13:58:13 -0800 (PST) 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 :content-type:content-transfer-encoding; bh=SpP3gVHQpny2sR9W06JOM33VsHnv38oT/bsusq9gDbE=; b=wCRuOykotqXApybvcqYJRyK44svL2qyM0zAIPNV8rZrPvHEpi9bC3Hy6l4QyJ8ma12 oZYhbooATgtpqwDQZgWbh9fjggQpyfGppf9x5D47WNbMTFhjKpeuaQsJ/9BJyXNyRi05 45beKUhaXH27EjjjsCwfQOwlHnrd5YFbhJwd3uVoyK2jcArynRkHAKcHo9mjf1kebilh 5/A4BE8n1nxjE+rt7I51giKP51+YBurGlOF3LQ2z0p4VAuIm3luw4MrjpN58t1e+VSE9 vYXkw3ktU6nC8TGpz9zNUnqorWa9Oa4LpsRPBjWn0thvIZRzsvBkhuuuoDrM+gPeo7zh 7few== X-Received: by 10.14.47.75 with SMTP id s51mr10286714eeb.97.1386885493786; Thu, 12 Dec 2013 13:58:13 -0800 (PST) Received: from [10.0.0.2] (bzq-109-65-142-155.red.bezeqint.net. [109.65.142.155]) by mx.google.com with ESMTPSA id g47sm70872940eeo.19.2013.12.12.13.58.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Dec 2013 13:58:13 -0800 (PST) Message-ID: <52AA3173.8040100@gmail.com> Date: Thu, 12 Dec 2013 23:58:11 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: IETF Security Directorate , The IESG , draft-ietf-trill-o-pw.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir review of draft-ietf-trill-o-pw-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 21:58:23 -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 specifies how multiple networks running TRILL can be connected using pseudowires. Summary Coming from the L3 security community, I am very worried by this document and its predecessors. It seems to me that we are creating the infrastructure for larger and larger L2 networks, often spanning large geographical distances, but the security mechanisms are not keeping up with this wider scope. I am not familiar with either the TRILL or PWE3 standards. Nor am I familiar with their real-life implementations. If secure deployments are common, I will be happy to be proven wrong (though I would expect such best practices to be documented and standardized). Details - This document copies the following text from the analogous PPP transport RFC: "not all implementations need to include specific security mechanisms at the pseudowire layer, for example if they are designed to be deployed only in cases where the networking environment is trusted or where other layers provide adequate security. A complete enumeration of possible deployment scenarios and associated threats and options is not possible and is outside the scope of this document.' I beg to differ. I think Security Considerations should recommend such solutions, and discuss the specific issues that come up when deploying them in this context: how should endpoints be authenticated? What protocol information should be protected? How do TRILL identities map to identities authenticated by the selected security protocol etc. In general, although not ALL implementations need security mechanisms, I assume an overwhelming majority of them does. - Moreover, text such as the following (RFC 6325) strongly hints that this traffic will be passing under the radar of many security devices: "TRILL ignorant devices with firewall features that cannot be detected by RBridges as end stations will generally not be able to inspect the content of such frames for security checking purposes." - The Security Considerations recommend end-to-end security as a replacement for link-level security. Though attractive from a security point of view, such solutions (security protocols between end hosts) are far from ubiquitous in large networks and so cannot replace link-level mechanisms. - This document is analogous to RFC 6361, which uses PPP to bridge the TRILL islands. RFC 6361 does in fact discuss specific security mechanisms (yes, one wonders about CHAP being recommended in a 2011 document). The current document does not do so. Thanks, Yaron From EdwardB@actelis.com Thu Dec 12 12:43:05 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE561ADFD6; Thu, 12 Dec 2013 12:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzpNnkZ4-ygM; Thu, 12 Dec 2013 12:43:03 -0800 (PST) Received: from mail2.actelis.com (mail2.actelis.com [212.150.9.5]) by ietfa.amsl.com (Postfix) with ESMTP id 979E31AE10E; Thu, 12 Dec 2013 12:43:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,473,1384293600"; d="scan'208";a="2373114" Received: from unknown (HELO il-mail07.actelis.net) ([212.150.9.1]) by mail2.actelis.com with ESMTP; 12 Dec 2013 22:42:54 +0200 Received: from il-mail07.actelis.net ([10.0.0.60]) by il-mail07.actelis.net ([10.0.0.60]) with mapi; Thu, 12 Dec 2013 22:42:54 +0200 From: Edward Beili To: Benoit Claise Date: Thu, 12 Dec 2013 22:42:51 +0200 Thread-Topic: secdir review of draft-ietf-opsawg-rfc5066bis-07 Thread-Index: Ac73errN+uqSUHm0QnKlrZe1Eb8Lcw== Message-ID: References: <1386851231.882518471@apps.rackspace.com> <52A9B085.3050301@cisco.com> <1386855497.519617520@apps.rackspace.com> <52A9C693.3040506@cisco.com> In-Reply-To: <52A9C693.3040506@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 13 Dec 2013 02:56:24 -0800 Cc: "iesg@ietf.org" , "Romascanu, Dan \(Dan\)" , "draft-ietf-opsawg-rfc5066bis.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-opsawg-rfc5066bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 20:43:05 -0000 Benoit, Ok, will do that tomorrow, if I ever get home - I'm stuck in the snow on my= way to Jerusalem - crazy weather here... Regards, -E. On Dec 12, 2013, at 16:22, "Benoit Claise" wrote: Scott, Many thanks for your review. Ed, It might make sense to update the abstract to express: provides an=20 updated security considerations section forIF-CAP-STACK-MIB module Regards, Benoit > On Thursday, December 12, 2013 4:48am, "Benoit Claise" said: >=20 >> Hi Scott, >>=20 >> Please note, from section 1. >>=20 >> Please note that IF-CAP-STACK-MIB module was not transfered to IEEE >> and remains as defined in RFC 5066. This memo provides an updated >> security considerations section for that module, since the original >> RFC did not list any security consideration for IF-CAP-STACK-MIB. >>=20 >> Regards, Benoit > Wow, really sorry about my error. On a train, in a hurry, and I had the s= ame document open in 2 tabs, so I compared it with itself. No wonder the se= ctions were identical (doh!). >=20 > I read through the security considerations section, and it seems reasonab= le to me. >=20 > --Scott >=20 >=20 >>> I have reviewed this document as part of the security directorate's ong= oing >>> 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 l= ast call >>> comments. >>>=20 >>>> From the abstract: >>>=20 >>> This document updates RFC 5066. It amends that specification by >>> informing the internet community about the transition of the EFM-CU= - >>> MIB module from the concluded IETF Ethernet Interfaces and Hub MIB >>> Working Group to the Institute of Electrical and Electronics >>> Engineers (IEEE) 802.3 working group. >>>=20 >>> The security considerations section appears to be identical to RFC5066.= Given the >>> stated purpose of the document, this seems appropriate. >>>=20 >>> --Scott >>>=20 >>>=20 >>>=20 >>=20 >=20 > . >=20 From clonvick@cisco.com Fri Dec 13 11:42:07 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0E61AE3D8; Fri, 13 Dec 2013 11:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0mZOluJziXx; Fri, 13 Dec 2013 11:42:05 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1F24C1AE3DD; Fri, 13 Dec 2013 11:42:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1511; q=dns/txt; s=iport; t=1386963717; x=1388173317; h=date:from:to:subject:message-id:mime-version; bh=4Vy2zrncktrxr1zxFIsGchYA1QiV7psnHfJKlhwoiRA=; b=MJy/+qp/rhD99hsfIXSJFV4oAzskCsrkBb6FxhZI5ky3XQK8vW5OAusQ kF3nfTiawCXYFR0kM0uZwq2RUM/XXNuFMzev2i2/XYy0a21RJYHxdLynS ArHMHFIVdJE0eRXIOiEIQ8/8KBvt2ljxueGCVZq/UjfAAMW0SFwVf3Qyz o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABViq1KrRDoG/2dsb2JhbABZgwo4ulkWdIJkAoF+iBUOyw4Xk1IEiUOgZ4NL X-IronPort-AV: E=Sophos;i="4.95,481,1384300800"; d="scan'208";a="100409998" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 13 Dec 2013 19:41:56 +0000 Received: from sjc-xdm-112 (sjc-xdm-112.cisco.com [171.71.188.44]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBDJfs6a024378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Dec 2013 19:41:54 GMT Date: Fri, 13 Dec 2013 11:41:54 -0800 (PST) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-ietf-roll-applicability-ami.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [secdir] SECDIR Review of draft-ietf-roll-applicability-ami X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 19:42:07 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document is incomplete but it appears that the authors know where they want to go with it. I would recommend that the Security Considerations section point to the Security Considerations section of RFC 6550 (RPL) and say that the roll-applicability-ami document is a description of the applicability of 6550 to the ami, therefore the considerations of 6550 apply. The authors note that other security mechanisms may be used, which would mean that the security functions of RPL would not be needed. I would recommend that a section of the Security Considerations be added for each instance where the RPL security mechanism are not to be used. Each of those sections should show how the replacement mechanisms will meet the requirements of the RPL security services that are described in 6550. I also see that the authors are also trying to address the initial deployment and incremental deployments, which is laudable. The authors may wish to look at restructuring the Security Considerations section to address these things through the FCAPS model or something similar. (http://en.wikipedia.org/wiki/FCAPS) Regards, Chris From new-work-bounces@ietf.org Mon Dec 16 07:36:59 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 556C71AE339; Mon, 16 Dec 2013 07:36:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1387208219; bh=cD4OBubou+uM2rlKUcqWw0D6yDaweqdpbnO2aSGSZrQ=; h=From:To:Date:Message-ID:MIME-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=nnTXE7AQgSqrkKuQ5wqhyg0ZtIlADzAshEftDrdVvtSKD1ujfbwqZQsw1h7R+95FG bn0Y/VJe9H1I/8JFEolPjkFVEYucZZFU++SLt+twyTH+KmiKPpGiF4IpPD+PbqKLLf wTg7FW/LhyZs0JoDJAGcp5nsHvvMhWEMweikik2E= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BF21AE339 for ; Mon, 16 Dec 2013 07:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.738 X-Spam-Level: X-Spam-Status: No, score=-6.738 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMnBD-GowbSf for ; Mon, 16 Dec 2013 07:36:52 -0800 (PST) Received: from ausxippc101.us.dell.com (ausxippc101.us.dell.com [143.166.85.207]) by ietfa.amsl.com (Postfix) with ESMTP id 4424D1AE060 for ; Mon, 16 Dec 2013 07:36:52 -0800 (PST) X-LoopCount0: from 10.175.216.249 X-IronPort-AV: E=Sophos;i="4.95,495,1384322400"; d="scan'208,217";a="348946521" From: To: Date: Mon, 16 Dec 2013 09:36:47 -0600 Thread-Topic: IEEE 802 November Plenary - New Study Groups Thread-Index: Ac76dA/lotvX54u6RXSuzT/RBG4Q0A== Message-ID: <28616F4740DDF542AA1DB7C9F597963907A422DB4D@AUSX7MCPS301.AMER.DELL.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Type: multipart/mixed; boundary="===============2432711587886727631==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" X-Mailman-Approved-At: Mon, 16 Dec 2013 07:42:12 -0800 Cc: p.nikolich@ieee.org Subject: [secdir] [new-work] IEEE 802 November Plenary - New Study Groups 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, 16 Dec 2013 15:36:59 -0000 --===============2432711587886727631== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_28616F4740DDF542AA1DB7C9F597963907A422DB4DAUSX7MCPS301A_" --_000_28616F4740DDF542AA1DB7C9F597963907A422DB4DAUSX7MCPS301A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Members of the IETF, In the spirit of continuing cooperation between IEEE 802 and IETF, the foll= owing letter addresses new work items for information and potential coordin= ation with the respective IEEE 802 WG. One of the first steps in the IEEE Standards Association's standards develo= pment process is the creation of a Study Group. Study groups are chartered = to create a formal Project Authorization Request (PAR) document that includ= es a description of the project's scope and purpose. The following Study Groups were approved at the Nov 2013 IEEE 802 Plenary - * IEEE 802.22 Spectrum Occupancy Sensing (SOS) Study Group * IEEE 802.15.7 Optical Camera Communications Study Group * IEEE 802.15.4 Common Ranging Protocol Study Group * IEEE 802.15.4 EU Regional PHY Support Study Group Further information about these Study Groups may be found at http://www.iee= e802.org/StudyGroups.shtml. Please note, per the IEEE 802 Policies and Procedures that a Study Group is= chartered to operate from plenary session-to-plenary session, a period of = four months and, if it wishes to continue, must request a charter extension= . Therefore, the Study Groups, listed above are chartered until the IEEE 80= 2 November 2013 Plenary Session. Study Groups may also terminate between pl= enary sessions if their proposed project is approved by the IEEE Standards = Association Standards Board. Additionally, within the IEEE 802 family of standards, there is a requireme= nt that each new project proposal attaches additional documentation that de= scribes its engineering feasibility, market potential, assurance of coexist= ence and distinct identity relative to previous standards (referred to as t= he "five criteria" in 802). The "five criteria" used by IEEE 802 can be fou= nd in document: https://mentor.ieee.org/802-ec/dcn/13/ec-13-0002-01-00EC-five-criteria-om-e= xtract-informative.doc Also please note that IEEE meetings are open and may be attended by any ind= ividuals who register and fulfill any registration fees. Details regarding = future IEEE 802 plenary meeting schedules may be found at http://802world.o= rg/plenary/future-plenary-sessions/. Please refer to individual working g= roups for their interim meeting schedules. A listing of all working groups = may be found at http://www.ieee802.org/. Sincerely, John D'Ambrosia Recording Secretary, IEEE 802 LMSC jdambrosia@ieee.org --_000_28616F4740DDF542AA1DB7C9F597963907A422DB4DAUSX7MCPS301A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Members of = the IETF,

In the spirit = of continuing cooperation between IEEE 802 and IETF, the following letter a= ddresses new work items for information and potential coordination with the= respective IEEE 802 WG.

One of the first steps in the IEEE Standards Association’s st= andards development process is the creation of a Study Group. Study groups = are chartered to create a formal Project Authorization Request (PAR) docume= nt that includes a description of the project’s scope and purpose.

The following Stud= y Groups were approved at the Nov 2013 IEEE 802 Plenary – =

·       = ;  IEEE 802.22 Spectrum Occupancy Sensing (SOS) = Study Group

·   &n= bsp;     IEEE 802.15.7 Optical Ca= mera Communications Study Group

·=          IEEE= 802.15.4 Common Ranging Protocol Study Group

·         IEEE 802.15.4 EU Regional PHY Support Study Group

Further information about these = Study Groups may be found at http://www.ieee802.org/StudyGroups.shtml.  

Please note, per the IEEE 802 = Policies and Procedures that a Study Group is chartered to operate from ple= nary session-to-plenary session, a period of four months and, if it wishes = to continue, must request a charter extension. Therefore, the Study Groups,= listed above are chartered until the IEEE 802 November 2013 Plenary Sessio= n. Study Groups may also terminate between plenary sessions if their propos= ed project is approved by the IEEE Standards Association Standards Board.

Additionally, with= in the IEEE 802 family of standards, there is a requirement that each new p= roject proposal attaches additional documentation that describes its engine= ering feasibility, market potential, assurance of coexistence and distinct = identity relative to previous standards (referred to as the “five cri= teria” in 802). The “five criteria” used by IEEE 802 can = be found in document:

https://mentor.ieee.org/802-ec/dcn= /13/ec-13-0002-01-00EC-five-criteria-om-extract-informative.doc<= span style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'> 

Also please note th= at IEEE meetings are open and may be attended by any individuals who regist= er and fulfill any registration fees. Details regarding future IEEE 802 ple= nary meeting schedules may be found at http://802world.org/plenary/future-plenary-sessi= ons/.   Please refer to individual working groups for their int= erim meeting schedules. A listing of all working groups may be found at http://www.ieee802.org/.  =

Sincerely,

 

John D’Ambrosia

Recording Secretary, IEEE 802 LMSC

jdambrosia@ieee.org

=  

= --_000_28616F4740DDF542AA1DB7C9F597963907A422DB4DAUSX7MCPS301A_-- --===============2432711587886727631== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============2432711587886727631==-- From adam@stoicsecurity.com Mon Dec 16 19:02:14 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F96D1AE055; Mon, 16 Dec 2013 19:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36WF7p5P0lYn; Mon, 16 Dec 2013 19:02:13 -0800 (PST) Received: from p3plsmtpa09-07.prod.phx3.secureserver.net (p3plsmtpa09-07.prod.phx3.secureserver.net [173.201.193.236]) by ietfa.amsl.com (Postfix) with ESMTP id 25F6A1AE05C; Mon, 16 Dec 2013 19:02:12 -0800 (PST) Received: from [192.168.1.69] ([99.64.100.240]) by p3plsmtpa09-07.prod.phx3.secureserver.net with id 2T271n0055BBm5P01T28x9; Mon, 16 Dec 2013 20:02:11 -0700 From: "Adam W. Montville" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 16 Dec 2013 21:02:06 -0600 To: secdir@ietf.org, iesg@ietf.org, draft-farrell-perpass-attack-02.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [secdir] SecDir Review of draft-farrell-perpass-attack-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 03:02:14 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. In my opinion, the draft is ready. The draft does a good job explaining = pervasive monitoring, why pervasive monitoring is considered an attack, = and that the IETF will *continue* to mitigate the effects of such an = attack where possible. I found it easy enough to follow and = particularly good at removing politics from the equation. If I had any criticism at all, it would be that the draft doesn't convey = that privacy is security as it pertains to a particular type of = information (replace personally identifying information with credit card = data, and you've got something more like PCI security). To those = unfamiliar with security and/or privacy, this point might be made = clearer either in a draft like this or in something like RFC6973 (and it = may be covered well there).=20 Like I said, though, I think the draft is ready. Regards, Adam From tlyu@mit.edu Mon Dec 16 20:03:46 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EED51AE019; Mon, 16 Dec 2013 20:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CluxkfSXF3BH; Mon, 16 Dec 2013 20:03:45 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id F12F41AE05C; Mon, 16 Dec 2013 20:03:44 -0800 (PST) X-AuditID: 1209190f-b7fb86d000000c36-84-52afcd1f4ffd Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 2C.4C.03126.F1DCFA25; Mon, 16 Dec 2013 23:03:43 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id rBH43fdH004939; Mon, 16 Dec 2013 23:03:43 -0500 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rBH43dF2009204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Dec 2013 23:03:40 -0500 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id rBH43dLA013250; Mon, 16 Dec 2013 23:03:39 -0500 (EST) To: iesg@ietf.org, secdir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org From: Tom Yu Date: Mon, 16 Dec 2013 23:03:38 -0500 Message-ID: Lines: 9 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixCmqrSt/dn2QwdcTFhY7urQtZvyZyGzx YeFDFgdmjyVLfjJ5fLn8mS2AKYrLJiU1J7MstUjfLoEr4+e+BewFc1gqTky8ydrAuI25i5GD Q0LAROLTf+0uRk4gU0ziwr31bF2MXBxCArOZJHZdnccO4WxklFj3tQXKOcckcfh3LzOE08Uo ceL7ATaQfhGBeIlfnX3sILawgL3ElvOHmUBWsAlISxxdXAYSZhFQlbjxsY0VxOYVsJA4Oe0r M4jNI8AhsffOCai4oMTJmU9YQGxmAS2JG/9eMk1g5JuFJDULSWoBI9MqRtmU3Crd3MTMnOLU ZN3i5MS8vNQiXRO93MwSvdSU0k2M4ECT5N/B+O2g0iFGAQ5GJR5ejtnrg4RYE8uKK3MPMUpy MCmJ8truAQrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4WUpAMrxpiRWVqUW5cOkpDlYlMR5b3LY BwkJpCeWpGanphakFsFkZTg4lCR4K88ANQoWpaanVqRl5pQgpJk4OEGG8wANTwGp4S0uSMwt zkyHyJ9iVJQS550KkhAASWSU5sH1whLBK0ZxoFeEeTVBqniASQSu+xXQYCagwc/XrAMZXJKI kJJqYLSJvnzr4NMPO65Ok5S1Wzzjh3tYJCvvGuv/F/lY/y8R715dLLr/7MdrupEpU3smtVz5 PPG60Z5/yv62n7dd7JvT/0w6q//AmWLObQemb5hjoNywXF1N7OVef8b42V4O7Hym09ZnGjMl 3yr2zPs5K4H5/svDQc/SfBbb9EbnXNrgIDt/tsGKr7FKLMUZiYZazEXFiQDf88Q03wIAAA== Subject: [secdir] secdir re-review of draft-ietf-rtgwg-cl-requirement-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 04:03:46 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The previous concerns I have had with a prior revision of this document seem to have been resolved adequately. There appear to be no security concerns introduced by revisions since my last review. From simon@josefsson.org Tue Dec 17 07:58:29 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA131AE156; Tue, 17 Dec 2013 07:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXVttYgRft3a; Tue, 17 Dec 2013 07:58:27 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDA11AE14F; Tue, 17 Dec 2013 07:58:26 -0800 (PST) Received: from latte.josefsson.org (46.182.205.36.c.fiberdirekt.net [46.182.205.36]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id rBHFwNsb023552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 17 Dec 2013 16:58:24 +0100 Date: Tue, 17 Dec 2013 16:58:17 +0100 From: Simon Josefsson To: draft-ietf-jose-use-cases.all@tools.ietf.org, secdir@ietf.org, iesg@ietf.org Message-ID: <20131217165817.3acaba4a@latte.josefsson.org> 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 Subject: [secdir] Review of draft-ietf-jose-use-cases (Ready with nits) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 15:58:29 -0000 Hi. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes some places where signed/encrypted JSON objects may be used, and gathers a list of requirements compiled from those use-cases. It is an Informational document, and doesn't mandate any implementation requirements, but presumably may help to evaluate whether the other JOSE deliverables meet expectations. The document is well-writen, and quite entertaining to read as a survey of various modern protocol use-cases. I only found minor issues. MINOR ISSUES: * The document is split into two parts, one that describes use-cases, and one that lists the requirements. The text of the use-cases mention several requirements that the solution needs to have, however it is hard to map those to the requirements listed in the second part. It is also hard to map the requirements back to the use-cases. There is a risk that something mentioned in the use-case section is not reflected in the requirements, and vice versa. However since this is an informational document, and that it is intended to be read and parsed by humans rather than something that will be implemented, I don't think this is a serious problem. For another approach, compare RFC 4226 which mix together a use case description with requirements. NITS: * Section 1 could mention PGP as well, it is a well known and widely used security protocol. Section 2: The ordering is wrong. OLD: In this document, we will refer to these as the "signed object format", the "encrypted object format", and the "key format", respectively. NEW: In this document, we will refer to these as the "encrypted object format", the "signed object format", and the "key format", respectively. Section 5.3: Typo OLD: In the OpenID Connect context, and in some other applicaitions of NEW: In the OpenID Connect context, and in some other applications of Section 5.7: Cut'n'paste error OLD: the counter value. A custom Key Derivation Function (KDF) function is used when is based on the AES-CBC is used to derive the required MAC key. The MAC key is then used to compute the MAC NEW: the counter value. A custom Key Derivation Function (KDF) function based on AES-CBC is used to derive the required MAC key. The MAC key is then used to compute the MAC /Simon From radiaperlman@gmail.com Tue Dec 17 19:11:53 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8ED31AE27C; Tue, 17 Dec 2013 19:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAUsWFvquhLP; Tue, 17 Dec 2013 19:11:52 -0800 (PST) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E4D801AE283; Tue, 17 Dec 2013 19:11:51 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id ik5so4679457vcb.2 for ; Tue, 17 Dec 2013 19:11:50 -0800 (PST) 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=7ulJ6KmDRA68QsT+IBkls8EkEEpJsc5025i1/BG3nbI=; b=ZxRHjG8YlSrluqWCM69u/OY891e4Z+mLFEfcGgMPCPbwQUgA09tzvalRbCQW7hCSXP Qoqg7QiDOos5JxkIvWKDCadPHnBo/nTB+WoSaqDWwtaeiekCcQQ975gDnrTtjpY52OIT Fw/NyU9dfPCRQbqjMgLiQ9RaaLxLQtp9mJNkXc2L6NuaF5ox//BYceFQnzW9ck2jl5DV XptvZd55KZEB4/JbR2gUlCwVRJlkQfnv7e8JpgKRDMTASUpx5a8tETC7y66SHUbKw4jZ ESkkfVwTJvsDEvWqMlzHBzKlsLH8DYksy2K9Ckv9bJ4l6zdBehC+v4iKXF25PfotNlD5 cFrw== MIME-Version: 1.0 X-Received: by 10.220.19.134 with SMTP id a6mr59854vcb.36.1387336310502; Tue, 17 Dec 2013 19:11:50 -0800 (PST) Received: by 10.52.27.19 with HTTP; Tue, 17 Dec 2013 19:11:50 -0800 (PST) Date: Tue, 17 Dec 2013 19:11:50 -0800 Message-ID: From: Radia Perlman To: "secdir@ietf.org" , The IESG , draft-ietf-netmod-iana-if-type.all@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c3ae1cf8b91204edc66775 Subject: [secdir] Secdir review of draft-ietf-netmod-iana-if-type-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 03:11:53 -0000 --001a11c3ae1cf8b91204edc66775 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 defines the initial version of the YANG iana-if-type (interface type) module for interface type definitions. As the document's security considerations section clearly and accurately says "this document does not introduce any technology or protocol, so there are no security issues to be considered. Radia --001a11c3ae1cf8b91204edc66775 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
I have reviewe=
d 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 defines the initial version of the YANG iana-if-type (interfa=
ce type) module for interface type definitions.
As the document's security considerations section clearly and accuratel=
y says "this document does not introduce any technology or protocol, s=
o there are no security issues to be considered.
Radia
--001a11c3ae1cf8b91204edc66775-- From d3e3e3@gmail.com Tue Dec 17 21:14:26 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FB31ADFBB; Tue, 17 Dec 2013 21:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXVQWI1BEEyn; Tue, 17 Dec 2013 21:14:23 -0800 (PST) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 462841AE00B; Tue, 17 Dec 2013 21:14:23 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id j17so7765265oag.28 for ; Tue, 17 Dec 2013 21:14:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zFruQdoVRSztLk0TxsRdBwHqdBjjb134zm1iXZWDRSU=; b=frM5vyPWAZPGR8mDnf4xk67E+gxkdEJ1EYRX82Ewf3gobRqykkTtLqFto9SozN6BUP 8rAHRs3VwJ3Ehj9pm2zIdhSvlrodlALSM0Pr0Sxd8Sn0wxiHp+cPPx5LFns2EVaFjqDk xmkwZyWqkBYLSpUBUT4MDyveOjPLzptgssvbC9sgNQun+0sU3xQZVvFm9hn5YVaNja9r sVqFGM9ZQXDwBjFe9HjIwDDhQKYuX11H2q4vfw7GwGaeBi1K5o6u733ZGADjrELrD3U9 3hRxA8ovdLT0Nie6PqB1QY0hOdJf2DhVW0TIzk/iqEjkVlg+tiiCFXxeBqZfdL/hH+y+ dFTw== X-Received: by 10.182.117.195 with SMTP id kg3mr18929866obb.17.1387343661842; Tue, 17 Dec 2013 21:14:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.33.102 with HTTP; Tue, 17 Dec 2013 21:14:00 -0800 (PST) In-Reply-To: <52AA3173.8040100@gmail.com> References: <52AA3173.8040100@gmail.com> From: Donald Eastlake Date: Wed, 18 Dec 2013 00:14:00 -0500 Message-ID: To: Yaron Sheffer Content-Type: text/plain; charset=ISO-8859-1 Cc: "draft-ietf-trill-o-pw.all@tools.ietf.org" , The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-trill-o-pw-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 05:14:26 -0000 Hi Yaron, On Thu, Dec 12, 2013 at 4:58 PM, Yaron Sheffer 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 specifies how multiple networks running TRILL can be > connected using pseudowires. I am puzzled as to why you think this document has to do with "multiple networks" or what you mean by that. As background, a transit TRILL switch acts like a router in the sense that it logically discards the Layer 2 header on an incoming packet, decrements the TRILL hop count and discards the packet if it has counted down, and adds a new Layer 2 header appropriate to the outgoing link type in the process of sending that packet out a port. When a TRILL switch port is connected to a port on a different TRILL switch by a link type that TRILL can use, the TRILL switches peer with each other (unless TRILL control plane security was configured to block such peering). It makes no difference what the link technology is; in particular, there is nothing different at the TRILL level for a pseudowire link as compared with, say, an Ethernet link or some other link technology. If the two TRILL switches involved happen to be psrts of two different TRILL campuses, then this must be the first connection between those campuses and the connection causes the TRILL campuses to merge into one TRILL campus with a single shared link state database. If the two TRILL switches are alrady part of the same TRILL campus, then this is just a change in topology (unless the two TRILL switches were already connected by a different link, in which case there isn't even a change in campus topology (except that their might be a reduction in link cost due to the availability of greater bandwidth across the parallel links)). > Summary > > Coming from the L3 security community, I am very worried by this > document and its predecessors. It seems to me that we are creating > the infrastructure for larger and larger L2 networks, often spanning > large geographical distances, but the security mechanisms are not > keeping up with this wider scope. There is no mention in this draft of "larger L2 networks" or of "spanning large geographic distances" nor do I see why there should be. You can construct TRILL campuses spanning a small or large geographic distance with a small or large number of nodes regardless of what link technology or set of link technologies you use between your TRILL switches. > I am not familiar with either the TRILL or PWE3 standards. Nor am I > familiar with their real-life implementations. If secure deployments > are common, I will be happy to be proven wrong (though I would > expect such best practices to be documented and standardized). > > Details > > - This document copies the following text from the analogous PPP > transport RFC: "not all implementations need to include specific > security mechanisms at the pseudowire layer, for example if they are > designed to be deployed only in cases where the networking > environment is trusted or where other layers provide adequate > security. A complete enumeration of possible deployment scenarios > and associated threats and options is not possible and is outside > the scope of this document.' Maybe the paragarph you quote part of above should be dropped. I'm not sure it is necessary since it seems to me that what it says is normally true. For example, I would say that it is not always necessary to use IP security because some combination of the security of the environment, the security of the link layers over which IP is running, and/or the security of the application layers running over IP are adequate. I think the same is true of TRILL. > I beg to differ. I think Security Considerations should recommend > such solutions, and discuss the specific issues that come up when > deploying them in this context: how should endpoints be > authenticated? So, for example, would you say that a hypothetical "IP over the Foobaz link protocol" draft would have to have an extensive discussion of how IP routers are authenticated to each other and how IP can be secured? Wouldn't references to IP security and a reference to Foobaz link security be sufficient in most cases? This document is TRILL over pseudowires. For various reasons given in the document, this happens to be specified as, in effect TRILL over PPP over pseudowire. There are references to TRILL security, PPP security, and pseudowire security. By the way, if by "endpoints" you mean the TRILL switches at the two ends of the pseudowire, they are authenticated to each other with TRILL IS-IS Hellos as specified in the TRILL base protocol specification, RFC 6325, and further detailed in RFC 6327 (being replaced by draft-ietf-trill-rfc6327bis which is in IETF Last Call simultaneously with this TRILL over pseudowire draft). But I don't see why this draft needs to talk about that as it is independent of link technology. > What protocol information should be protected? How do TRILL > identities map to identities authenticated by the selected security > protocol etc. In general, although not ALL implementations need > security mechanisms, I assume an overwhelming majority of them does. In my opinion, a simple "X over Y" draft, where there are approved protocol X standards covering the security of X and approved protocol Y standards covering the security of Y, both referenced by the "X over Y" draft, does not normally require the re-hashing of security for either protocol X or protocol Y. You seem to want a complete re-hashing of TRILL security just because of this effort to specify a strightforward encoding of TRILL over a link type. > - Moreover, text such as the following (RFC 6325) strongly hints > that this traffic will be passing under the radar of many security > devices: "TRILL ignorant devices with firewall features that cannot > be detected by RBridges as end stations will generally not be able > to inspect the content of such frames for security checking > purposes." I don't see how this is different from any new protocol. Generally speaking, looking at a packet, there will be some sort of header for the new protocol and a device that don't understand that new protocol will be unable to parse that header or any following information. Firewall-like devices certainly have the option to discard such packets, which perhaps should be been explicitly mentioned in RFC 6325. Is it your opinion that the IETF standardization of a protocol should not be permitted until it has been demonstrated that understanding of that protocol has been actually deployed to all firewall-like devices in the universe? > - The Security Considerations recommend end-to-end security as a > replacement for link-level security. Though attractive from a > security point of view, such solutions (security protocols between > end hosts) are far from ubiquitous in large networks and so cannot > replace link-level mechanisms. The sentence in this draft most relevant to your comment above is as follows: "For applications involving sensitive data, end-to-end security should always be considered, in addition to link security, to provide security in depth." That doesn't sound like "replacement" to me. > - This document is analogous to RFC 6361, which uses PPP to bridge the TRILL > islands. RFC 6361 does in fact discuss specific security mechanisms (yes, > one wonders about CHAP being recommended in a 2011 document). The current > document does not do so. I think the claim you make that RFC 6361 uses PPP to "bridge the TRILL islands" is incorrect unless you consider every TRILL switch to be a one node "island" and every link between two TRILL switch ports to be a "bridge". There is no difference, from the TRILL protocol point of view, between links of different technology between TRILL switches (except that links configured as point-to-point are treated somewhat differently from multi-access links). This draft is "Transport of TRILL Using Pseudowires", effectively specified as TRILL over PPP over pseudowires. Pseudowires are over either MPLS or IP, and MPLS and IP are over some link protocol. So link security between two TRILL switch ports connected by a pseudowire can potentially be protected by security mechanisms provided by (1) TRILL, (2) PPP, (3) pseudowires, (4) MPLS or IP, and (5) the link technology being used by MPLS or IP. (Although, the PPP layer is somewhat vestigial - mostly used to conveniently distinguish TRILL Data and TRILL IS-IS packets.) I'd be happy to try to clarify in the Security Considerations section that link security can come from any combination of these layers. but I do not think the draft is the appropriate place for detailed discussion of all of these types of security and their permutations and combinations. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Thanks, > Yaron On Thu, Dec 12, 2013 at 4:58 PM, Yaron Sheffer 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 specifies how multiple networks running TRILL can be connected > using pseudowires. > > Summary > > Coming from the L3 security community, I am very worried by this document > and its predecessors. It seems to me that we are creating the infrastructure > for larger and larger L2 networks, often spanning large geographical > distances, but the security mechanisms are not keeping up with this wider > scope. > > I am not familiar with either the TRILL or PWE3 standards. Nor am I familiar > with their real-life implementations. If secure deployments are common, I > will be happy to be proven wrong (though I would expect such best practices > to be documented and standardized). > > Details > > - This document copies the following text from the analogous PPP transport > RFC: "not all implementations need to include specific security mechanisms > at the pseudowire layer, for example if they are designed to be deployed > only in cases where the networking environment is trusted or where other > layers provide adequate security. A complete enumeration of possible > deployment scenarios and associated threats and options is not possible and > is outside the scope of this document.' I beg to differ. I think Security > Considerations should recommend such solutions, and discuss the specific > issues that come up when deploying them in this context: how should > endpoints be authenticated? What protocol information should be protected? > How do TRILL identities map to identities authenticated by the selected > security protocol etc. In general, although not ALL implementations need > security mechanisms, I assume an overwhelming majority of them does. > > - Moreover, text such as the following (RFC 6325) strongly hints that this > traffic will be passing under the radar of many security devices: "TRILL > ignorant devices with firewall features that cannot be detected by RBridges > as end stations will generally not be able to inspect the content of such > frames for security checking purposes." > > - The Security Considerations recommend end-to-end security as a replacement > for link-level security. Though attractive from a security point of view, > such solutions (security protocols between end hosts) are far from > ubiquitous in large networks and so cannot replace link-level mechanisms. > > - This document is analogous to RFC 6361, which uses PPP to bridge the TRILL > islands. RFC 6361 does in fact discuss specific security mechanisms (yes, > one wonders about CHAP being recommended in a 2011 document). The current > document does not do so. > > Thanks, > Yaron > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From ynir@checkpoint.com Tue Dec 17 22:31:48 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618D61AE00A; Tue, 17 Dec 2013 22:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.439 X-Spam-Level: X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hex6_sSdh4JO; Tue, 17 Dec 2013 22:31:47 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D05981AE0BD; Tue, 17 Dec 2013 22:31:46 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rBI6VimZ024595; Wed, 18 Dec 2013 08:31:44 +0200 X-CheckPoint: {52B13D5F-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.77]) by IL-EX10.ad.checkpoint.com ([169.254.2.82]) with mapi id 14.03.0123.003; Wed, 18 Dec 2013 08:31:44 +0200 From: Yoav Nir To: "draft-housley-number-registries.all@tools.ietf.org" , " IESG" , "" Thread-Topic: SECDIR review of draft-housley-number-registries-02 Thread-Index: AQHO+7rRSdB0J0wqMkWLnL48bQrnEg== Date: Wed, 18 Dec 2013 06:31:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.201] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: <4CB755E3E9D7CE46989E15FAEE0EA04C@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] SECDIR review of draft-housley-number-registries-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 06:31:48 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These 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. TL;DR version: This document is ready This document is an informational describing the current state of the three= IANA numbers registry: the AS numbers, the IPv4 addresses, and the IPv6 ad= dresses. As such, it repeats information currently in those IANA registries= , and based on a cursory review of those registries, seems to do so accurat= ely. All I can say security-wise is that I agree with the security consider= ations section: "It does not change the security posture of the Internet in= any way." Having read both the Abstract and the Introduction, I have to say that I do= n't understand who the target audience of this document is. Nowhere does it= say what the value is of taking a snapshot of these registries as of early= 2014. That said, while I don't see the utility, there is definitely no har= m. Yoav From tobias.gondrom@gondrom.org Wed Dec 18 07:55:54 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ED71ADFFC; Wed, 18 Dec 2013 07:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjEpx2ppis94; Wed, 18 Dec 2013 07:55:52 -0800 (PST) Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC781ADFF7; Wed, 18 Dec 2013 07:55:52 -0800 (PST) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=yipxf3hjfOwzbUkDAb4Y1zun+EGOv1ANmsIcRriJLIkIaU2GzKClBqZMh4ZQpC20BdrrUEcaQ19kGmK935PtxKCt+hj1z/kCnVniKm9ApwmKX0lWZEy4CXHIvM5nC28ByKa6PlchFunZb3Q1mwVfkwwBWkeZ5AC+Ai9RS5A/Wdo=; h=X-No-Relay:X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.4] (2e40e8fb.skybroadband.com [46.64.232.251]) by www.gondrom.org (Postfix) with ESMTPSA id 008FC15390052; Wed, 18 Dec 2013 16:55:48 +0100 (CET) Message-ID: <52B1C584.5060907@gondrom.org> Date: Wed, 18 Dec 2013 15:55:48 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: draft-ietf-json-rfc4627bis.all@tools.ietf.org References: <52101187.2060409@gondrom.org> <5293E22B.90705@gondrom.org> <52A2257C.30700@gondrom.org> In-Reply-To: <52A2257C.30700@gondrom.org> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------080001010800070601020407" Cc: secdir-secretary@mit.edu, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-json-rfc4627bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 15:55:55 -0000 This is a multi-part message in MIME format. --------------080001010800070601020407 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi all, I re-reviewed the new doc version and did not see any changes related to my comments nor did I receive any direct replies from the authors. (note: this might well be due to some technical errors on the IETF mail server, which I think is fixed now.) As I am not sure whether my review email was received by the authors, here it is again. Best regards, Tobias as I am not sure whether these On 06/12/13 19:29, Tobias Gondrom wrote: > Hi all, > as it seems my previous review email was not relayed to the secdir and > iesg mailing-lists. Here it is again. > Best regards, Tobias > > > On 25/11/13 23:50, Tobias Gondrom wrote: >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> >> The document updates RFC4627 and aims for Standards Track. >> It is about the JSON Data Interchange Format >> >> This document appears ready for publication. >> >> It is good that we make the effort to incorporate the existing errata >> into an updated RFC. >> >> Some small nits / thoughts (as comments, none of them a discuss): >> - section 1: you briefly explain strings, objects and arrays. Do you >> maybe also want to make a brief statement about the range of allowed >> numbers or point towards section 6? (though this is not absolutely >> necessary as you discuss the data types in more detail in section 4-7). >> >> - section 12. Security Considerations: >> second paragraph: the point about the "eval()" function is a bit >> shallow, it might be useful to discuss this a bit more and to spell >> out what would be best practice instead of "use that language's >> "eval()" function to parse JSON texts." as that "generally >> constitutes an unacceptable security risk" >> >> - section 1 or 2: >> it might be useful to spell out what exactly the most important >> changes are in comparison to 4627 and why. Or mention that this would >> be discussed in detail in Appendix A. >> >> >> Best regards, Tobias > --------------080001010800070601020407 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi all,

I re-reviewed the new doc version and did not see any changes related to my comments nor did I receive any direct replies from the authors.
(note: this might well be due to some technical errors on the IETF mail server, which I think is fixed now.)
As I am not sure whether my review email was received by the authors, here it is again.

Best regards, Tobias



as I am not sure whether these

On 06/12/13 19:29, Tobias Gondrom wrote:
Hi all,
as it seems my previous review email was not relayed to the secdir and iesg mailing-lists. Here it is again.
Best regards, Tobias


On 25/11/13 23:50, Tobias Gondrom wrote:
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.


The document updates RFC4627 and aims for Standards Track.
It is about the JSON Data Interchange Format

This document appears ready for publication.

It is good that we make the effort to incorporate the existing errata into an updated RFC.

Some small nits / thoughts (as comments, none of them a discuss):
- section 1: you briefly explain strings, objects and arrays. Do you maybe also want to make a brief statement about the range of allowed numbers or point towards section 6? (though this is not absolutely necessary as you discuss the data types in more detail in section 4-7). 

- section 12.  Security Considerations:
second paragraph: the point about the "eval()" function is a bit shallow, it might be useful to discuss this a bit more and to spell out what would be best practice instead of "use that language's "eval()" function to parse JSON texts." as that "generally constitutes an unacceptable security risk"

- section 1 or 2:
it might be useful to spell out what exactly the most important changes are in comparison to 4627 and why. Or mention that this would be discussed in detail in Appendix A.


Best regards, Tobias


--------------080001010800070601020407-- From paul.hoffman@vpnc.org Wed Dec 18 08:35:24 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179641AE1CA; Wed, 18 Dec 2013 08:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPDLvFf8O2BE; Wed, 18 Dec 2013 08:35:22 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 65EF71AE180; Wed, 18 Dec 2013 08:35:22 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rBIGZD7n021033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Dec 2013 09:35:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: <52B1C584.5060907@gondrom.org> Date: Wed, 18 Dec 2013 08:35:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52101187.2060409@gondrom.org> <5293E22B.90705@gondrom.org> <52A2257C.30700@gondrom.org> <52B1C584.5060907@gondrom.org> To: Tobias Gondrom X-Mailer: Apple Mail (2.1827) Cc: secdir-secretary@mit.edu, secdir , draft-ietf-json-rfc4627bis.all@tools.ietf.org, The IESG Subject: Re: [secdir] secdir review of draft-ietf-json-rfc4627bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 16:35:24 -0000 Greetings. I see that we did miss responding to you. We had a very hard = time getting consensus in the WG leading to IETF Last Call, so we wanted = to keep the changes after that to a minimum. Of your nits: >>> Some small nits / thoughts (as comments, none of them a discuss):=20 >>> - section 1: you briefly explain strings, objects and arrays. Do you = maybe also want to make a brief statement about the range of allowed = numbers or point towards section 6? (though this is not absolutely = necessary as you discuss the data types in more detail in section 4-7). =20= Our charter was to make as few changes to RFC 4627 as possible, so we = left the original prose as-is unless it was actively wrong or caused = interoperability issues. >>> - section 12. Security Considerations:=20 >>> second paragraph: the point about the "eval()" function is a bit = shallow, it might be useful to discuss this a bit more and to spell out = what would be best practice instead of "use that language's "eval()" = function to parse JSON texts." as that "generally constitutes an = unacceptable security risk" The WG didn't come up with any "best practice" other than "don't do = that". RFC 4627 includes a (very wrong) example of how to fix the = problem, and we didn't want to repeat the mistake of saying "but you = might do X instead". >>>=20 >>> - section 1 or 2:=20 >>> it might be useful to spell out what exactly the most important = changes are in comparison to 4627 and why. Or mention that this would be = discussed in detail in Appendix A.=20 In this WG, *every* change became important. :-(=20 --Paul Hoffman= From benl@google.com Wed Dec 18 10:02:26 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359F91AE052 for ; Wed, 18 Dec 2013 10:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFA5Aqic_mmh for ; Wed, 18 Dec 2013 10:02:24 -0800 (PST) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E41911AE037 for ; Wed, 18 Dec 2013 10:02:23 -0800 (PST) Received: by mail-ve0-f172.google.com with SMTP id jw12so5527518veb.31 for ; Wed, 18 Dec 2013 10:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tYT78oBN6RbQvo3kIpXvpHX7xMPe04RY9pLwglGvgYw=; b=if9aJwzwLryyOgjCB9aODJQd3I6k1njZKVaW+3NAagP58nrd0BJli9X+h2Dc+aXzJf +doQrYKSfZUdZowrNcex4pnqXMS1IVYH4wNCOGMTA/Q3u/zdNMuWAPetbIcFnlSHYMP3 zwH9bYdA7ZQAJJfeOc6MIgc4CAu4cyXXAKLDiUPV4JtEW+7nCqumCsjkq7YYeRioQCFj N9gnZHbQc/mkyccLU2bzEhX2O67/r7ZrYUfh5mWK2Kwr4qWcFIcq6+XnoVaMuaFV32l0 VGrRJlZXanRRh73CSb/exyAMsMLgD/cw4nUdef9YIT7J5Xvqz5BFshwylbOtFLLhncnq gPTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=tYT78oBN6RbQvo3kIpXvpHX7xMPe04RY9pLwglGvgYw=; b=DtRm4qxg9IbTr4kTQ44EbASrCXadTmjZ1qhsZbKlIYkK41kt9pTqWw7J2Tw7VkZESN 8+wCZ13Ef439jUbuq3ZzZ1N0ZUmpLkToXS8PeJHAfpTLf1434n14MeA9Ezk2ECVUsgko w+7Jz3i+F/elHtlffUQJAvdM00Y8HYM5kp2aJ2qMsE5jmwb+mdTTx4Jyf2g7kk1hLcYq gmFhaMESJJKPOrPM9ONHt0TNFOpz6u5plt5TxV6kDzM/TukMMW0Vz+OexSfBS15XN6XS B4WliUEvUTvwbelA7JbCx/h4JgkS7QowdN5n9+fsooYx5e3g1rMi/xTUepFpsmpWawfq QIvg== X-Gm-Message-State: ALoCoQmIW+Ch+BQFSIBB0HUMMgV4tuU+rIUmcuTSaMKqj5Ray3U7v6BOGFFQy+PYeBrqjVctgJymlDeDfl6Kw6zxk9X7nCFKcgLGug8MxY3lyqTJ5TZA/8Sq+RhRhkPWt5FggW730KyplkUZJfyuZDFBNe1e8Crf3MpVS+NwvXYqhPiMC9RL9WOOkieQauY+v+xxpBpd3qzp MIME-Version: 1.0 X-Received: by 10.58.108.196 with SMTP id hm4mr9165304veb.28.1387389742025; Wed, 18 Dec 2013 10:02:22 -0800 (PST) Received: by 10.52.183.65 with HTTP; Wed, 18 Dec 2013 10:02:21 -0800 (PST) Date: Wed, 18 Dec 2013 18:02:21 +0000 Message-ID: From: Ben Laurie To: The IESG , "secdir@ietf.org" , draft-ietf-httpbis-p1-messaging.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [secdir] secdir review of draft-ietf-httpbis-p1-messaging-25 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 18:02:26 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: HTTP/1.1 is complicated, with many pitfalls. The draft does not give a great deal of assistance in dealing with them, and, indeed, encourages s/w to trip over these pitfalls. 2.4 Caches As well as poisoning attacks, websites can leave themselves exposed by failing to set appropriate caching values - for example, allowing caches to cache pages containing pesonal information, which is later served to the wrong person. The I-D should discuss this issue and give concrete advice on how to avoid inappropriate caching, whilst still permitting appropriate caching. Likewise, caches can be fooled into serving cached data inappropriaely - for example, in response to a subtly different request. Part 6, which is devoted to caches, appears to give no advice whatsoever, other than applications should "emit appropriate Cache-Control response header fields". It also, strangely, blames cache poisoning on implementation flaws, whilst exactly those types of flaws are encouraged in the next section of this I-D: "Unless noted otherwise, a recipient MAY attempt to recover a usable protocol element from an invalid construct." 2.5. Conformance and Error Handling Obviously very important for security. Is littered with vague generalities like "A sender MUST NOT generate protocol elements that convey a meaning that is known by that sender to be false." "Within a given message, a sender MUST NOT generate protocol elements or syntax alternatives that are only allowed to be generated by participants in other roles (i.e., a role that the sender does not have for that message)." "When a received protocol element is parsed, the recipient MUST be able to parse any value of reasonable length that is applicable to the recipient's role and matches the grammar defined by the corresponding ABNF rules." without giving any concrete advice (other than, presumably, "read and memorise the whole xxx pages of RFCs A, B, C ... Z"). Are there matrices of what is allowed, for example? Where? How long is "reasonable"? What do you do if the length is, in fact, "unreasonable"? As mentioned above, dangerous behaviour is encouraged on the part of receivers - i.e. to attempt to make some sense of invalid constructs. Also, "A recipient MUST interpret a received protocol element according to the semantics defined for it by this specification, including extensions to this specification, unless the recipient has determined (through experience or configuration) that the sender incorrectly implements what is implied by those semantics." is a licence for arbitraty behaviour. No mention at all of any of this in Security Considerations. 2.6. Protocol Versioning "A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions." - more encouragement to ignore the spec, and doubtless introduce yet more interesting security flaws. 3. Message Format "A recipient that receives whitespace between the start-line and the first header field MUST either reject the message as invalid or consume each whitespace-preceded line without further processing of it (i.e., ignore the entire line, along with any subsequent lines preceded by whitespace, until a properly formed header field is received or the header section is terminated)." - ditto. 3.1.1. Request Line "Recipients of an invalid request-line SHOULD respond with either a 400 (Bad Request) error or a 301 (Moved Permanently) redirect with the request-target properly encoded." - ditto. 3.2.2. Field Order "A server MUST wait until the entire header section is received before interpreting a request message, since later header fields might include conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request processing." Good advice, but sadly, no substance - it goes on to say: "A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation of the combined field value" Which gives no useful advice about "duplicate header fields that would impact request processing", and worse, means that intermediates and endpoints have essentially no chance of predicting the behaviour of machines up/downstream from them. 3.2.4. Field Parsing "A server that receives an obs-fold in a request message that is not within a message/http container MUST either reject the message by sending a 400 (Bad Request), preferably with a representation explaining that obsolete line folding is unacceptable, or replace each received obs-fold with one or more SP octets prior to interpreting the field value or forwarding the message downstream." - again, encouraging dangerous behaviour. 3.3.2. Content-Length Oddly, advice is given on what to when multiple identical content lengths are received, but not when they're different... "If a message is received that has multiple Content-Length header fields with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing a list of identical decimal values (e.g., "Content-Length: 42, 42"), indicating that duplicate Content-Length header fields have been generated or combined by an upstream message processor, then the recipient MUST either reject the message as invalid or replace the duplicated field-values with a single valid Content-Length field containing that decimal value prior to determining the message body length or forwarding the message." (though the next section does say what to do: for a change, reject it). "Since there is no way to distinguish a successfully completed, close-delimited message from a partially-received message interrupted by network failure, a server SHOULD generate encoding or length- delimited messages whenever possible. The close-delimiting feature exists primarily for backwards compatibility with HTTP/1.0." Surely closed connections _can_ be distinguished from interrupted ones? 4. Transfer Codings It should be noted that compressed encodings lead to vulnerability to CRIME-like attacks. 9. Security Considerations In general, a few useful pointers are given, but the above suggests rather more is needed. However, "Users need to be aware that intermediaries are no more trustworthy than the people who run them; HTTP itself cannot solve this problem." a) Users are not going to read this document, so - how are they to be made aware? b) No mechanism to determine who might be running intermediaries is described. From magnusn@gmail.com Wed Dec 18 17:03:29 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253DD1AD8CD for ; Wed, 18 Dec 2013 17:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ec5SwCw3dVf for ; Wed, 18 Dec 2013 17:03:27 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4778F1AD7BE for ; Wed, 18 Dec 2013 17:03:27 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hi5so6140472wib.14 for ; Wed, 18 Dec 2013 17:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=aRlFkjKeLJnbw2Qoz9L8+ufwtNSDYIxB5HIZMSCfJGc=; b=HwwrFbFAY9AbhfpWaHykCWPg9nwhbg53sXLcB3pGw3gRCDu36Awm2xZ28h7FfJWzIN qQsSkAbbeqz1QfX3HjMH8V2zv71kdeYsmvKeOZtyjbhahwhUsDs2n31TowC7i3AVsNSZ b41JFm+uC4O2c6wsQE1Lw5fJrAb6TDLpaKnf9hqewKzbmqRPxprO5Xfyu31DK31TuFZb KLfopalKAEqkpKI/yiQzL7z59niBhNAfl4hVi7PJUH7WfdF/O1M8VJcvhMN8J+e+H68e UnEXzha3biK3TEYgtADTVbkP2quBHGjoy/CpBfSm/VFkoNkoQnfB7txOT6hF6Vmgthvr kM8Q== MIME-Version: 1.0 X-Received: by 10.180.95.162 with SMTP id dl2mr308035wib.17.1387415005227; Wed, 18 Dec 2013 17:03:25 -0800 (PST) Received: by 10.180.36.78 with HTTP; Wed, 18 Dec 2013 17:03:25 -0800 (PST) Date: Wed, 18 Dec 2013 17:03:25 -0800 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: "adrian@olddog.co.uk" Content-Type: multipart/alternative; boundary=f46d0444e9838aef5304edd8ba01 Cc: draft-ietf-pim-explicit-tracking@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Security directorate review of draft-ietf-pim-explicit-tracking X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 01:03:29 -0000 --f46d0444e9838aef5304edd8ba01 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All, this is just to confirm - in time for the IESG telechat tomorrow - that I am happy with the updates the author made in draft version -09 to the Security Considerations section based on our discussion. Thanks, /Magnus On Mon, Nov 11, 2013 at 11:40 AM, Adrian Farrel wrote= : > Authors, > > > > Could you please engage with Magnus to either address his concerns in a > new revision, or explain to him why that would not be necessary/appropria= te. > > > > Thanks, > > Adrian > > > > *From:* iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] *On Behalf > Of *Magnus Nystr=F6m > *Sent:* 08 November 2013 04:16 > *To:* secdir@ietf.org; draft-ietf-pim-explicit-tracking@tools.ietf.org > *Cc:* iesg@ietf.org > *Subject:* Security directorate review of > draft-ietf-pim-explicit-tracking [Was: Re: Security directorate reveiw of > draft-asaeda-mboned-explicit-tracking > > > > > > [I did it again ... Sorry about the incorrect Subject: title, I used the > original draft name, the current name is of course > draft-ietf-pim-explicit-tracking.] > > > > On Thu, Nov 7, 2013 at 8:13 PM, Magnus Nystr=F6m wrot= e: > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security are= a > directors. Document editors and WG chairs should treat these comments jus= t > like any other last call comments. > > This document describes a tracking function for multicast routers and > proxies, intended to reduce latencies and network traffic, among other > things. > > The document seems well written but the security considerations sections > makes vague references to "serious threats" that may be introduced by > malicious hosts on the network yet only states that "abuse" can be > mitigated by limiting the amount of information a router can store (which > seems like a given anyway?). It would be good if the document enumerated > the "serious threats" and their mitigations. > > > -- Magnus > > > > > -- > -- Magnus > --=20 -- Magnus --f46d0444e9838aef5304edd8ba01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All, this is just to confirm - in time for the IESG telech= at tomorrow - that I am happy with the updates the author made in draft ver= sion -09 to the Security Considerations section based on our discussion.
Thanks,
/Magnus<= br>
On Mon, Nov 11, 2013 at 11:40 AM, A= drian Farrel <adrian@olddog.co.uk> wrote:
Authors,

=A0

Could you pl= ease engage with Magnus to either address his concerns in a new revision, o= r explain to him why that would not be necessary/appropriate.=

=A0

Thanks,

Adrian=

= =A0

From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Magnus N= ystr=F6m
Sent: 08 November 2013 04:16
To: secdir@ietf.org; draft-ietf-pim-e= xplicit-tracking@tools.ietf.org
Cc: iesg@ietf.org=
Subject: Security directorate review of draft-ietf-pim-expli= cit-tracking [Was: Re: Security directorate reveiw of draft-asaeda-mboned-e= xplicit-tracking

=A0

=A0

[I did it again .= .. Sorry about the incorrect Subject: title, I used the original draft name= , the current name is of course draft-ietf-pim-explicit-tracking.]

=A0

On Thu, Nov 7, 2013 at 8:13 PM, Magnus Nystr=F6m <magnusn@gmail.com> wrote:

I have review= ed this document as part of the security directorate's ongoing effort t= o review all IETF documents being processed by the IESG. These comments wer= e written primarily for the benefit of the security area directors. Documen= t editors and WG chairs should treat these comments just like any other las= t call comments.

This document describes a tracking function for multicast routers and p= roxies, intended to reduce latencies and network traffic, among other thing= s.

The document seems well wr= itten but the security considerations sections makes vague references to &q= uot;serious threats" that may be introduced by malicious hosts on the = network yet only states that "abuse" can be mitigated by limiting= the amount of information a router can store (which seems like a given any= way?). It would be good if the document enumerated the "serious threat= s" and their mitigations.=

-- Magnus




--
-- Magnus

=



--
-- Magnus
--f46d0444e9838aef5304edd8ba01-- From mnot@mnot.net Wed Dec 18 19:01:26 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F8B1ADF51; Wed, 18 Dec 2013 19:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQfXlIjx4RLl; Wed, 18 Dec 2013 19:01:23 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE691ADEC8; Wed, 18 Dec 2013 19:01:23 -0800 (PST) Received: from [192.168.1.55] (unknown [118.209.106.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 659D3509B5; Wed, 18 Dec 2013 22:01:17 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Mark Nottingham In-Reply-To: Date: Thu, 19 Dec 2013 14:01:13 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <453C9132-9FFF-4DC0-8E9C-1CBA1D90F4B5@mnot.net> References: To: Ben Laurie X-Mailer: Apple Mail (2.1827) Cc: draft-ietf-httpbis-p1-messaging.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-httpbis-p1-messaging-25 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 03:01:26 -0000 Hi Ben, Thanks for the detailed review. A few preliminary comments below. On 19 Dec 2013, at 5:02 am, Ben Laurie 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 > Summary: HTTP/1.1 is complicated, with many pitfalls. The draft does > not give a great deal of assistance in dealing with them, and, indeed, > encourages s/w to trip over these pitfalls. >=20 > 2.4 Caches >=20 > As well as poisoning attacks, websites can leave themselves exposed by > failing to set appropriate caching values - for example, allowing > caches to cache pages containing pesonal information, which is later > served to the wrong person. The I-D should discuss this issue and give > concrete advice on how to avoid inappropriate caching, whilst still > permitting appropriate caching. >=20 > Likewise, caches can be fooled into serving cached data inappropriaely > - for example, in response to a subtly different request. >=20 > Part 6, which is devoted to caches, appears to give no advice > whatsoever, other than applications should "emit appropriate > Cache-Control response header fields". >=20 > It also, strangely, blames cache poisoning on implementation flaws, > whilst exactly those types of flaws are encouraged in the next section = of this > I-D: "Unless noted otherwise, a recipient MAY attempt to recover a > usable protocol element from an invalid construct." Do you have a suggestion for text we should include (either here or in = p6)? > 2.5. Conformance and Error Handling >=20 > Obviously very important for security. Is littered with vague > generalities like >=20 > "A sender MUST NOT generate protocol elements that convey a meaning > that is known by that sender to be false." >=20 > "Within a given message, a sender MUST NOT generate protocol elements > or syntax alternatives that are only allowed to be generated by > participants in other roles (i.e., a role that the sender does not > have for that message)." >=20 > "When a received protocol element is parsed, the recipient MUST be > able to parse any value of reasonable length that is applicable to > the recipient's role and matches the grammar defined by the > corresponding ABNF rules." >=20 > without giving any concrete advice (other than, presumably, "read and > memorise the whole xxx pages of RFCs A, B, C ... Z"). Are there > matrices of what is allowed, for example? Where? How long is > "reasonable"? What do you do if the length is, in fact, > "unreasonable"? If we were designing HTTP from scratch, I would agree with you. However, = we're not; it is arguably the most widely deployed and diversely = implemented application protocols. There are few (if any) fields where a = single recommendation about "reasonable" size (for example) would be = appropriate, because HTTP is used for everything from Web browsers to = embedded controllers. We can't make these things non-conformant = retrospectively. We have, however, introduced recommendations (not requirements) around = minimum field lengths, etc. in most places. If you find a particular one = lacking, please do bring it to our attention. > As mentioned above, dangerous behaviour is encouraged on the part of > receivers - i.e. to attempt to make some sense of invalid constructs. >=20 > Also, "A recipient MUST interpret a received protocol element > according to the semantics defined for it by this specification, > including extensions to this specification, unless the recipient has > determined (through experience or configuration) that the sender > incorrectly implements what is implied by those semantics." is a > licence for arbitraty behaviour. >=20 > No mention at all of any of this in Security Considerations. >=20 > 2.6. Protocol Versioning >=20 > "A client MAY send a lower request version if it is known that the > server incorrectly implements the HTTP specification, but only after > the client has attempted at least one normal request and determined > from the response status code or header fields (e.g., Server) that the > server improperly handles higher request versions." - more > encouragement to ignore the spec, and doubtless introduce yet more > interesting security flaws. How is this "ignoring the spec"? > 3. Message Format >=20 > "A recipient that receives whitespace between the start-line and the > first header field MUST either reject the message as invalid or > consume each whitespace-preceded line without further processing of it > (i.e., ignore the entire line, along with any subsequent lines > preceded by whitespace, until a properly formed header field is > received or the header section is terminated)." - ditto. Can you please give us more substantive input? What is the *specific* = flaw here? >=20 > 3.1.1. Request Line >=20 > "Recipients of an invalid request-line SHOULD respond with either a > 400 (Bad Request) error or a 301 (Moved Permanently) redirect with the > request-target properly encoded." - ditto. And again... > 3.2.2. Field Order >=20 > "A server MUST wait until the entire header section is received before > interpreting a request message, since later header fields might > include conditionals, authentication credentials, or deliberately > misleading duplicate header fields that would impact request > processing." >=20 > Good advice, but sadly, no substance - it goes on to say: >=20 > "A recipient MAY combine multiple header fields with the same field > name into one "field-name: field-value" pair, without changing the > semantics of the message, by appending each subsequent field value to > the combined field value in order, separated by a comma. The order in > which header fields with the same field name are received is therefore > significant to the interpretation of the combined field value" >=20 > Which gives no useful advice about "duplicate header fields that would > impact request processing", and worse, means that intermediates and > endpoints have essentially no chance of predicting the behaviour of > machines up/downstream from them. We've taken the approach of identifying security-sensitive headers and = giving such advice in their specification, since this section is going = to be read by implementers of the generic message parsers, not the folks = who need to understand the security import of this design. > 3.2.4. Field Parsing >=20 > "A server that receives an obs-fold in a request message that is not > within a message/http container MUST either reject the message by > sending a 400 (Bad Request), preferably with a representation > explaining that obsolete line folding is unacceptable, or replace each > received obs-fold with one or more SP octets prior to interpreting the > field value or forwarding the message downstream." - again, > encouraging dangerous behaviour. Please explain how it is dangerous. > 3.3.2. Content-Length >=20 > Oddly, advice is given on what to when multiple identical content > lengths are received, but not when they're different... >=20 > "If a message is received that has multiple Content-Length header > fields with field-values consisting of the same decimal value, or a > single Content-Length header field with a field value containing a > list of identical decimal values (e.g., "Content-Length: 42, 42"), > indicating that duplicate Content-Length header fields have been > generated or combined by an upstream message processor, then the > recipient MUST either reject the message as invalid or replace the > duplicated field-values with a single valid Content-Length field > containing that decimal value prior to determining the message body > length or forwarding the message." >=20 > (though the next section does say what to do: for a change, reject > it). So, it is given. What's the issue - would you like this section = rearranged? If so, please come out and say so; if not, please explain. > "Since there is no way to distinguish a successfully completed, > close-delimited message from a partially-received message interrupted > by network failure, a server SHOULD generate encoding or length- > delimited messages whenever possible. The close-delimiting feature > exists primarily for backwards compatibility with HTTP/1.0." >=20 > Surely closed connections _can_ be distinguished from interrupted > ones? Not if the client is behind a proxy, and not if the HTTP API doesn't = expose this information. That said, "no way" is too strong here; should = be at least qualified with a "sometimes." > 4. Transfer Codings >=20 > It should be noted that compressed encodings lead to vulnerability to > CRIME-like attacks. >=20 >=20 > 9. Security Considerations >=20 > In general, a few useful pointers are given, but the above suggests > rather more is needed. >=20 > However, >=20 > "Users need to be aware that intermediaries are no more trustworthy > than the people who run them; HTTP itself cannot solve this problem." >=20 > a) Users are not going to read this document, so - how are they to be > made aware? >=20 > b) No mechanism to determine who might be running intermediaries is > described. In this effort, we're not chartered to do so. However, I agree it makes = sense to remove the "Users need to be aware that" qualification. Thanks again, -- Mark Nottingham http://www.mnot.net/ From kivinen@iki.fi Thu Dec 19 02:32:59 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8F11AE2B8 for ; Thu, 19 Dec 2013 02:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToMuS67-oKCN for ; Thu, 19 Dec 2013 02:32:57 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF961AE2B0 for ; Thu, 19 Dec 2013 02:32:56 -0800 (PST) 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 rBJAWoq2000302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 19 Dec 2013 12:32:50 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rBJAWnea010350; Thu, 19 Dec 2013 12:32:49 +0200 (EET) 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: <21170.52049.771263.384309@fireball.kivinen.iki.fi> Date: Thu, 19 Dec 2013 12:32:49 +0200 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.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 10:32:59 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Carl Wallace is next in the rotation. For telechat 2013-12-19 Reviewer LC end Draft Dave Cridland T 2013-11-04 draft-ietf-httpbis-p5-range-25 Julien Laganier T 2013-12-06 draft-ietf-avtcore-rtp-security-options-09 Matt Lepinski T 2013-11-04 draft-ietf-httpbis-p2-semantics-25 Matt Lepinski T 2013-12-09 draft-rosen-rph-reg-policy-01 For telechat 2014-01-09 Derek Atkins TR2013-10-01 draft-ietf-siprec-architecture-11 Last calls and special requests: Rob Austein 2013-11-27 draft-turner-application-cms-media-type-07 Dave Cridland E 2013-11-21 draft-dunbar-armd-arp-nd-scaling-practices-07 Steve Hanna E 2013-11-28 draft-ietf-pcp-nat64-prefix64-04 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05 Jeffrey Hutzelman 2013-12-09 draft-ietf-avtcore-leap-second-06 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-09 Julien Laganier 2013-12-11 draft-ietf-stox-core-08 Ben Laurie 2013-12-11 draft-ietf-stox-presence-06 Alexey Melnikov E 2013-12-12 draft-ietf-roll-rpl-industrial-applicability-02 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Magnus Nystrom 2014-01-05 draft-ietf-ccamp-oam-configuration-fwk-11 Hilarie Orman 2013-12-24 draft-ietf-isis-rfc1142-to-historic-00 Vincent Roca 2013-12-25 draft-ietf-6man-stable-privacy-addresses-16 Vincent Roca 2013-12-23 draft-ietf-savi-send-10 Joe Salowey 2013-12-23 draft-ietf-soc-overload-control-14 Zach Shelby 2013-12-23 draft-ietf-trill-rfc6327bis-02 Ondrej Sury 2013-12-27 draft-ietf-tls-applayerprotoneg-03 Tina TSOU 2014-01-10 draft-moriarty-pkcs12v1-1-03 Klaas Wierenga 2013-11-27 draft-ietf-pwe3-dynamic-ms-pw-20 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 Glen Zorn 2013-11-27 draft-turner-ct-keypackage-receipt-n-error-algs-04 -- kivinen@iki.fi From benl@google.com Thu Dec 19 04:21:01 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0751A1F1B for ; Thu, 19 Dec 2013 04:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8160LVKXb4kW for ; Thu, 19 Dec 2013 04:20:58 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B04B91A1F54 for ; Thu, 19 Dec 2013 04:20:58 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id ij19so601723vcb.31 for ; Thu, 19 Dec 2013 04:20:56 -0800 (PST) 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:content-transfer-encoding; bh=husSEnS0ODRDmMt7u0QlZhvkLzczRyQx5M6UpCSHg/s=; b=VQdSSiujLMbP5wqarQZ5ng7pWttRoP6cDzxQBtTR+/tbXNvbyLRk99nd35sGYXgeoB YpevYKSuvFKEZ8Qd6GHjdG1NCs5cL+n7fUJfBPjk7JGc0Ni/ghcGa4J2CS/YqVTFuzif MwSRAGNe8V+udaXqLy3Y4OwO52bp2EP/ycz1lPd7UTGjFjR2QgSGzVsuvPvR6YK7bdbd M2bxHXb5UKhlngqW+AVIbg0taygjTd3w+IAW0gIA3KQAXENxXzX9l8KgAKIS+p2ekpwA DT76LiH/6Esuv0vz7ANoZR/fbf6/SbekLW5yqn020UAeTZpouOpwQoWaarQ8Kjt5zjad 5u9w== 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 :content-transfer-encoding; bh=husSEnS0ODRDmMt7u0QlZhvkLzczRyQx5M6UpCSHg/s=; b=Ee9X54aiRMKNSlcAwYLEE8f5lKssgVtbTc/JdqpTTsop5BsbeLv5NH07ZX+cn9X/By 9NKxAk1kmcd1i4KBjDyWud5a1IwpMI6aywFfTpLMMFzn0gqvO7DUpltTivQkfrUG8Zs+ QXqWHWY4MMMM0dc991u2h4W6XSBQCYsXvQ42iYxzpP/vuINiWY3QR96/ayHwmlyPWvOZ MNVBO95k7CuUfELhrOJiL0OWyc8WBprf+pZ/7bz9wVmE1KnQPZe9QX7vUNyaU2VkR/eD ZV1zbAjC8Pb4DnsZtpc7xlyeUTHZUqu/tPb11DGo5nzwg9XkmlMA8YiKHXUcw2+hW8PQ sP6g== X-Gm-Message-State: ALoCoQkikWO+zKG/nE0zNj60pGQRErsauWfMhHXqBr3qzk3VFlUsR1xtw8RtasJPvqg6wOyuzyZA7XwgHvOnhK9yHgDLW6u/3wPI8PntF6TqrqozcBNe+CQU0APVKRu3CTeoxUNMxofkfGH78w7zeW1jJIemBUoNm/b5/S45iwADtmbILAAO88IgN7+f+roGm3N3WXyfofSo MIME-Version: 1.0 X-Received: by 10.58.156.106 with SMTP id wd10mr674308veb.7.1387455656568; Thu, 19 Dec 2013 04:20:56 -0800 (PST) Received: by 10.52.178.9 with HTTP; Thu, 19 Dec 2013 04:20:55 -0800 (PST) In-Reply-To: <453C9132-9FFF-4DC0-8E9C-1CBA1D90F4B5@mnot.net> References: <453C9132-9FFF-4DC0-8E9C-1CBA1D90F4B5@mnot.net> Date: Thu, 19 Dec 2013 12:20:55 +0000 Message-ID: From: Ben Laurie To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-httpbis-p1-messaging.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-httpbis-p1-messaging-25 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 12:21:01 -0000 On 19 December 2013 03:01, Mark Nottingham wrote: > Hi Ben, > > Thanks for the detailed review. A few preliminary comments below. > > > On 19 Dec 2013, at 5:02 am, Ben Laurie 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. >> >> Summary: HTTP/1.1 is complicated, with many pitfalls. The draft does >> not give a great deal of assistance in dealing with them, and, indeed, >> encourages s/w to trip over these pitfalls. >> >> 2.4 Caches >> >> As well as poisoning attacks, websites can leave themselves exposed by >> failing to set appropriate caching values - for example, allowing >> caches to cache pages containing pesonal information, which is later >> served to the wrong person. The I-D should discuss this issue and give >> concrete advice on how to avoid inappropriate caching, whilst still >> permitting appropriate caching. >> >> Likewise, caches can be fooled into serving cached data inappropriaely >> - for example, in response to a subtly different request. >> >> Part 6, which is devoted to caches, appears to give no advice >> whatsoever, other than applications should "emit appropriate >> Cache-Control response header fields". >> >> It also, strangely, blames cache poisoning on implementation flaws, >> whilst exactly those types of flaws are encouraged in the next section o= f this >> I-D: "Unless noted otherwise, a recipient MAY attempt to recover a >> usable protocol element from an invalid construct." > > Do you have a suggestion for text we should include (either here or in p6= )? I would say that recipients MUT NOT attempt recover a usable... Also, for "appropriate Cache-Control response header fields", I'd suggest including examples for likely scenarios (e.g. "can be freely cached, must not be cached at all, ever, can be cached for anyone with this particular cookie" [if that's even possible]). >> 2.5. Conformance and Error Handling >> >> Obviously very important for security. Is littered with vague >> generalities like >> >> "A sender MUST NOT generate protocol elements that convey a meaning >> that is known by that sender to be false." >> >> "Within a given message, a sender MUST NOT generate protocol elements >> or syntax alternatives that are only allowed to be generated by >> participants in other roles (i.e., a role that the sender does not >> have for that message)." >> >> "When a received protocol element is parsed, the recipient MUST be >> able to parse any value of reasonable length that is applicable to >> the recipient's role and matches the grammar defined by the >> corresponding ABNF rules." >> >> without giving any concrete advice (other than, presumably, "read and >> memorise the whole xxx pages of RFCs A, B, C ... Z"). Are there >> matrices of what is allowed, for example? Where? How long is >> "reasonable"? What do you do if the length is, in fact, >> "unreasonable"? > > If we were designing HTTP from scratch, I would agree with you. However, = we're not; it is arguably the most widely deployed and diversely implemente= d application protocols. There are few (if any) fields where a single recom= mendation about "reasonable" size (for example) would be appropriate, becau= se HTTP is used for everything from Web browsers to embedded controllers. W= e can't make these things non-conformant retrospectively. You could, perhaps, distinguish between what might be found in the wild (that you want to make conformant, for some reason) and what you advise for new implementations. > We have, however, introduced recommendations (not requirements) around mi= nimum field lengths, etc. in most places. If you find a particular one lack= ing, please do bring it to our attention. > > >> As mentioned above, dangerous behaviour is encouraged on the part of >> receivers - i.e. to attempt to make some sense of invalid constructs. >> >> Also, "A recipient MUST interpret a received protocol element >> according to the semantics defined for it by this specification, >> including extensions to this specification, unless the recipient has >> determined (through experience or configuration) that the sender >> incorrectly implements what is implied by those semantics." is a >> licence for arbitraty behaviour. >> >> No mention at all of any of this in Security Considerations. >> >> 2.6. Protocol Versioning >> >> "A client MAY send a lower request version if it is known that the >> server incorrectly implements the HTTP specification, but only after >> the client has attempted at least one normal request and determined >> from the response status code or header fields (e.g., Server) that the >> server improperly handles higher request versions." - more >> encouragement to ignore the spec, and doubtless introduce yet more >> interesting security flaws. > > How is this "ignoring the spec"? You allow clients to fall back to older specs (i.e. ignore this spec) on essentially arbitrary grounds. >> 3. Message Format >> >> "A recipient that receives whitespace between the start-line and the >> first header field MUST either reject the message as invalid or >> consume each whitespace-preceded line without further processing of it >> (i.e., ignore the entire line, along with any subsequent lines >> preceded by whitespace, until a properly formed header field is >> received or the header section is terminated)." - ditto. > > Can you please give us more substantive input? What is the *specific* fla= w here? The issue is encouraging interpreting content that may or may not be HTTP as if it were (combined with other admonishments to guess at its meaning as you go). This is how request splitting attacks work, for example. In other words, recipients should be strict in their interpretation lest they are fooled into misinterpretation. >> 3.1.1. Request Line >> >> "Recipients of an invalid request-line SHOULD respond with either a >> 400 (Bad Request) error or a 301 (Moved Permanently) redirect with the >> request-target properly encoded." - ditto. > > And again... See above. The response should be a 400, never a 301. >> 3.2.2. Field Order >> >> "A server MUST wait until the entire header section is received before >> interpreting a request message, since later header fields might >> include conditionals, authentication credentials, or deliberately >> misleading duplicate header fields that would impact request >> processing." >> >> Good advice, but sadly, no substance - it goes on to say: >> >> "A recipient MAY combine multiple header fields with the same field >> name into one "field-name: field-value" pair, without changing the >> semantics of the message, by appending each subsequent field value to >> the combined field value in order, separated by a comma. The order in >> which header fields with the same field name are received is therefore >> significant to the interpretation of the combined field value" >> >> Which gives no useful advice about "duplicate header fields that would >> impact request processing", and worse, means that intermediates and >> endpoints have essentially no chance of predicting the behaviour of >> machines up/downstream from them. > > We've taken the approach of identifying security-sensitive headers and gi= ving such advice in their specification, since this section is going to be = read by implementers of the generic message parsers, not the folks who need= to understand the security import of this design. OK. It would probably be useful to have a list somewhere, rather than obliging everyone, e.g. code auditors, to read all n documents. >> 3.2.4. Field Parsing >> >> "A server that receives an obs-fold in a request message that is not >> within a message/http container MUST either reject the message by >> sending a 400 (Bad Request), preferably with a representation >> explaining that obsolete line folding is unacceptable, or replace each >> received obs-fold with one or more SP octets prior to interpreting the >> field value or forwarding the message downstream." - again, >> encouraging dangerous behaviour. > > Please explain how it is dangerous. Again, non-strict interpretation can lead (and historically has led) to misinterpretation, which leads to exploitable bugs. >> 3.3.2. Content-Length >> >> Oddly, advice is given on what to when multiple identical content >> lengths are received, but not when they're different... >> >> "If a message is received that has multiple Content-Length header >> fields with field-values consisting of the same decimal value, or a >> single Content-Length header field with a field value containing a >> list of identical decimal values (e.g., "Content-Length: 42, 42"), >> indicating that duplicate Content-Length header fields have been >> generated or combined by an upstream message processor, then the >> recipient MUST either reject the message as invalid or replace the >> duplicated field-values with a single valid Content-Length field >> containing that decimal value prior to determining the message body >> length or forwarding the message." >> >> (though the next section does say what to do: for a change, reject >> it). > > So, it is given. What's the issue - would you like this section rearrange= d? If so, please come out and say so; if not, please explain. Yeah, it just seemed odd to deal with one case in one place and the other in a completely different section. It also is a little odd to collapse multiple content-lengths (which is incorrect according to the spec) into a single one, just because they happen to match. >> "Since there is no way to distinguish a successfully completed, >> close-delimited message from a partially-received message interrupted >> by network failure, a server SHOULD generate encoding or length- >> delimited messages whenever possible. The close-delimiting feature >> exists primarily for backwards compatibility with HTTP/1.0." >> >> Surely closed connections _can_ be distinguished from interrupted >> ones? > > Not if the client is behind a proxy, and not if the HTTP API doesn't expo= se this information. That said, "no way" is too strong here; should be at l= east qualified with a "sometimes." Perhaps the proxy should indicate if this has happened? From alexey.melnikov@isode.com Fri Dec 20 05:14:48 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496871AE272 for ; Fri, 20 Dec 2013 05:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYBXEOHAA1ms for ; Fri, 20 Dec 2013 05:14:45 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 9F71A1AC403 for ; Fri, 20 Dec 2013 05:14:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1387545281; d=isode.com; s=selector; i=@isode.com; bh=BTitHSG7wYXMX9ovaEOLSLbj/9xQqeHPkeot/0jgrOE=; 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=bETtZIb07XkGEOu6sVtWj6940ITmF3HbbpglVpjFZS0alQrTFXO/Fs0/v4qE32fPXQHwAW GzVMOTTVSVog7kkaV+CTfeNIFKhNaKNzvEEF+9SiQESGpszRu0qRIgJdcqLP0Sap3xkBav GCf+3NSyRyvp1g61m/bsVT2o1wlohE0=; Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 20 Dec 2013 13:14:41 +0000 Message-ID: <52B442CA.8090909@isode.com> Date: Fri, 20 Dec 2013 13:14:50 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 To: draft-ietf-roll-rpl-industrial-applicability.all@tools.ietf.org, Michael Richardson MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org Subject: [secdir] SecDir Review of draft-ietf-roll-rpl-industrial-applicability X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 13:14:48 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document is well written and was quite educational for me. However the Security Considerations section is incomplete and not quite ready. > This document does not specify operations that could introduce new > threats. Security considerations for RPL deployments are to be > developed in accordance with recommendations laid out in, for > example, [I-D.tsao-roll-security-framework]. This document got obsoleted by a WG document. I am not entirely sure whether this is intended to be draft-ietf-roll-security-threats or draft-ietf-roll-security-framework. Please update your draft to point to the latest document. > Industrial automation networks are subject to stringent security > requirements as they are considered a critical infrastructure > component. At the same time, since they are composed of large > numbers of resource- constrained devices inter-connected with > limited-throughput links, many available security mechanisms are > not practical for use in such networks. As a result, the choice of > security mechanisms is highly dependent on the device and network > capabilities characterizing a particular deployment. While this sounds plausible, this is not very helpful for deployments. Are there any documents (maybe even research papers) that talk about different types of deployments and suitable security mechanisms for them? > In contrast to other types of LLNs, in industrial automation > networks centralized administrative control and access to > a permanent secure infrastructure is available. > As a result link-layer, transport-layer > and/or application-layer security mechanisms are typically in place > and may make use of RPL's secure mode unnecessary. Pointing to RFC 6550 and describing how RPL security services described there can be replaced by link/transport/application-layer technologies would be helpful as well. > 6.1. Security Considerations during initial deployment > > 6.2. Security Considerations during incremental deployment These sections need completing. Looking at draft-ietf-roll-applicability-template-03, I can see there a useful pointer to a document about getting initial keys and trust anchors. From Ted.Lemon@nominum.com Mon Dec 23 13:12:44 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45401AE29D; Mon, 23 Dec 2013 13:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTM9xQJtnXYR; Mon, 23 Dec 2013 13:12:40 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 13D1D1AE27D; Mon, 23 Dec 2013 13:12:40 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUrinRIAsGLZPTUG08UIie32WAHqFTniG@postini.com; Mon, 23 Dec 2013 13:12:37 PST 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 B4C061B82E1; Mon, 23 Dec 2013 13:12:36 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (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 ESMTP id 8A7CA19005C; Mon, 23 Dec 2013 13:12:36 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Dec 2013 13:12:30 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Mon, 23 Dec 2013 16:12:25 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <018ED656-C051-4CB7-8F8B-7920491CF2A2@nominum.com> References: <52AA3173.8040100@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "draft-ietf-trill-o-pw.all@tools.ietf.org" , The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-trill-o-pw-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 21:12:44 -0000 Yaron, it's my impression that Donald has addressed your secdir review = comments. If you do not believe that to be the case, please let us = know. Thanks! From hilarie@purplestreak.com Tue Dec 24 12:07:33 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029FB1AE053; Tue, 24 Dec 2013 12:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrJr7s61AZDZ; Tue, 24 Dec 2013 12:07:31 -0800 (PST) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by ietfa.amsl.com (Postfix) with ESMTP id B05CE1AE064; Tue, 24 Dec 2013 12:07:31 -0800 (PST) Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1VvYGD-0005Xv-Nm; Tue, 24 Dec 2013 13:07:25 -0700 Received: from [72.250.219.84] (helo=sylvester.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1VvYGB-0003QU-Kf; Tue, 24 Dec 2013 13:07:25 -0700 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id rBOK6tVU021015; Tue, 24 Dec 2013 13:06:55 -0700 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id rBOK6r4C021013; Tue, 24 Dec 2013 13:06:53 -0700 Date: Tue, 24 Dec 2013 13:06:53 -0700 Message-Id: <201312242006.rBOK6r4C021013@sylvester.rhmr.com> From: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org X-XM-AID: U2FsdGVkX18/OJ6/uW9olkh4qXTwf5a9 X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Cc: imc.shand@googlemail.com, draft-ietf-isis-rfc1142-to-historic@tools.ietf.org Subject: [secdir] review draft-ietf-isis-rfc1142-to-historic-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 20:07:33 -0000 Reclassification of RFC 1142 to Historic draft-ietf-isis-rfc1142-to-historic-00 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. RFC1142 described an early version of the ISO protocol for intradomain routing and its use with IP. The description of the ISO protocol did not match the final version, and ever since there has been some confusion about what to cite with respect to this ISO standard. The reclassification of RFC1142 to historic may help alleviate the confusion. There are no security issues for consideration in this document. Hilarie From yaronf.ietf@gmail.com Wed Dec 25 08:16:11 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D84D1A802F; Wed, 25 Dec 2013 08:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88NZaUtBImb3; Wed, 25 Dec 2013 08:16:10 -0800 (PST) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id CEE011A1F05; Wed, 25 Dec 2013 08:16:09 -0800 (PST) Received: by mail-ee0-f42.google.com with SMTP id e53so3369940eek.29 for ; Wed, 25 Dec 2013 08:16:05 -0800 (PST) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ClpKwX9VJJUFfi0zdzORQRTtJy53up0nrb+4mnpyojE=; b=IXxhRmlhA5ut7oU6eHDSSsIrXrTh3KXfJa+/gZYKsRaaEa6MZGHf+oSszBSmT3H/Wo 6EGjTrJJ5o/8HX7NHPLJGzGskYxC44ZyM2TKjg7uqxF8k+M7Ud9spabxkKDXEgbrI442 Ta6Gcl+Dag06RMNqcFOmhdPOH1XO7sSL4U48WU1TwCuSKnYedB8RaJ0Uq2jvcHKkeSRQ sBczot+oalh71F1Zx9dyoJwtn+yELjujpKTYYXiMMM/skZgyr9aAb8lEPgkkYyvKiJEI xJD3YSf8PlUeKYzQGRFjr28kevZIHQ6E9tyqkaKatSzpBPMR/RgLa94vth++iZOQVRi3 2jNg== X-Received: by 10.14.108.6 with SMTP id p6mr32229686eeg.31.1387988165226; Wed, 25 Dec 2013 08:16:05 -0800 (PST) Received: from [10.0.0.10] (93-173-35-212.bb.netvision.net.il. [93.173.35.212]) by mx.google.com with ESMTPSA id g7sm65081511eet.12.2013.12.25.08.16.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Dec 2013 08:16:04 -0800 (PST) Message-ID: <52BB04C2.4000901@gmail.com> Date: Wed, 25 Dec 2013 18:16:02 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ted Lemon References: <52AA3173.8040100@gmail.com> <018ED656-C051-4CB7-8F8B-7920491CF2A2@nominum.com> In-Reply-To: <018ED656-C051-4CB7-8F8B-7920491CF2A2@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-trill-o-pw.all@tools.ietf.org" , The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-trill-o-pw-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2013 16:16:11 -0000 Yes, Donald did address my comments, quite extensively. It was also an opportunity to read his excellent IPJ tutorial on TRILL. Thanks and Happy Holidays! Yaron On 12/23/2013 11:12 PM, Ted Lemon wrote: > Yaron, it's my impression that Donald has addressed your secdir review comments. If you do not believe that to be the case, please let us know. > > Thanks! > From pthubert@cisco.com Fri Dec 20 09:13:53 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A431AD669 for ; Fri, 20 Dec 2013 09:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yb7DYmZZOkkx for ; Fri, 20 Dec 2013 09:13:52 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 34CBF1ADFC1 for ; Fri, 20 Dec 2013 09:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3219; q=dns/txt; s=iport; t=1387559628; x=1388769228; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Na9sj9viOkAiz+m+72PGAe1oYSsG+BsBou2F9Afd/2E=; b=c5fRrMiJrwePdCM2PtPT9ENKxI2VGs8SGnbsH8IviKGc9FEn05c0Zuxr eWcsmTvZjdw2uIwHUKO9vNFewKJZUXznlOi0BP6uVIGiFQgQwJ3PwPB+q UNZR1lIsBMR4P30ZZUb3WxbgoqzX6R++CrHW7sVIGO2/oYMU0QQiBmFKK 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAPJ5tFKtJXHA/2dsb2JhbABZgwuBDbk2gR4WdIIlAQEBBHkMBAIBCBEEAQELHQcyFAkIAgQBDQUIh3zKSReOOicxBwaDHYETAQOJC6EfgyuBaEI X-IronPort-AV: E=Sophos;i="4.95,522,1384300800"; d="scan'208";a="8215298" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-4.cisco.com with ESMTP; 20 Dec 2013 17:13:47 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rBKHDlmW009529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Dec 2013 17:13:47 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.179]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Fri, 20 Dec 2013 11:13:47 -0600 From: "Pascal Thubert (pthubert)" To: Alexey Melnikov , "draft-ietf-roll-rpl-industrial-applicability.all@tools.ietf.org" , "Michael Richardson" Thread-Topic: SecDir Review of draft-ietf-roll-rpl-industrial-applicability Thread-Index: AQHO/YV9o9lCIwsv2kKoXlizQBGqsZpdUiQQ Date: Fri, 20 Dec 2013 17:13:47 +0000 Deferred-Delivery: Fri, 20 Dec 2013 17:13:00 +0000 Message-ID: References: <52B442CA.8090909@isode.com> In-Reply-To: <52B442CA.8090909@isode.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 26 Dec 2013 12:00:43 -0800 Cc: "secdir@ietf.org" Subject: Re: [secdir] SecDir Review of draft-ietf-roll-rpl-industrial-applicability X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 17:13:54 -0000 Thanks a lot Alexey! We'll dig into that, though probably after Christmas now : ) Cheers, Pascal > -----Original Message----- > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] > Sent: vendredi 20 d=E9cembre 2013 14:15 > To: draft-ietf-roll-rpl-industrial-applicability.all@tools.ietf.org; Mich= ael > Richardson > Cc: secdir@ietf.org > Subject: SecDir Review of draft-ietf-roll-rpl-industrial-applicability >=20 > Hi, >=20 > I have reviewed this document as part of the security directorate's ongoi= ng > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area dire= ctors. > Document editors and WG chairs should treat these comments just like any > other last call comments. >=20 > The document is well written and was quite educational for me. However th= e > Security Considerations section is incomplete and not quite ready. >=20 > > This document does not specify operations that could introduce new > > threats. Security considerations for RPL deployments are to be > > developed in accordance with recommendations laid out in, for > > example, [I-D.tsao-roll-security-framework]. >=20 > This document got obsoleted by a WG document. I am not entirely sure whet= her > this is intended to be draft-ietf-roll-security-threats or draft-ietf-rol= l-security- > framework. Please update your draft to point to the latest document. >=20 > > Industrial automation networks are subject to stringent security > > requirements as they are considered a critical infrastructure > > component. At the same time, since they are composed of large > > numbers of resource- constrained devices inter-connected with > > limited-throughput links, many available security mechanisms are > > not practical for use in such networks. As a result, the choice of > > security mechanisms is highly dependent on the device and network > > capabilities characterizing a particular deployment. >=20 > While this sounds plausible, this is not very helpful for deployments. > Are there any documents (maybe even research papers) that talk about diff= erent > types of deployments and suitable security mechanisms for them? >=20 > > In contrast to other types of LLNs, in industrial automation > > networks centralized administrative control and access to > > a permanent secure infrastructure is available. > > As a result link-layer, transport-layer > > and/or application-layer security mechanisms are typically in place > > and may make use of RPL's secure mode unnecessary. >=20 > Pointing to RFC 6550 and describing how RPL security services described t= here > can be replaced by link/transport/application-layer technologies would be > helpful as well. >=20 > > 6.1. Security Considerations during initial deployment > > 6.2. Se= curity > Considerations during incremental deployment >=20 > These sections need completing. Looking at draft-ietf-roll-applicability- > template-03, I can see there a useful pointer to a document about getting= initial > keys and trust anchors.