From julian.reschke@gmx.de Fri Nov 1 06:17:20 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EA721E836E for ; Fri, 1 Nov 2013 06:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNQcGT1ZyX9B for ; Fri, 1 Nov 2013 06:16:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id B04F221E8436 for ; Fri, 1 Nov 2013 06:13:08 -0700 (PDT) Received: from [192.168.2.117] ([84.187.33.167]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MU0pN-1VBayi3Nbd-00QhGq for ; Fri, 01 Nov 2013 14:13:07 +0100 Message-ID: <5273A8D2.2050604@gmx.de> Date: Fri, 01 Nov 2013 14:12:50 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Bjoern Hoehrmann , Julian Reschke References: <52700DE4.8020208@bbn.com> <52726125.1000802@greenbytes.de> <52726DD8.8080800@greenbytes.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:WMvOdqRDjkZ4Nx5S0c0VlFHphpK5fXR7SG+HrEu+8X0aO5P2N6C wvrCWCBcZdF/C+KgTqtOBTa8O00qBE2fS36mwwAXnkyPy3oczFHiF02tAGwEPT0Lp7nRYtw GfuzWHVP8+CchOamjNk/MKV7wKT8DWmSRp3ZpHX5e+oK0mShQJLG5K4vguM6QeudpMlANOL IUg/Tt/zKDe7x+Y0W8ibw== Cc: secdir , Pete Resnick , "Mankin, Allison" , HTTP Working Group , Barry Leiba Subject: Re: [secdir] additional mechanisms on top of the auth framework, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 13:17:20 -0000 On 2013-10-31 16:05, Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >> On 2013-10-31 15:44, Bjoern Hoehrmann wrote: >>> I think doing s/encryption/authentication/ instead would be better. >>> There is no reason to discuss confidentiality here. Encryption and other >>> cryptographic techniques are used in many authentication schemes, like >>> with client certificates; that may have been the idea behind the text. >> >> "authentication on the transport layer"? > > Applying my suggestion would make the text read, > > The HTTP protocol does not restrict applications to this simple > challenge-response framework for access authentication. Additional > mechanisms MAY be used, such as authentication at the transport > level or via message encapsulation, and with additional header fields > specifying authentication information. However, such additional > mechanisms are not defined by this specification. > > (The MAY might be better as "can".) > ... OK, applied with . Best regards, Julian From kent@bbn.com Fri Nov 1 06:55:33 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8DC11E8397 for ; Fri, 1 Nov 2013 06:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.445 X-Spam-Level: X-Spam-Status: No, score=-106.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOxV7CLk70ym for ; Fri, 1 Nov 2013 06:55:27 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A163A11E83AC for ; Fri, 1 Nov 2013 06:54:43 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:52722 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VcFB2-000LY5-3q; Fri, 01 Nov 2013 09:54:16 -0400 Message-ID: <5273B287.7010205@bbn.com> Date: Fri, 01 Nov 2013 09:54:15 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Mark Nottingham References: <52700DE4.8020208@bbn.com> <52725E8E.50106@greenbytes.de> <5272B71B.1070607@bbn.com> <679A359D-AB27-4DA7-AAD0-59290DA1DF23@mnot.net> In-Reply-To: <679A359D-AB27-4DA7-AAD0-59290DA1DF23@mnot.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: secdir , Pete Resnick , "Julian F. Reschke" , Mark Nottingham , "Mankin, Allison" , HTTP Working Group , Barry Leiba , Roy Fielding Subject: Re: [secdir] proxies and forwarding of credentials, was: SECDIR review of draft-ietf-httpbis-p7-auth-24 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 13:55:33 -0000 Mark, > It entirely depends upon the way that they’re cooperating… sometimes you’d want to forward them, sometimes not. If we were defining a proxy authentication cooperation protocol here, I could understand a MUST here, but as we’re not, I don’t think we want to constrain how one might operate… > OK. Just make sure the text doesn't appear to give contradictory messages wrt this topic. The description of what a proxy relay does, or does not, do needs to be a bit clearer, so that the MAY seems appropriate. Steve From derek@ihtfp.com Fri Nov 1 06:57:14 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4939211E833C; Fri, 1 Nov 2013 06:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEpt+MJNeCkq; Fri, 1 Nov 2013 06:57:13 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id 7505211E813F; Fri, 1 Nov 2013 06:57:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 3D6DE2602BA; Fri, 1 Nov 2013 09:57:09 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 25674-09; Fri, 1 Nov 2013 09:57:05 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 932DA260237; Fri, 1 Nov 2013 09:57:05 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.5/Submit) id rA1Dv04R028154; Fri, 1 Nov 2013 09:57:01 -0400 From: Derek Atkins To: "Hutton\, Andrew" References: <9F33F40F6F2CD847824537F3C4E37DDF17BF527F@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF17C26825@MCHP04MSX.global-ad.net> Date: Fri, 01 Nov 2013 09:57:00 -0400 In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C26825@MCHP04MSX.global-ad.net> (Andrew Hutton's message of "Wed, 30 Oct 2013 17:39:16 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: "leon.portman@gmail.com" , "secdir@ietf.org" , "krehor@cisco.com" , "iesg@ietf.org" , "siprec-chairs@tools.ietf.org" , "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.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 13:57:14 -0000 Hi, "Hutton, Andrew" writes: > 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" This is a good start. Could you also add something like: 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 > Regards > Andy -derek >> -----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 > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From andrew.hutton@unify.com Fri Nov 1 09:18:03 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1242221E84DA; Fri, 1 Nov 2013 09:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJ9HRFTmlED0; Fri, 1 Nov 2013 09:17:58 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 369AC21E84D8; Fri, 1 Nov 2013 09:17:57 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 7ED9823F0505; Fri, 1 Nov 2013 17:17:55 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Fri, 1 Nov 2013 17:17:55 +0100 From: "Hutton, Andrew" To: Derek Atkins Thread-Topic: sec-dir review of draft-ietf-siprec-architecture-08 Thread-Index: AQHO1wo8FpuNNNCQs06E2FZPbdmFCZoQjbAw Date: Fri, 1 Nov 2013 16:17:54 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C29FB8@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.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 16:18:03 -0000 Sounds good will use your text. Thanks 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 ynir@checkpoint.com Sat Nov 2 05:30:02 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5F011E81FF; Sat, 2 Nov 2013 05:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.377 X-Spam-Level: X-Spam-Status: No, score=-10.377 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov3OAnr-+tGg; Sat, 2 Nov 2013 05:29:56 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5E011E81FD; Sat, 2 Nov 2013 05:29:54 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA2CTmmf018382; Sat, 2 Nov 2013 14:29:48 +0200 X-CheckPoint: {5274EF09-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Sat, 2 Nov 2013 14:29:48 +0200 From: Yoav Nir To: "" , The IESG , "draft-ietf-nfsv4-labreqs.all@tools.ietf.org" Thread-Topic: SecDir Review of draft-ietf-nfsv4-labreqs Thread-Index: AQHO18c3l5Ocx4tIM0WjeGDw7jvwUA== Date: Sat, 2 Nov 2013 12:29:47 +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.241] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <10E74F5DF062E54B8097AFBDB7C05F63@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] SecDir Review of draft-ietf-nfsv4-labreqs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 12:30:02 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments ust like any o= ther last call comments. Short version: I think the draft is ready. This draft is intended to be Informational. It does not specify any standar= d. Instead, it describes the operating environment and assumptions behind l= abeled NFS.=20 Labeled NFS associates labels with resources (usually files) and processes,= where the resources reside on a file server, while the resources run on a = client. Such labels (Multi-Level Security is but one example) are then used= as a basis for policy decisions. The draft is intended for people not fami= liar with NFS, and does a good job of explaining the different scenarios. F= or example, with a limited server, it is up to the client to decide about a= uthorization for accessing resources, and the server functions solely as a = store. This model is surprising to people familiar with, for example, web s= ervers, where the resources are considered to belong to the server, and it = is up to the server to make authorization decisions. Other NFS servers, cal= led "MAC-functional" have authorization decisions on both client and server= . I found the draft to be well-written and informative. I have a few comments, but I consider none of them show-stoppers: - The introduction has this text: "DAC systems offer no real protection aga= inst malicious or flawed software due to each program running with the full= permissions of the user executing it.". Put like that, this sentence is in= flammatory. Discretionary Access Control protects you against unauthorized = users running malicious software. It just doesn't protect against "good" us= ers being tricked into running bad software. - Section 3.3 uses the term "opaque". This is a surprising term, considerin= g this sentence about the opaque component: "The LFS component provides a m= echanism for identifying the structure and semantics of the opaque componen= t." So it's not really opaque, is it? The term "opaque" is commonly used w= hen the data is unparseable by the participants in the protocol. Here, the = client and a MAC-functional server can parse this data just fine. - I think the security considerations is missing some text on what addition= al security is needed in the case of a limited server that only stores the = information. Something should protect the data so that client A's data is n= ot served to client B, even if client B is malicious.=20 Yoav From leifj@sunet.se Sat Nov 2 13:36:53 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3585E11E824E; Sat, 2 Nov 2013 13:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4afvVM2dAF85; Sat, 2 Nov 2013 13:36:46 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC4811E824B; Sat, 2 Nov 2013 13:36:43 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id rA2KadQZ031842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 2 Nov 2013 21:36:39 +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 rA2KaZNQ004535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Nov 2013 21:36:37 +0100 (CET) X-Footer: c3VuZXQuc2U= Received: from [31.133.146.88] ([31.133.146.88]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.1.2) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Sat, 2 Nov 2013 21:36:33 +0100 Message-ID: <5275624F.5060500@sunet.se> Date: Sat, 02 Nov 2013 21:36:31 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: draft-sin-sdnrg-sdn-approach.all@tools.ietf.org, secdir@ietf.org, iesg@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: 09KIIADXH - 745c13bb54f4 - 20131102 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: [secdir] secdir review of draft-sin-sdnrg-sdn-approach-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 20:36:53 -0000 Folks, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is an informational overview of SDN providing an operational and service-provider perspective. My only comment is that the Security considerations section reads: "This document does not define any protocol nor architecture" and is otherwise blank, however there is a perfectly good section "On Security" just above it that could easily qualify as a security considerations section. My suggestion would be to rename "On Security" to "Security Considerations". Cheers Leif From Tom.Haynes@netapp.com Sat Nov 2 14:08:23 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442D011E823E; Sat, 2 Nov 2013 14:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.073 X-Spam-Level: X-Spam-Status: No, score=-9.073 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQsykpPykBy8; Sat, 2 Nov 2013 14:07:54 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 5B03111E8241; Sat, 2 Nov 2013 14:07:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,623,1378882800"; d="scan'208";a="289795681" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx1-out.netapp.com with ESMTP; 02 Nov 2013 14:07:51 -0700 Received: from SACEXCMBX05-PRD.hq.netapp.com ([169.254.8.3]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Sat, 2 Nov 2013 14:07:51 -0700 From: "Haynes, Tom" To: Yoav Nir Thread-Topic: SecDir Review of draft-ietf-nfsv4-labreqs Thread-Index: AQHO18c3l5Ocx4tIM0WjeGDw7jvwUJoS5PWA Date: Sat, 2 Nov 2013 21:07:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.114] Content-Type: text/plain; charset="us-ascii" Content-ID: <87216ABF88B2264C81E65D4921C3A6A4@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-nfsv4-labreqs.all@tools.ietf.org" , The IESG , "" Subject: Re: [secdir] SecDir Review of draft-ietf-nfsv4-labreqs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 21:08:24 -0000 inline... On Nov 2, 2013, at 5:29 AM, Yoav Nir wrote: > I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. These c= omments were written primarily for the benefit of the security area directo= rs. Document editors and WG chairs should treat these comments ust like any= other last call comments. >=20 > Short version: I think the draft is ready. >=20 > This draft is intended to be Informational. It does not specify any stand= ard. Instead, it describes the operating environment and assumptions behind= labeled NFS.=20 >=20 > Labeled NFS associates labels with resources (usually files) and processe= s, where the resources reside on a file server, while the resources run on = a client. Such labels (Multi-Level Security is but one example) are then us= ed as a basis for policy decisions. The draft is intended for people not fa= miliar with NFS, and does a good job of explaining the different scenarios.= For example, with a limited server, it is up to the client to decide about= authorization for accessing resources, and the server functions solely as = a store. This model is surprising to people familiar with, for example, web= servers, where the resources are considered to belong to the server, and i= t is up to the server to make authorization decisions. Other NFS servers, c= alled "MAC-functional" have authorization decisions on both client and serv= er. >=20 > I found the draft to be well-written and informative. >=20 > I have a few comments, but I consider none of them show-stoppers: >=20 > - The introduction has this text: "DAC systems offer no real protection a= gainst malicious or flawed software due to each program running with the fu= ll permissions of the user executing it.". Put like that, this sentence is = inflammatory. Discretionary Access Control protects you against unauthorize= d users running malicious software. It just doesn't protect against "good" = users being tricked into running bad software. >=20 Can rework.... > - Section 3.3 uses the term "opaque". This is a surprising term, consider= ing this sentence about the opaque component: "The LFS component provides a= mechanism for identifying the structure and semantics of the opaque compon= ent." So it's not really opaque, is it? The term "opaque" is commonly used= when the data is unparseable by the participants in the protocol. Here, th= e client and a MAC-functional server can parse this data just fine. >=20 I can't argue with your statement - I've tried and every time I get 20 word= s in, I disagree with what I am writing. The intent is that the payload of the component is not describable via the = protocol. seLinux might pick a different labeling scheme than say Trusted Solaris. I am willing to rewrite to get that intent through. > - I think the security considerations is missing some text on what additi= onal security is needed in the case of a limited server that only stores th= e information. Something should protect the data so that client A's data is= not served to client B, even if client B is malicious.=20 A limited server cannot parse the labels. In essence, the server is acting = like a disk array to the client. It simply passes the labels back to allow the client to act.= As a use case, it is actually very attractive in achieving parity with SAN based implementati= ons. I do believe there are now Linux NFSv4.2 prototypes available for just this purpose. Nothing prevents a server vendor from implementing some user ID and IP base= d schema to=20 provide a coarse control. >=20 > Yoav >=20 Thanks for the comments.= From simon@josefsson.org Sat Nov 2 14:40:25 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A87911E8243; Sat, 2 Nov 2013 14:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1I5L+2O13+T; Sat, 2 Nov 2013 14:40:21 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id CD45011E811D; Sat, 2 Nov 2013 14:40:20 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id rA2LeFiM024475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 2 Nov 2013 22:40:17 +0100 Date: Sat, 2 Nov 2013 22:40:14 +0100 From: Simon Josefsson To: secdir@ietf.org, draft-trammell-ipfix-tcpcontrolbits-revision.all@tools.ietf.org, iesg@ietf.org Message-ID: <20131102224014.1aca13bf@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: quoted-printable X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Subject: [secdir] Review of draft-trammell-ipfix-tcpcontrolbits-revision-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 21:40:25 -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. 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. =46rom 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? 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. 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. * 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. * The acronym IE is not spelled out. 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. * 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]: * The IANA-IPFIX reference looks bad in section 6.2. /Simon From clonvick@cisco.com Sat Nov 2 20:32:22 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EA811E8180; Sat, 2 Nov 2013 20:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wz+WCD6GZ7Zl; Sat, 2 Nov 2013 20:32:17 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EEFC311E817B; Sat, 2 Nov 2013 20:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1212; q=dns/txt; s=iport; t=1383449534; x=1384659134; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=WtDjW5DfZhlmcCx8SeXdhOulGBcLerY4CW42+C6zTe8=; b=gim/zZocrtkWrzaY8VAjaxYb2ZtFB3yK7L/FQmhG9g+gqw7hX3KQwQ/u 2J9H2a27wVSFtLRV67lSbRcujv2QlpsNlPRgtzIkIpmgETsBH/IiKe50D R/ucu8Cysr1SRWEwE2N+4/Jj39SgfJ3iVK0k/NF/guigVFf+0wyDoGgYZ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAA7DdVKtJV2d/2dsb2JhbABZgweBC79OgR0WdIInAQQ6UQEqFEImAQQBGod5vRmPJ4NYgQ4DqhODJoIq X-IronPort-AV: E=Sophos;i="4.93,624,1378857600"; d="scan'208";a="276947585" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 03 Nov 2013 03:32:13 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rA33WDFu003057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 3 Nov 2013 03:32:13 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.147]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Sat, 2 Nov 2013 22:32:12 -0500 From: "Chris Lonvick (clonvick)" To: "draft-ietf-multimob-handover-optimization.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: SECDIR review of draft-ietf-multimob-handover-optimization-05.txt Thread-Index: Ac7YRCCJUSILibbkQouNb6tLR/Pk+Q== Date: Sun, 3 Nov 2013 03:32:11 +0000 Message-ID: <9BB92CB59918E1418A06FD4E3269FABE2AB21319@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.21.64.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] SECDIR review of draft-ietf-multimob-handover-optimization-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 03:32:22 -0000 Hi,=0A= =0A= I have reviewed this document as part of the security directorate's =0A= ongoing effort to review all IETF documents being processed by the =0A= IESG. These comments were written primarily for the benefit of the =0A= security area directors. Document editors and WG chairs should treat =0A= these comments just like any other last call comments.=0A= =0A= Overall, I found the document to be understandable and I believe that all o= f the security concerns have been documented.=0A= =0A= I did find some editorial nits that you may want to address.=0A= =0A= In Section 2, the phrase "Along this document..." is used. It would be bet= ter to use something like, "In this document...".=0A= =0A= In Section 4.3.1.2, the phrase "which is be responsible of managing this co= unter." is used. I think it would be better to use "which is responsible f= or managing this counter.".=0A= =0A= The first sentence in Section 9 is, "This document defines the new followin= g elements which values to be allocated by IANA:" I think it would be bett= er to say "This document establishes new assignments to the IANA mobility p= arameters registry."=0A= =0A= Best regards,=0A= Chris= From ynir@checkpoint.com Sun Nov 3 10:26:36 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B40711E82CD; Sun, 3 Nov 2013 10:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.38 X-Spam-Level: X-Spam-Status: No, score=-10.38 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bijk6X2xuEeR; Sun, 3 Nov 2013 10:26:30 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECB511E82CB; Sun, 3 Nov 2013 10:26:27 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA3IQDTU021675; Sun, 3 Nov 2013 20:26:21 +0200 X-CheckPoint: {527693FE-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Sun, 3 Nov 2013 20:26:13 +0200 From: Yoav Nir To: "Haynes, Tom" Thread-Topic: SecDir Review of draft-ietf-nfsv4-labreqs Thread-Index: AQHO18c3l5Ocx4tIM0WjeGDw7jvwUJoS5PWAgADOSQA= Date: Sun, 3 Nov 2013 18:26:12 +0000 Message-ID: <0665E0C6-DFB6-4CA5-B261-CB3AD27DEB50@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.239] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-ID: <94EA0D76F8840D4E96E5BE48E5F7AE9E@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-nfsv4-labreqs.all@tools.ietf.org" , The IESG , "" Subject: Re: [secdir] SecDir Review of draft-ietf-nfsv4-labreqs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 18:26:36 -0000 On Nov 2, 2013, at 2:07 PM, "Haynes, Tom" wrote: > inline... >=20 > On Nov 2, 2013, at 5:29 AM, Yoav Nir wrote: >=20 >> I have reviewed this document as part of the security directorate's ongo= ing effort to review all IETF documents being processed by the IESG. These = comments were written primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments ust like an= y other last call comments. >>=20 >> Short version: I think the draft is ready. >>=20 >> This draft is intended to be Informational. It does not specify any stan= dard. Instead, it describes the operating environment and assumptions behin= d labeled NFS.=20 >>=20 >> Labeled NFS associates labels with resources (usually files) and process= es, where the resources reside on a file server, while the resources run on= a client. Such labels (Multi-Level Security is but one example) are then u= sed as a basis for policy decisions. The draft is intended for people not f= amiliar with NFS, and does a good job of explaining the different scenarios= . For example, with a limited server, it is up to the client to decide abou= t authorization for accessing resources, and the server functions solely as= a store. This model is surprising to people familiar with, for example, we= b servers, where the resources are considered to belong to the server, and = it is up to the server to make authorization decisions. Other NFS servers, = called "MAC-functional" have authorization decisions on both client and ser= ver. >>=20 >> I found the draft to be well-written and informative. >>=20 >> I have a few comments, but I consider none of them show-stoppers: >>=20 >> - The introduction has this text: "DAC systems offer no real protection = against malicious or flawed software due to each program running with the f= ull permissions of the user executing it.". Put like that, this sentence is= inflammatory. Discretionary Access Control protects you against unauthoriz= ed users running malicious software. It just doesn't protect against "good"= users being tricked into running bad software. >>=20 >=20 > Can rework.... >=20 >> - Section 3.3 uses the term "opaque". This is a surprising term, conside= ring this sentence about the opaque component: "The LFS component provides = a mechanism for identifying the structure and semantics of the opaque compo= nent." So it's not really opaque, is it? The term "opaque" is commonly use= d when the data is unparseable by the participants in the protocol. Here, t= he client and a MAC-functional server can parse this data just fine. >>=20 >=20 > I can't argue with your statement - I've tried and every time I get 20 wo= rds in, I disagree with > what I am writing. >=20 > The intent is that the payload of the component is not describable via th= e protocol. seLinux > might pick a different labeling scheme than say Trusted Solaris. >=20 > I am willing to rewrite to get that intent through. So how about=85 OLD: To accomplish this the labels MUST consist of an opaque component bound with a Label Format Specifier (LFS). NEW: To accomplish this the labels MUST consist of a format-specific component bound with a Label Format Specifier (LFS). >> - I think the security considerations is missing some text on what addit= ional security is needed in the case of a limited server that only stores t= he information. Something should protect the data so that client A's data i= s not served to client B, even if client B is malicious.=20 >=20 >=20 > A limited server cannot parse the labels. In essence, the server is actin= g like a disk array > to the client. It simply passes the labels back to allow the client to ac= t. As a use case, it > is actually very attractive in achieving parity with SAN based implementa= tions. I do believe > there are now Linux NFSv4.2 prototypes available for just this purpose. >=20 > Nothing prevents a server vendor from implementing some user ID and IP ba= sed schema to=20 > provide a coarse control. Great. That's the text I was missing. >=20 >=20 >=20 >>=20 >> Yoav >>=20 >=20 > Thanks for the comments. > Email secured by Check Point From cjbc@it.uc3m.es Sun Nov 3 10:46:44 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3F211E82DC; Sun, 3 Nov 2013 10:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1qKa6VFyQrI; Sun, 3 Nov 2013 10:46:39 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id CDE9211E82D4; Sun, 3 Nov 2013 10:46:38 -0800 (PST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A9E2CCD58D3; Sun, 3 Nov 2013 19:46:34 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [10.122.115.223] (unknown [207.230.251.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 564BFCADC46; Sun, 3 Nov 2013 19:46:33 +0100 (CET) Message-ID: <1383504390.3964.10.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Chris Lonvick (clonvick)" Date: Sun, 03 Nov 2013 19:46:30 +0100 In-Reply-To: <9BB92CB59918E1418A06FD4E3269FABE2AB21319@xmb-rcd-x06.cisco.com> References: <9BB92CB59918E1418A06FD4E3269FABE2AB21319@xmb-rcd-x06.cisco.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20266.001 Cc: "draft-ietf-multimob-handover-optimization.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-multimob-handover-optimization-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 18:46:45 -0000 Dear Chris, thanks for your review. Some comments inline below... On Sun, 2013-11-03 at 03:32 +0000, Chris Lonvick (clonvick) 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. > > Overall, I found the document to be understandable and I believe that all of the security concerns have been documented. > > I did find some editorial nits that you may want to address. > > In Section 2, the phrase "Along this document..." is used. It would be better to use something like, "In this document...". [Authors] Thanks, we'll change it. > > In Section 4.3.1.2, the phrase "which is be responsible of managing this counter." is used. I think it would be better to use "which is responsible for managing this counter.". [Authors] Thanks, we'll fix it in -06. > > The first sentence in Section 9 is, "This document defines the new following elements which values to be allocated by IANA:" I think it would be better to say "This document establishes new assignments to the IANA mobility parameters registry." [Authors] OK, we'll change that in -06. Thanks again, Carlos > > Best regards, > Chris From ynir@checkpoint.com Sun Nov 3 10:54:35 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7989921E8108; Sun, 3 Nov 2013 10:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.493 X-Spam-Level: X-Spam-Status: No, score=-10.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU657Nym6ULK; Sun, 3 Nov 2013 10:54:31 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4669521E80BF; Sun, 3 Nov 2013 10:54:26 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA3IsMHF024685; Sun, 3 Nov 2013 20:54:22 +0200 X-CheckPoint: {52769A97-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Sun, 3 Nov 2013 20:54:22 +0200 From: Yoav Nir To: "" , The IESG , "draft-weis-gdoi-iec62351-9@tools.ietf.org" Thread-Topic: SecDir-ish Review of draft-weis-gdoi-iec62351-9-02 Thread-Index: AQHO2MYb3pOxi66Il0e9xzu1/y7hHQ== Date: Sun, 3 Nov 2013 18:54:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.239] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <182A91B1B980654692283DE866B5BEC9@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] SecDir-ish Review of draft-weis-gdoi-iec62351-9-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 18:54:35 -0000 Hi there. At Sean's request, I've done a SecDir-ish review of draft-weis-gdoi-iec6235= 1-9-02. I think it is in pretty good shape, but I do have some concerns. First, an apology: the draft embeds OIDs in IKE packets. Throughout this re= view I use the term "ASN.1" for both the objects and the encoding. I do rea= lize that ASN means abstract syntax notation, and that the correct term to = use for the encoding ia BER, but this is a very common misuse. The draft do= es get this correct. I am somewhat confused by the IEC standards numbers. The abstract and intro= duction mostly discuss IEC 61850, which is the "power utility automation" f= amily of standards. On the other hand, the number in the title of the draft= is IEC 62351. There is a reference to a document called "IEC 62351 Part 9 = - Key Management". I can see how this draft relates to key management, but = "part 9" of what? Another thing that's missing for me, as one uninitiated in the ways of the = IEC, is what are we negotiating keys for? I get that it's not IPsec, but at= the end of the protocol, we have keys that are distributed to group member= s. Now, what is this data layer that can now use them. A reference to some = standard ("IEC-61850-9-2" would be OK), but since these are not widely avai= lable, some short description of what this protocol looks like would be gre= at. Another generic comment is about the IANA considerations as well as parts o= f section 2.2. Why do we need to establish new registries, that are duplica= tes of IPsec registries with one additional value? I know there has been so= me resistance to adding things there for stuff that's "not IKE", but with t= his already done in RFC 6932 ([1],[2]), that ship has left the station afte= r the horses had bolted. Why is there an OID_LENGTH field? All ASN.1 structures are self-describing= in terms of length. There can be a good reason: so that you can implement = with a bitwise comparison rather than implementing an ASN.1 parser. Please = say so if that's the reason. I didn't quite get where each of the OIDs in the ID payload (figure 2) and = the TEK payload (figure 4) come from. Are they the same? Appendix A suggest= s that they're not. So, - what does "type of traffic" mean? =20 - Appendix A says "OID=3D" in the TEK payload. What is k? Yoav [1] http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ips= ec-registry-10 [2] http://tools.ietf.org/html/rfc6932=09 From alexey.melnikov@isode.com Sun Nov 3 11:08:15 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A83621E80C7 for ; Sun, 3 Nov 2013 11:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZJMsLApzSXn for ; Sun, 3 Nov 2013 11:08:14 -0800 (PST) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 079CC21E809A for ; Sun, 3 Nov 2013 11:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1383505691; d=isode.com; s=selector; i=@isode.com; bh=2wkfvqMbsCM7rSRgbFqM33tRoudPxmF2C9E6eRbZsFY=; 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=m4IGQ0U1zA2NLV3jxt1JLf3LM49uXZlCcdiFeVaPx1wryK/ZdoWCF5d4G5753uFRnFqwdw w5RL1cYLwHP56G6xSvG4HJW3gnYLH6pTVIBuVQ0+Jmmk52KHbSgTGJ4IS11HifHN7wJ2bl 1jh0fIe6m4MZCctHIRW5qn2xUTsKtlk=; Received: from [172.16.0.7] ((unknown) [184.69.150.122]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 3 Nov 2013 19:08:10 +0000 X-SMTP-Protocol-Errors: NORDNS PIPELINING Message-ID: <52769F16.6000905@isode.com> Date: Sun, 03 Nov 2013 11:08:06 -0800 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: secdir@ietf.org, draft-ietf-httpbis-method-registrations.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Review of draft-ietf-httpbis-method-registrations-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 19:08:15 -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. Summary: This is an informational document which registers those Hypertext Transfer Protocol (HTTP) methods which have been defined in standards-track RFCs before the IANA HTTP Method Registry was established. The document is purely administrative, so from a security point of view, I see no issues with this document. From Tom.Haynes@netapp.com Sun Nov 3 11:15:29 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F2321E8104; Sun, 3 Nov 2013 11:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=-2.831, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCJheh-IRgKs; Sun, 3 Nov 2013 11:15:22 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id D7F5D21E80FF; Sun, 3 Nov 2013 11:15:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,627,1378882800"; d="scan'208";a="68875450" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 03 Nov 2013 11:15:17 -0800 Received: from SACEXCMBX05-PRD.hq.netapp.com ([169.254.8.3]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Sun, 3 Nov 2013 11:15:17 -0800 From: "Haynes, Tom" To: Yoav Nir Thread-Topic: SecDir Review of draft-ietf-nfsv4-labreqs Thread-Index: AQHO18c3l5Ocx4tIM0WjeGDw7jvwUJoS5PWAgADOSQCAAC9C8A== Date: Sun, 3 Nov 2013 19:15:16 +0000 Message-ID: <3E4AD982-592B-4F8E-A41D-639FAFB18226@netapp.com> References: , <0665E0C6-DFB6-4CA5-B261-CB3AD27DEB50@checkpoint.com> In-Reply-To: <0665E0C6-DFB6-4CA5-B261-CB3AD27DEB50@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-nfsv4-labreqs.all@tools.ietf.org" , The IESG , "" Subject: Re: [secdir] SecDir Review of draft-ietf-nfsv4-labreqs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 19:15:29 -0000 > On Nov 3, 2013, at 10:26 AM, "Yoav Nir" wrote: >=20 >=20 >> On Nov 2, 2013, at 2:07 PM, "Haynes, Tom" wrote: >>=20 >> inline... >>=20 >>> On Nov 2, 2013, at 5:29 AM, Yoav Nir wrote: >>>=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 direc= tors. Document editors and WG chairs should treat these comments ust like a= ny other last call comments. >>>=20 >>> Short version: I think the draft is ready. >>>=20 >>> This draft is intended to be Informational. It does not specify any sta= ndard. Instead, it describes the operating environment and assumptions behi= nd labeled NFS.=20 >>>=20 >>> Labeled NFS associates labels with resources (usually files) and proces= ses, where the resources reside on a file server, while the resources run o= n a client. Such labels (Multi-Level Security is but one example) are then = used as a basis for policy decisions. The draft is intended for people not = familiar with NFS, and does a good job of explaining the different scenario= s. For example, with a limited server, it is up to the client to decide abo= ut authorization for accessing resources, and the server functions solely a= s a store. This model is surprising to people familiar with, for example, w= eb servers, where the resources are considered to belong to the server, and= it is up to the server to make authorization decisions. Other NFS servers,= called "MAC-functional" have authorization decisions on both client and se= rver. >>>=20 >>> I found the draft to be well-written and informative. >>>=20 >>> I have a few comments, but I consider none of them show-stoppers: >>>=20 >>> - The introduction has this text: "DAC systems offer no real protection= against malicious or flawed software due to each program running with the = full permissions of the user executing it.". Put like that, this sentence i= s inflammatory. Discretionary Access Control protects you against unauthori= zed users running malicious software. It just doesn't protect against "good= " users being tricked into running bad software. >>>=20 >>=20 >> Can rework.... >>=20 >>> - Section 3.3 uses the term "opaque". This is a surprising term, consid= ering this sentence about the opaque component: "The LFS component provides= a mechanism for identifying the structure and semantics of the opaque comp= onent." So it's not really opaque, is it? The term "opaque" is commonly us= ed when the data is unparseable by the participants in the protocol. Here, = the client and a MAC-functional server can parse this data just fine. >>>=20 >>=20 >> I can't argue with your statement - I've tried and every time I get 20 w= ords in, I disagree with >> what I am writing. >>=20 >> The intent is that the payload of the component is not describable via t= he protocol. seLinux >> might pick a different labeling scheme than say Trusted Solaris. >>=20 >> I am willing to rewrite to get that intent through. >=20 > So how about=85 >=20 > OLD: > To accomplish this the labels > MUST consist of an opaque component bound with a Label Format > Specifier (LFS). > NEW: > To accomplish this the labels > MUST consist of a format-specific component bound with a Label > Format Specifier (LFS). Agreed. >=20 >>> - I think the security considerations is missing some text on what addi= tional security is needed in the case of a limited server that only stores = the information. Something should protect the data so that client A's data = is not served to client B, even if client B is malicious.=20 >>=20 >>=20 >> A limited server cannot parse the labels. In essence, the server is acti= ng like a disk array >> to the client. It simply passes the labels back to allow the client to a= ct. As a use case, it >> is actually very attractive in achieving parity with SAN based implement= ations. I do believe >> there are now Linux NFSv4.2 prototypes available for just this purpose. >>=20 >> Nothing prevents a server vendor from implementing some user ID and IP b= ased schema to=20 >> provide a coarse control. >=20 > Great. That's the text I was missing. >=20 >>=20 >>=20 >>=20 >>>=20 >>> Yoav >>>=20 >>=20 >> Thanks for the comments. >> Email secured by Check Point >=20 From hallam@gmail.com Sun Nov 3 12:24:54 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2403811E8169 for ; Sun, 3 Nov 2013 12:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSIh4yRuG8iU for ; Sun, 3 Nov 2013 12:24:53 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id A5A1821E8115 for ; Sun, 3 Nov 2013 12:24:50 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id u14so4756359lbd.8 for ; Sun, 03 Nov 2013 12:24:49 -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=8Z3F++rBGbqenf+os1evM0LOAHGWSGEwZZ1nTcaJLGw=; b=nILbGQHr+QRLCVYGLrI6cEiCW2vUMDQ9AYn7oUytgnjmPhnOteGzK/mhUEZ3EQ3Nc/ 2GMLrPQnXIdtvmUosLlZUw6tcrEEihVBo1GXJvKA2gs/0pVXZHxOvrELDYu7N+viHJDd +IVgo8zlMtMr/BjjGpp+Wzz4/Dlzl3JYlphoe2uYSmHTm93OA9vio4+7FAtPt8vF3Ll9 MkrljBabXGLTzXoPVnkVOJqAMR+OloqGEDh8aHo4mrmijpENqocozrAsfKQth1oWDzwG oDBvPYxXd8NP/VH3Rer2fHKOa9e+UJQW+pPDpqirizz9AAvROqLs7Tq40US6S8KGoIdd Fr+w== MIME-Version: 1.0 X-Received: by 10.152.6.169 with SMTP id c9mr2186362laa.28.1383510289524; Sun, 03 Nov 2013 12:24:49 -0800 (PST) Received: by 10.112.46.98 with HTTP; Sun, 3 Nov 2013 12:24:49 -0800 (PST) Date: Sun, 3 Nov 2013 15:24:49 -0500 Message-ID: From: Phillip Hallam-Baker To: "secdir@ietf.org" , draft-ietf-ccamp-gmpls-ospf-g709v3-10.all@tools.ietf.org Content-Type: multipart/alternative; boundary=089e01493c0659aced04ea4b971f Subject: [secdir] SECDIR Review of draft-ietf-ccamp-gmpls-ospf-g709v3-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 20:24:54 -0000 --089e01493c0659aced04ea4b971f 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. G.709 Optical Transport Network introduces new parameters that need to be expressible in GMPLS and OSPF-TE. This drafts adds support within the existing framework. The security considerations section appropriately consists of a brief explanation of why a citation to the existing security framework document is sufficient and the citation to the relevant document which is sufficiently recent (2010) for these purposes. The document raises no new security considerations that need to be considered since routing is not considered to be a confidentiality or integrity layer for Internet purposes. If preventing traffic analysis was desired it would probably be more appropriate to apply link layer security and flood fill the links in any case. -- Website: http://hallambaker.com/ --089e01493c0659aced04ea4b971f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's
ongoin= g effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
ar= ea directors. Document editors and WG chairs should treat these
comments= just like any other last call comments.

G.709 Optica=
l Transport Network introduces new parameters that need to be expressible i=
n GMPLS and  OSPF-TE. This drafts adds support within the existing framewor=
k.

The security considerations section appro=
priately consists of a brief explanation of why a citation to the existing =
security framework document is sufficient and the citation to the relevant =
document which is sufficiently recent (2010) for these purposes.


The document raises no new security consi=
derations that need to be considered since routing is not considered to be =
a confidentiality or integrity layer for Internet purposes. If preventing t=
raffic analysis was desired it would probably be more appropriate to apply =
link layer security and flood fill the links in any case.


--
Website: http://hallambaker.com/
--089e01493c0659aced04ea4b971f-- From kathleen.moriarty@emc.com Sun Nov 3 15:28:11 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5B321E80DC; Sun, 3 Nov 2013 15:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5Fi3NsptGAA; Sun, 3 Nov 2013 15:28:07 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4243411E8251; Sun, 3 Nov 2013 15:28:04 -0800 (PST) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA3NRP0O009874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Nov 2013 18:27:25 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com rA3NRP0O009874 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1383521247; bh=eDKbkvBWKimuO+JqwjcpxvhZgms=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=b6T0xDJf+9ZITfTjRRiTN4mPynEADsQ0IfbBSSRHw0m6/Z5NZAjMN955qaAFDMUNJ NSUKUruJd9xpSTes2Xjbx9fK6sojKUdIci2+pcie20C0LB5KWa3aHt4QNSCIfBrdhb nkdIpETZdyBIiqyaBooogDUOJnccFmfi7nU4O87s= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com rA3NRP0O009874 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd55.lss.emc.com (RSA Interceptor); Sun, 3 Nov 2013 18:27:15 -0500 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA3NRDE4030103 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 3 Nov 2013 18:27:13 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Sun, 3 Nov 2013 18:27:12 -0500 From: "Moriarty, Kathleen" To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org" Date: Sun, 3 Nov 2013 18:27:12 -0500 Thread-Topic: Sec Dir review of draft-ietf-mpls-ldp-multi-topology-09.txt Thread-Index: AQHO2OwspRhWMDZGTEewZuLZvdGEBQ== 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: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Cc: "rtorvi@juniper.net" , "daniel@olddog.co.uk" , "lichenyj@chinamobile.com" , "huaimochen@huawei.com" , "zhenbin.li@huawei.com" , "huanglu@chinamobile.com" , "ning.so@tatacommunications.com" , "emily.chen220@gmail.com" Subject: [secdir] Sec Dir review of draft-ietf-mpls-ldp-multi-topology-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 23:28:12 -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. Review: It is unclear to me how there could not be any security considerations. Th= e draft introduces the ability to segregate traffic, allowing for the MT ca= pability to be supported and then transitioned to equipment where the capab= ility is not supported. See section 3.2: If an LSR is changed from IGP-MT capable to non-MT capable, it may wait until the routes update to withdraw FEC and release the label mapping for existing LSPs of specific MT. The introduction states this feature may be used to segregate traffic for d= ifferent purposes, including the use of management traffic. Typically, man= agement traffic requires security protections such as session encryption. = The labeling also appears to allow for labels to change in addition to the = feature support disappearing. The security considerations should at least = mention that no additional protections are offered through this mechanism o= f segregating traffic, so that the reader is informed of this risk. The ad= vantages may be limited to QoS and other possible benefits. Users should b= e aware that the segregation offers no security advantage over MPLS without= MT. Editorial nits: In Introduction, change from isolated to isolate: Separate routing and MPLS domains may be used to isolated multicast and IPv6 islands within the backbone network. To: Separate routing and MPLS domains may be used to isolate multicast and IPv6 islands within the backbone network. Change Carries to carry: Management traffic could be separated from customer traffic using multiple MTs, where the management traffic MT does not use links that carries customer traffic. To: Management traffic could be separated from customer traffic using multiple MTs, where the management traffic MT does not use links that carry customer traffic. Section 3.6: Change "imply" to "simply": Since using different label spaces for different topologies would imply significant changes to the data plane, a single global label space is supported in this solution.=20 Change "peer" to "peers": There will be one session supported for each pair of peer, even there are multiple topologies supported between these two peers. Section 4.3.4: Change from: For the case that the LSP ping with return path not specified , the reply packet must go through the default topology instead of the topology where the Echo Request goes through. To: For the case that the LSP ping with return path is not specified, the reply packet must go through the default topology instead of the topology where the Echo Request goes through. Section 5.1: Recommend breaking this text into multiple sentences. Section 6: Change from: In case the bad things does happen, according to [RFC5036], processing of such message should be aborted. To: In case the bad things happen, according to [RFC5036], processing of such messages should be aborted. Section 7: I recommend breaking the second paragraph into multiple sentence= s. Best regards, Kathleen From bew@cisco.com Mon Nov 4 02:11:33 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B6911E80D9; Mon, 4 Nov 2013 02:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.418 X-Spam-Level: X-Spam-Status: No, score=-110.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aL4OKKASVTJl; Mon, 4 Nov 2013 02:11:18 -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 192AF11E8264; Mon, 4 Nov 2013 02:04:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6919; q=dns/txt; s=iport; t=1383559486; x=1384769086; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=t4YWO5kxImol6UtU/MWio8NzF96zGGBtFq5zP0g5HYA=; b=FfqxU/L2TxBbnTqCjjztigZCSpnlbctHLSMVbOd4EgcXuu4Zjc07sINi nlz6t3Oacd79RWaah9XtVAii3NEHm+Y86673EDbdGpE1e/dZigR+l/Sy0 lUL7eJboMoHUllGDtCy9OXLXoV3G/7Vr+skkL0K3qCdt2oUKl3O5XF4pY I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcKAPNwd1KrRDoI/2dsb2JhbABWA4MHOKsklCFLgSMWdIIlAQEBAwEBAQFrCwULCw44JzAGEwmHcgUOtUKIR44PEYEFIxAHEYMPgQ4DiUCOSoEvkFqDRxuBNQ X-IronPort-AV: E=Sophos;i="4.93,631,1378857600"; d="scan'208";a="96491076" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 04 Nov 2013 10:04:21 +0000 Received: from sjc-vpn4-1274.cisco.com (sjc-vpn4-1274.cisco.com [10.21.84.249]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA4A4JEk015782; Mon, 4 Nov 2013 10:04:20 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: Mon, 4 Nov 2013 02:04:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Yoav Nir X-Mailer: Apple Mail (2.1510) Cc: "draft-weis-gdoi-iec62351-9@tools.ietf.org" , The IESG , "" Subject: Re: [secdir] SecDir-ish Review of draft-weis-gdoi-iec62351-9-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 10:11:34 -0000 Hi Yoav, Many thanks for your review. On Nov 3, 2013, at 10:54 AM, Yoav Nir wrote: > Hi there. >=20 > At Sean's request, I've done a SecDir-ish review of = draft-weis-gdoi-iec62351-9-02. I think it is in pretty good shape, but I = do have some concerns. >=20 > First, an apology: the draft embeds OIDs in IKE packets. Throughout = this review I use the term "ASN.1" for both the objects and the = encoding. I do realize that ASN means abstract syntax notation, and that = the correct term to use for the encoding ia BER, but this is a very = common misuse. The draft does get this correct. The draft actually uses DER encoding, which I believe is the case for = most ASN.1 encoding in RFCs. This should be stated to avoid confusion.=20= > I am somewhat confused by the IEC standards numbers. The abstract and = introduction mostly discuss IEC 61850, which is the "power utility = automation" family of standards. On the other hand, the number in the = title of the draft is IEC 62351. There is a reference to a document = called "IEC 62351 Part 9 - Key Management". I can see how this draft = relates to key management, but "part 9" of what? For the benefit of the secdir audience here's Herb's reply from the = original email thread and your reply: >> [Herb]: I don=92t understand the question. So I will try to = explain. IEC 61850 is a set of communication standards developed under = IEC Technical Committee 57. IEC TC57 has WG15 that was formed to = address security for the breadth of standards that are developed under = TC57, including IEC 61850. In IEC, the designations within a family of = standards (e.g. 61850 or 62351) are called parts. IEC 61850 has over 10 = standards that are 61850-1 through 61850-10 (e.g. 10 parts). = Chapters/sub-chapters are called =93clauses=94 in IEC. So when it = mentions IEC 62351 Part 9 =96 Key Management, the official reference is = =93IEC 62351-9 Ed. 1.0 Power systems management and associated = information exchange - Data and communications security - Part 9: Cyber = security key management for power system equipment (Future IEC 62351-9 = TS Ed.1)=94. When IEC removes the ED 1.0, it means refer to the current = revisions (ED.2 has almost been completed). The =93Power systems = management and associated information exchange - Data and communications = security=94 is the charter of WG15 and the overall scope of 62351 (they = all have that in their title). Therefore, =93IEC 62351 Part 9 =96 Key = Management=94 could be referred to as =93IEC 62351-9=94, =93IEC 62351-9 = : Cyber security key management for power system equipment=94, or in = presentations =93IEC 62351-9=96 Key Management=94. So, I would change = to IEC 62351-9 (and give the full name). Sorry for the long = explanation. >>=20 > [Yoav] OK. I guess the IEC standards have a more complicated naming = convention than RFCs .I'm just missing an overall title for 62351.=20 We can summarize Herb's description above in the Introduction, if that = would help. > Another thing that's missing for me, as one uninitiated in the ways of = the IEC, is what are we negotiating keys for? I get that it's not IPsec, = but at the end of the protocol, we have keys that are distributed to = group members. Now, what is this data layer that can now use them. A = reference to some standard ("IEC-61850-9-2" would be OK), but since = these are not widely available, some short description of what this = protocol looks like would be great. OK. > Another generic comment is about the IANA considerations as well as = parts of section 2.2. Why do we need to establish new registries, that = are duplicates of IPsec registries with one additional value? I know = there has been some resistance to adding things there for stuff that's = "not IKE", but with this already done in RFC 6932 ([1],[2]), that ship = has left the station after the horses had bolted. This is a different situation from RFC 6932. (In fact, since GDOI is = IKEv1-based what you're asking for will add to the RFC 2409 registries, = which RFC 6932 says is discouraged.) I have some sympathy for saying we should have one list of algorithms = that all protocols should use, but in fact every protocol (in this case = the IEC set of protocols) would have to declare which subset of the = algorithm list they support in a normative fashion. That complexity does = not belong in the notes section of [1], IMO. Non-IPsec protocol-specific = subsets will change over time and have to be maintained somewhere ... a = new protocol-specific registry is the right place to do that. By the way, the IEC standards defines truncation values for HMAC-SHA256 = that are not duplicates. >=20 > Why is there an OID_LENGTH field? All ASN.1 structures are = self-describing in terms of length. There can be a good reason: so that = you can implement with a bitwise comparison rather than implementing an = ASN.1 parser. Please say so if that's the reason. The OID_LENGTH field is not strictly required, since the DER includes = the length. Maintaining the length outside of the DER is valuable for = payload manipulation where parsing the DER is not otherwise necessary = (e.g., copying the DER into the payload, payload length sanity checks, = etc.). We'll add that. >=20 > I didn't quite get where each of the OIDs in the ID payload (figure 2) = and the TEK payload (figure 4) come from. Are they the same? Appendix A = suggests that they're not. So, The OID in the ID payload will match the OID in the TEK payload if the = group represented by the ID payload has only one multicast sender. This = is shown in Appendix A (modulo a typo, see below). Sorry for the = confusion. To answer the broader question, there could be multiple multicast = senders represented by the OID, so the group key server would return = multiple TEKs, each with unique OID & OID specific payload. This can be = made clearer in the draft. > - what does "type of traffic" mean? The IEC documents list several OID types, each of which is a "type of = traffic". This can be expanded. > =20 > - Appendix A says "OID=3D" in the TEK payload. What is k? That is a typo. It should be "OID=3D" matching the ID payload. Thanks, Brian >=20 >=20 > Yoav >=20 > [1] = http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-= registry-10 > [2] http://tools.ietf.org/html/rfc6932=09 >=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 Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From TurnerS@ieca.com Mon Nov 4 11:19:31 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18B011E81EA for ; Mon, 4 Nov 2013 11:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ao0KfaaqBlix for ; Mon, 4 Nov 2013 11:19:26 -0800 (PST) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [67.18.65.22]) by ietfa.amsl.com (Postfix) with ESMTP id 62DF921E815D for ; Mon, 4 Nov 2013 11:19:18 -0800 (PST) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 2FB3FCCFFC163; Mon, 4 Nov 2013 13:19:05 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 17FD1CCFFC118 for ; Mon, 4 Nov 2013 13:19:05 -0600 (CST) Received: from [31.133.164.114] (port=56214 helo=dhcp-a472.meeting.ietf.org) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VdPgD-0005Sm-3X for secdir@ietf.org; Mon, 04 Nov 2013 13:19:17 -0600 From: Sean Turner Content-Type: multipart/signed; boundary="Apple-Mail=_D0309CB7-EF80-46C9-AC8A-CCBB84432B63"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Date: Mon, 4 Nov 2013 11:19:08 -0800 References: <5268021A.6040108@ieca.com> To: secdir@ietf.org In-Reply-To: <5268021A.6040108@ieca.com> X-Mailer: Apple Mail (2.1816) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-a472.meeting.ietf.org) [31.133.164.114]:56214 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Subject: Re: [secdir] secdir lunch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 19:19:32 -0000 --Apple-Mail=_D0309CB7-EF80-46C9-AC8A-CCBB84432B63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We=92ve been assigned Plaza B for secdir lunch. See you all there. spt On Oct 23, 2013, at 10:06, Sean Turner wrote: > I've reserved a room for our usual secdir lunch on Tuesday. The room = number has not been assigned and I will let you know when it is = assigned. >=20 > spt >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --Apple-Mail=_D0309CB7-EF80-46C9-AC8A-CCBB84432B63 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww ggJkoAMCAQICCQCdWMxKNutUeTANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE ChMKSUVDQSwgSW5jLjAeFw0xMzA0MDMxNDUxMThaFw0xNDA0MDMxNDUxMThaMDgxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOpCGCRptT1m+bIpLTmbahZLZ0Qe4X99f8SgTQ7QISvUfpmn tfOD1oA1AttXlOULEERYubzvDnUTXvstFomQx0XTA67IaV+mw9ODRtG1hPN/erdKX6sU6rH4tsEb ba3Drr/I0HT3YVvD3SjWtGXjF12XLvTP6+LfMIIDTCAPiEd9KPG23D7skVu/4BvvmdLFI96OARhg wQ86M+lTIn83KRJlbbfAeIevbRx/rUB7D+uvMdWxOzR0KZJhd6dEeTXVwBXZG4rnQ4uFM+mRSiD4 rxDCyOuIuOzR07tnOyCRio6sRipOZvwQUWttdsgMEs6IxLdWsaTXcs1HjCsxrdedovMCAwEAAaOB njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD VR0RBBQwEoEQVHVybmVyU0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB CwUAA4ICAQAimDYm77ppTi4vK6qJSUhyvCDMGb8mngiEXEYKxsfdHPWoDO7+06j7dAZ8sDD9/FtE kiUMyoNGSUmKHR+tGperVnNiM/Zk6WwCJv8dYZwhGXNQeEGzeys/UkFv7CFX7uDSn8GQeB8sOAZ1 N1hxV/TvT8qXvcRxP5+aWTAGAq3TKtCQxZjuU74L3st2hZiOhJlhjhqz0K5FIwWzXUK9uwhZe1th GUpDbRustVgmKN2Xa0pzwqI1VUO0jnWt24A4u59xo6DJQXzQVMhCx0xhpemuT9BrsBDTX8eJdI1i Wv9wp3ivSrfHjKXp8y8OGD+usiG40HCjj0W9C+dH0VfbgrB6QOI4vA9+kTg4mANth1cxyxwPYOSJ v0zi1qR0eDIGI//2v2/s6TmGuNqbnRa26Ldv5gGqS7xj32Fiaby6UOXs4+aAIWGZEOH+BXjozcvE eGBwjU/VRQYu6itR28PaNhNVji4D5ITaGxWWiycqK1EUaFraWHtk7W100ROX69xTeFVZP86D2ymi /aohl5Vb1vlYHdqlbgqjDRl9dPbTxVCXEHf+jkexcuwlLTvr7F+5DIN6c/EbCpRqQx3edy193L48 OGyRDh1/Wmzpew0VWWAWOSXGl/P9VzXf3Z6GPt7flN/V9iEJAa3Mo+w+eIdzJkHBWR+yJcqQcCRM MSyishMwLDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEzMTEwNDE5MTkwOFowIwYJKoZIhvcNAQkEMRYEFAjWNQwGQ/uEqUbjbGeZwheh +ZQ7MD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF Q0EsIEluYy4CCQCdWMxKNutUeTANBgkqhkiG9w0BAQEFAASCAQBjqkj79f2z2zJh7KzUzE7NaPfZ SF7KsRY0P1WHHW9xZcJ3G/z4Hj/bERCQlxye5q4yKdQo9Y/zTxsm1VRBZlMJ7+X9HBTPhqUcH9Lu QBExfVfKzp1ZNubAj3Vw/E3kTBr41ceQPklZzQtXruLwpf2zlJ0vfo2wwAwV7H8hE7q1OSXu8xga 7mezreKZJWKrj9TNdxgYp5+ggNWGarm0Daobe2xO+kOB9vHfCy912yGIKM/KDU+taqgL5l+6VylI htyxvhsNWuJxX2jmt75mimRSNGblhy2c2MbdswykYfsKm3+aoB0z4dSobV+pCS19dUyqiLAkJAci KeWV1c74JoWSAAAAAAAA --Apple-Mail=_D0309CB7-EF80-46C9-AC8A-CCBB84432B63-- From tjc@ecs.soton.ac.uk Mon Nov 4 16:50:10 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CE121F9CA9; Mon, 4 Nov 2013 16:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0itb8+VShZH; Mon, 4 Nov 2013 16:49:24 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 5E06821E836A; Mon, 4 Nov 2013 16:49:08 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA50mTX3006568; Tue, 5 Nov 2013 00:48:29 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rA50mTX3006568 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1383612510; bh=KOmvMs9pp1p0JR6EauYiHI8qOY8=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=mfvPEka8MMrDVQZl+P8YBTRZxAB2sSV2PpDs6Gn+vPRzCCCEj+a1vZA1ywfUolWyS 41Wa67TWcBhlJCvMfTExBMSIolxnuqKr+9qHQVtIbC+wuvDuw7iMkKw6OaGyhjXoxa UiiSCLD8zgijKDRR1VI/8JLcbrQARieuUmIaQO0M= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id pA40mY09596347695s ret-id none; Tue, 05 Nov 2013 00:48:30 +0000 Received: from wireless-v6.meeting.ietf.org (wireless-v6.meeting.ietf.org [IPv6:2001:67c:370:160:dc36:f9fb:865b:22c5] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA50l6Lu007907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Nov 2013 00:47:10 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_79A9B6B9-258E-4174-94B3-A16DC1412250" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Tim Chown In-Reply-To: Date: Tue, 5 Nov 2013 00:47:05 +0000 Message-ID: References: To: Samuel Weiler X-Mailer: Apple Mail (2.1816) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=pA40mY095963476900; tid=pA40mY09596347695s; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: rA50mTX3006568 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-Mailman-Approved-At: Mon, 04 Nov 2013 19:05:47 -0800 Cc: The IESG , draft-ietf-homenet-arch.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-homenet-arch-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 00:50:11 -0000 --Apple-Mail=_79A9B6B9-258E-4174-94B3-A16DC1412250 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Samuel, The diff for the -11 is available here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-arch-11.txt Comments in line, On 11 Sep 2013, at 03:53, Samuel Weiler wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 >=20 > Even though this is an architecture document, I think it deserves some = AD attention. >=20 >=20 > First: it seems odd to set an expectation for (near) = zero-configuration: >=20 > It is not practical to expect home users to configure their = networks. > Thus the assumption of this document is that the homenet is as far = as > possible self-organising and self-configuring, i.e. it should > function without pro-active management by the residential user. >=20 > and then decline to give any guidance about, arguably, the most = important security choice in the document: >=20 > This document takes no position on [whether 'default allow' or > 'default deny'] mode is the default, but assumes > the choice for the homenet to use either mode would be available. - added text in 3.8.2 (ops/mgmt section) about the default deny/allow = setting >=20 > I found the "Name spaces" section (3.7.3) a bit confusing, in part = because it doesn't specifically name DNS at the start of the section, = even though the details below clearly point to DNS (IDNA, possible = conflicts with dotless TLDs). Perhaps the second paragraph of 3.7.4, = explaining that there are some non-DNS alternatives under consideration, = should be moved up? Furthermore, there are some particular assertions = in both 3.7.3 and 3.7.4 that need to be reconsidered: - moved all of section 3.7.4 above 3.7.3; it seems to flow better this = way around? >=20 > -- "When DNS is used as the homenet name service, it includes both a > resolving service and an authoritative service." Does it > necessarily? - inserted "typically" wrt authoritative and resolving services >=20 > -- "The name space(s) should be served authoritatively by the > homenet..." Why is that necessary? (Indeed, there is text in > 3.7.4 that seems to conflict with this.) - on authoritative service - the WG consensus is to serve name space(s) = from the homenet; this means independent operation can be supported. > -- There is a recommendation to support DNSSEC on the authoritative > server side (in 3.7.4). Shouldn't there be a similar > recommendation on the resolver side? - on DNSSEC, the recommendation is intended to be for both; extra = sentence added Also, the phrase "secondary resolving name service" is clarified to = "secondary authoritative name service=94 =20 tim --Apple-Mail=_79A9B6B9-258E-4174-94B3-A16DC1412250 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Samuel,

Comments in = line,

On 11 Sep 2013, at 03:53, Samuel = Weiler <weiler@watson.org> = 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.


Even though this is an architecture = document, I think it deserves some AD attention.


First: it = seems odd to set an expectation for (near) zero-configuration:

=   It is not practical to expect home users to configure their = networks.
  Thus the assumption of this document is that = the homenet is as far  as
  possible self-organising = and self-configuring, i.e. it should
  function without = pro-active management by the residential user.

and then decline = to give any guidance about, arguably, the most important security choice = in the document:

  This document takes no position on = [whether 'default allow' or
  'default deny'] mode is the = default, but assumes
  the choice for the homenet to use = either mode would be available.

- added = text in 3.8.2 (ops/mgmt section) about the default deny/allow = setting


I found the "Name = spaces" section (3.7.3) a bit confusing, in part because it doesn't = specifically name DNS at the start of the section, even though the = details below clearly point to DNS (IDNA, possible conflicts with = dotless TLDs).  Perhaps the second paragraph of 3.7.4, explaining = that there are some non-DNS alternatives under consideration, should be = moved up?  Furthermore, there are some particular assertions in = both 3.7.3 and 3.7.4 that need to be reconsidered:

- = moved all of section 3.7.4 above 3.7.3; it seems to flow better this way = around?

-- "When DNS is used as the = homenet name service, it includes both a
  resolving = service and an authoritative service."  Does it
=   necessarily?

- inserted "typically" wrt = authoritative and resolving services

-- = "The name space(s) should be served authoritatively by the
=   homenet..."   Why is that necessary? =  (Indeed, there is text in
  3.7.4 that seems to = conflict with this.)

- on authoritative = service - the WG consensus is to serve name space(s) from the homenet; = this means independent operation can be = supported.

-- There is a = recommendation to support DNSSEC on the authoritative
=   server side (in 3.7.4).  Shouldn't there be a = similar
  recommendation on the resolver = side?

- on DNSSEC, the recommendation is = intended to be for both; extra sentence = added

Also, the phrase "secondary resolving = name service" is clarified to "secondary authoritative name service=94 =  

tim

= --Apple-Mail=_79A9B6B9-258E-4174-94B3-A16DC1412250-- From new-work-bounces@ietf.org Mon Nov 4 17:04:05 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA89911E8317; Mon, 4 Nov 2013 17:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1383613445; bh=LdyIGKKuTIGv3yvW8nopKnIkDkeETh9xNAVuKa/XFnA=; 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=fPfiV6uhPIwEdAWRu9Zouq4K7ZKsU6Cc3mSjrz/xQjwVq3XZm8q/9NEZ6Ohehr387 dmPjxoM6f8QzGWJQ+LjfjnK78nfhJvpY1Jv2FgTqHkg7NWQvxXEVjsUK2LzCv1wGAm +gzvGJZ/wDHYYiKRbIF5MGdKC11BL4D9I4bTWpjs= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E2311E82F7 for ; Mon, 4 Nov 2013 17:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnIsG5wYCApm for ; Mon, 4 Nov 2013 17:03:56 -0800 (PST) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) by ietfa.amsl.com (Postfix) with ESMTP id 91CA811E82C7 for ; Mon, 4 Nov 2013 17:03:52 -0800 (PST) X-LoopCount0: from 10.175.216.249 X-IronPort-AV: E=Sophos;i="4.93,636,1378875600"; d="scan'208,217";a="369290588" From: To: Date: Mon, 4 Nov 2013 19:03:47 -0600 Thread-Topic: IEEE 802 New Work Under Consideration @ Nov 2013 Plenary Thread-Index: Ac7ZwaoT3RhyKE0bRsabmcgooYcBBA== Message-ID: <28616F4740DDF542AA1DB7C9F5979639079B2298C4@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.12 Precedence: list Content-Type: multipart/mixed; boundary="===============6144060845344167173==" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 04 Nov 2013 19:05:47 -0800 Cc: paul.nikolich@att.net Subject: [secdir] [new-work] IEEE 802 New Work Under Consideration @ Nov 2013 Plenary X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 01:04:06 -0000 --===============6144060845344167173== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_28616F4740DDF542AA1DB7C9F5979639079B2298C4AUSX7MCPS301A_" --_000_28616F4740DDF542AA1DB7C9F5979639079B2298C4AUSX7MCPS301A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, The following Project Authorization Requests (PARs) will be considered at t= he Nov 2013 IEEE 802 Plenary: * 802 - Standard for Local and Metropolitan Area Networks: Overview and = Architecture - PAR extension request * 802.1AX-REV - PAR modification request * 802.1Q-REV - PAR modification request * 802.3br - amendment: Interspersing Express Traffic * 802.3bt - amendment: DTE Power via MDI over 4-Pair * 802.3bu - amendment: 1-Pair Power over Data Lines * 802.22 - Revision PAR * OmniRAN EC SG - Recommended Practice, Network Reference Model and Func= tional Description of IEEE 802 Access Network The PARs can be found at http://ieee802.org/PARs.shtml along with the suppo= rting 5 criteria (i.e. the explanations of how they fit the IEEE 802 criter= ia for initiating new work) Any comments on a proposed PAR should be sent to the Working Group chair id= entified on the PAR to be received by 5:00 PM (Central), Tuesday, Nov 12, 2= 013 (23:00 UTC Nov 12, 2013). Regards, John D'Ambrosia IEEE 802 LMSC Recording Secretary --_000_28616F4740DDF542AA1DB7C9F5979639079B2298C4AUSX7MCPS301A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

The following Project Authorization Requests (PARs) will be cons= idered at the Nov 2013 IEEE 802 Plenary:

  • 802 - Standard for Local and Metropolitan Area = Networks: Overview and Architecture - PAR extension request
    • =
  • 802.1AX-REV - PAR modi= fication request
  • 802.1Q-REV - PAR modification request
    • 802.3br - amendment: Interspersing Express Tra= ffic
  • 802.3bt - amendment: D= TE Power via MDI over 4-Pair
  • 802.22 - Revision PAR
  • OmniRAN EC SG - Recommended Practice, Network Reference = Model and Functional Description of IEEE 802 Access Network

The PARs can be f= ound at http://ieee802.org/PARs.s= html along with the supporting 5 criteria (i.e. the explanations of how= they fit the IEEE 802 criteria for initiating new work)

Any comments on a proposed = PAR should be sent to the Working Group chair identified on the PAR to be r= eceived by 5:00 PM (Central), Tuesday, Nov 12, 2013 (23:00 UTC Nov 12, 2013= ).

Regard= s,

John D’Ambrosia

<= p class=3DMsoNormal>IEEE 802 LMSC Recording Secretary

 

= --_000_28616F4740DDF542AA1DB7C9F5979639079B2298C4AUSX7MCPS301A_-- --===============6144060845344167173== 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 --===============6144060845344167173==-- From kivinen@iki.fi Mon Nov 4 23:34:38 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B859011E822C; Mon, 4 Nov 2013 23:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5ktS7g-I-kr; Mon, 4 Nov 2013 23:34:37 -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 A8D2711E8171; Mon, 4 Nov 2013 23:34:34 -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 rA57YWga008564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Nov 2013 09:34:32 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rA57YWmo020581; Tue, 5 Nov 2013 09:34:32 +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: <21112.40840.714558.901624@fireball.kivinen.iki.fi> Date: Tue, 5 Nov 2013 09:34:32 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-httpbis-p6-cache.all@tools.ietf.org X-Edit-Time: 6 min X-Total-Time: 6 min Subject: [secdir] Secdir review of draft-ietf-httpbis-p6-cache-24 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 07:34:38 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is rereview of this draft. In my previous review I listed some attacks, and all those attacks have been added to the security considerations section. I think the security considerations section is now good enough. I think this document is ready from the security point of view. -- kivinen@iki.fi From kivinen@iki.fi Thu Nov 7 16:15:15 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9435D21E81E1 for ; Thu, 7 Nov 2013 16:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9yTJE3a8UjO for ; Thu, 7 Nov 2013 16:15:14 -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 6E7F021E818D for ; Thu, 7 Nov 2013 16:15:08 -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 rA80F23D004235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 8 Nov 2013 02:15:02 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rA80F2EH014928; Fri, 8 Nov 2013 02:15:02 +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: <21116.11526.684017.890987@fireball.kivinen.iki.fi> Date: Fri, 8 Nov 2013 02:15:02 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 2 min X-Total-Time: 6 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:15:15 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Dorothy Gellert is next in the rotation. For telechat 2013-11-21 Reviewer LC end Draft Chris Lonvick TR2013-10-25 draft-ietf-mmusic-rfc2326bis-38 Radia Perlman TR2013-08-18 draft-ietf-karp-ops-model-09 Vincent Roca T 2013-09-24 draft-ietf-mmusic-duplication-grouping-03 Joe Salowey TR2013-09-23 draft-ietf-sidr-bgpsec-threats-07 Yaron Sheffer TR2013-08-16 draft-ietf-tls-oob-pubkey-10 David Waltermire T 2013-09-30 draft-ietf-opsec-ip-options-filtering-05 Tom Yu T 2013-10-01 draft-ietf-sidr-origin-ops-22 For telechat 2013-12-05 Shawn Emery T 2013-11-26 draft-ietf-cdni-requirements-12 For telechat 2013-12-19 Dave Cridland T 2013-11-04 draft-ietf-httpbis-p5-range-24 Matt Lepinski T 2013-11-04 draft-ietf-httpbis-p2-semantics-24 Catherine Meadows T 2013-11-04 draft-ietf-httpbis-authscheme-registrations-08 Klaas Wierenga TR2013-11-04 draft-ietf-httpbis-p4-conditional-24 Last calls and special requests: Derek Atkins 2013-11-27 draft-ietf-xrblock-rtcp-xr-qoe-12 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 Dave Cridland 2013-11-28 draft-leiba-smime-type-registry-01 Alan DeKok 2013-12-01 draft-moonesamy-ietf-conduct-3184bis-03 Donald Eastlake 2013-11-19 draft-ietf-soc-load-control-event-package-10 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05 Tero Kivinen 2013-10-24 draft-ietf-roll-trickle-mcast-05 Julien Laganier E 2013-11-21 draft-ietf-avtcore-rtp-security-options-08 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-08 Julien Laganier 2013-11-06 draft-ietf-forces-ceha-08 Alexey Melnikov E 2013-11-21 draft-ietf-payload-rtp-howto-09 Sandy Murphy 2013-10-31 draft-ietf-netext-pd-pmip-12 Magnus Nystrom 2013-11-06 draft-ietf-pim-explicit-tracking-08 Hilarie Orman 2013-11-18 draft-shore-icmp-aup-06 Radia Perlman 2013-11-27 draft-housley-ct-keypackage-receipt-n-error-05 Vincent Roca 2013-04-26 draft-ietf-6man-stable-privacy-addresses-14 Joe Salowey 2013-11-27 draft-ietf-clue-telepresence-requirements-06 Yaron Sheffer 2013-11-27 draft-ietf-idr-extcomm-iana-01 Ondrej Sury 2013-11-18 draft-ietf-l2vpn-etree-reqt-05 Tina TSOU 2013-11-27 draft-ietf-l2vpn-evpn-req-05 Carl Wallace 2013-11-27 draft-ietf-mmusic-sdp-g723-g729-04 Brian Weis 2013-11-26 draft-ietf-ospf-rfc6506bis-01 Klaas Wierenga 2013-11-27 draft-ietf-pwe3-dynamic-ms-pw-19 Tom Yu 2013-11-27 draft-ietf-sidr-rpki-rtr-impl-04 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 Glen Zorn 2013-11-27 draft-turner-ct-keypackage-receipt-n-error-algs-03 -- kivinen@iki.fi From magnusn@gmail.com Thu Nov 7 20:13:42 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE8F21E81A7; Thu, 7 Nov 2013 20:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1K53dFnEwU4p; Thu, 7 Nov 2013 20:13:42 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B271F21E80A3; Thu, 7 Nov 2013 20:13:41 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id q58so1431905wes.17 for ; Thu, 07 Nov 2013 20:13:38 -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=px+wSKN/7rN+Gs60M9rdqFpphi0ZWRcfGqbkQH5aimI=; b=RrxE+JOLYaBJEHwvvY+n8UfhO3Z8lPuE0jcHvp/scDC75SczvcPqYszTxISQO1LwjL +M/eX8JGrM0Xfu3ZpZCkE/kIzyOmjRekqZg/qJyt+fUDH1/XyuhPk/nSPBuTpRalSZXK q4R/0NvY7/8Xxo5R74eP//Fh8aXdWUHi98MAGQdzajCL7w3j21ZQm7jGi65+zY5HQZMO 8HrHB4B2m2ltnjxdrN9eTAZwU/YpYM9xaSvmdby8oHkZGe9TCaokFPF96S2T3BuAegaz PQZSnqrux9R0c7EflUOjn6kvRsRjw9mphMfnbWDtXgsqx9aKwGA5NLPQiV0TDvPYuX9y OM0Q== MIME-Version: 1.0 X-Received: by 10.180.160.212 with SMTP id xm20mr620751wib.23.1383884018218; Thu, 07 Nov 2013 20:13:38 -0800 (PST) Received: by 10.180.93.167 with HTTP; Thu, 7 Nov 2013 20:13:38 -0800 (PST) Date: Thu, 7 Nov 2013 20:13:38 -0800 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: "secdir@ietf.org" , draft-asaeda-mboned-explicit-tracking@tools.ietf.org Content-Type: multipart/alternative; boundary=047d7b624d3450ff6304eaa29b2b Cc: "iesg@ietf.org" Subject: [secdir] Security directorate reveiw of draft-asaeda-mboned-explicit-tracking X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 04:13:42 -0000 --047d7b624d3450ff6304eaa29b2b 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 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 --047d7b624d3450ff6304eaa29b2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security= directorate's=20 ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security=20 area directors. Document editors and WG chairs should treat these=20 comments just like any other last 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 written but the security considerat= ions sections makes vague references to "serious threats" that ma= y be introduced by malicious hosts on the network yet only states that &quo= t;abuse" can be mitigated by limiting the amount of information a rout= er can store (which seems like a given anyway?). It would be good if the do= cument enumerated the "serious threats" and their mitigations.

-- Magnus
--047d7b624d3450ff6304eaa29b2b-- From magnusn@gmail.com Thu Nov 7 20:16:12 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A3321E8185; Thu, 7 Nov 2013 20:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nobYyAgmSfkN; Thu, 7 Nov 2013 20:16:11 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A94BF21E81B6; Thu, 7 Nov 2013 20:16:05 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id m15so1413635wgh.13 for ; Thu, 07 Nov 2013 20:16:01 -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=jDZ03fC5k9T95J2YhzdUe19D/eFRiAkACVOP2el3UCY=; b=NtxlzXWSztNNBh7np05KkSVgLpjOxC3PYIIGp3PCDTkoJaB/E9+g4EMNUj38s3PRPz dMWBK/QL3LngfVB4fnx1uf8knj3i1Xv5FbBntvNU+cVS455M5+JrkTYlveOf+qQ/JAN1 e3rejcp0eIsKdYxdcaKQHe7dQFb7GHrI2+5n0vGtuAtV4JOZOwpTR6DtgTTgmGu4EYuZ eiVeqHzDoMHNgGokgIyCMxpmnpgZAig1j5s0to+f0mMty7VB7Upb8D7jdZMsZUG0guY5 h3klrHOkL7FoLBMUeeecAnraz9g/hACTjDzLElahxGVCa3y5Ek5kyTBkweqTs5vZiDOU Y83A== MIME-Version: 1.0 X-Received: by 10.180.187.41 with SMTP id fp9mr616263wic.33.1383884160941; Thu, 07 Nov 2013 20:16:00 -0800 (PST) Received: by 10.180.93.167 with HTTP; Thu, 7 Nov 2013 20:16:00 -0800 (PST) Date: Thu, 7 Nov 2013 20:16:00 -0800 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: "secdir@ietf.org" , draft-ietf-pim-explicit-tracking@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c3844cd2c5b504eaa2a377 Cc: "iesg@ietf.org" Subject: [secdir] Security directorate review of draft-ietf-pim-explicit-tracking [Was: Re: Security directorate reveiw of draft-asaeda-mboned-explicit-tracking X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 04:16:12 -0000 --001a11c3844cd2c5b504eaa2a377 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [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 wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security are= a > directors. Document editors and WG chairs should treat these comments 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 > --=20 -- Magnus --001a11c3844cd2c5b504eaa2a377 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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

On Thu, Nov 7, 2013 at 8:13 PM, Magnus Nystr= =F6m <magnusn@gmail.com> wrote:
I have reviewed this document as part of the security= directorate's=20 ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security=20 area directors. Document editors and WG chairs should treat these=20 comments just like any other last 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 written but the security considerat= ions sections makes vague references to "serious threats" that ma= y be introduced by malicious hosts on the network yet only states that &quo= t;abuse" can be mitigated by limiting the amount of information a rout= er can store (which seems like a given anyway?). It would be good if the do= cument enumerated the "serious threats" and their mitigations.

-- Magnus



--
-- Magnus
--001a11c3844cd2c5b504eaa2a377-- From radiaperlman@gmail.com Sat Nov 9 22:09:54 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715FF21F9F80; Sat, 9 Nov 2013 22:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHNdBdb-H8ev; Sat, 9 Nov 2013 22:09:53 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 151FA21F9F21; Sat, 9 Nov 2013 22:09:52 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id w6so2473621lbh.41 for ; Sat, 09 Nov 2013 22:09:52 -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=x3n6pK+MaG4YMU3Jpup0F7kMaOKZb6/c4CnV0ujXOy0=; b=jcs6wFQi8NuplZzIM5SeosCxAm4x5G4Z+jnRu9sHlscd5qpRDuc13WKgAp2F/BXJ4i NCeKfVS44wp5ljcSsDLghh+su2Id2lOckgu66re9N8+CMHA0vMJP1SkfvU4uK108rv4N XzqvCE934ZSWftMW+jyeFKpbFNQ3xxomSzoAFDgYCUy94xNAJDUBiA2mf20TgKsKwhzq xlz2Pw5aso8bfBE+o47YV+hb3OSoHa62MMPyRJfovrdMlB4G+eaomLW+iSQ7zB0EeAXU jV585hjSK5HS1jUtGy/hsIvc6sMjGs6kC7S/4/Y4iBg6EeFC8ijq2cMx4AKlTchyi9SI NLyw== MIME-Version: 1.0 X-Received: by 10.112.204.74 with SMTP id kw10mr16969459lbc.13.1384063792035; Sat, 09 Nov 2013 22:09:52 -0800 (PST) Received: by 10.112.188.197 with HTTP; Sat, 9 Nov 2013 22:09:51 -0800 (PST) Date: Sat, 9 Nov 2013 22:09:51 -0800 Message-ID: From: Radia Perlman To: "secdir@ietf.org" , The IESG , draft-housley-ct-keypackage-receipt-n-error.all@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c3bb34abbc9b04eacc76ae Subject: [secdir] Secdir review of draft-housley-ct-keypackage-receipt-n-error-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 06:09:54 -0000 --001a11c3bb34abbc9b04eacc76ae Content-Type: text/plain; charset=windows-1252 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 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): 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 als= o defining this attribute or whether this information was included in this document for the purpose of providing context. The document defines a long list of error codes with the comment =93Expect additional error codes=94 without specifying a mechanism for additional err= or 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? 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. 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. 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 =93w= hich receivers of the key package are requested to return receipts=94. Radia --001a11c3bb34abbc9b04eacc76ae Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the security direct= orate's ongoing effort to review all IETF documents being processed by = the IESG.=A0 These comments were written primarily for the benefit of the s= ecurity area directors.=A0 Document editors and WG chairs should treat thes= e comments just like any other last call comments.

=A0

This document defines a synt= ax for two Cryptographic Message Syntax (CMS) content types that can be use= d in responses to messages containing key packages. One is for acknowledgin= g receipt and the other is for reporting errors. The exact syntax is unimpo= rtant to security and the message purpose seems sensible and non-controvers= ial.

=A0

=A0

=A0

=A0

=A0

=A0


Radia

--001a11c3bb34abbc9b04eacc76ae-- From adrian@olddog.co.uk Mon Nov 11 11:41:43 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68BF21E8088 for ; Mon, 11 Nov 2013 11:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZu-IOgDzUnc for ; Mon, 11 Nov 2013 11:41:03 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id A3AD311E8108 for ; Mon, 11 Nov 2013 11:41:00 -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 rABJewSR012555; Mon, 11 Nov 2013 19:40:58 GMT Received: from 950129200 (westford-nat.juniper.net [66.129.232.2]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rABJeuXm012528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Nov 2013 19:40:57 GMT From: "Adrian Farrel" To: Date: Mon, 11 Nov 2013 19:40:55 -0000 Message-ID: <008e01cedf15$f12e3e50$d38abaf0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008F_01CEDF15.F1314B90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7fFUJeSOXqHmCyRlmY+gCsJy8WpQ== Content-Language: en-gb Cc: 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.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 19:41:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008F_01CEDF15.F1314B90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Authors, =20 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/appropriate. =20 Thanks, Adrian =20 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 =20 =20 [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.] =20 On Thu, Nov 7, 2013 at 8:13 PM, Magnus Nystr=F6m = wrote: I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. These = comments were written primarily for the benefit of the security area directors. = Document editors and WG chairs should treat these comments just like any other = last call comments. This document describes 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=20 --=20 -- Magnus=20 ------=_NextPart_000_008F_01CEDF15.F1314B90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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/appropriate.

 

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 <magnusn@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. 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 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 =

------=_NextPart_000_008F_01CEDF15.F1314B90-- From asaeda@nict.go.jp Tue Nov 12 06:34:30 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F032E21F969F for ; Tue, 12 Nov 2013 06:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idKS3AFlkBqg for ; Tue, 12 Nov 2013 06:34:24 -0800 (PST) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 068EC11E815C for ; Tue, 12 Nov 2013 06:34:21 -0800 (PST) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id rACEYIkX002018; Tue, 12 Nov 2013 23:34:18 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id rACEYHHg022865; Tue, 12 Nov 2013 23:34:18 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id E072F2CB31; Tue, 12 Nov 2013 23:34:17 +0900 (JST) Received: from localhost (ssh.nict.go.jp [133.243.3.49]) by mail2.nict.go.jp (NICT Mail) with ESMTP id BC91C2CAF4; Tue, 12 Nov 2013 23:34:17 +0900 (JST) Date: Tue, 12 Nov 2013 23:34:16 +0900 (JST) Message-Id: <20131112.233416.141125049.asaeda@nict.go.jp> To: adrian@olddog.co.uk From: Hitoshi Asaeda In-Reply-To: <008e01cedf15$f12e3e50$d38abaf0$@olddog.co.uk> References: <008e01cedf15$f12e3e50$d38abaf0$@olddog.co.uk> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.97.8 at zenith2 X-Virus-Status: Clean X-Mailman-Approved-At: Tue, 12 Nov 2013 08:31:33 -0800 Cc: draft-ietf-pim-explicit-tracking@tools.ietf.org, secdir@ietf.org, pim-chairs@tools.ietf.org Subject: Re: [secdir] Security directorate review of draft-ietf-pim-explicit-tracking X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 14:34:31 -0000 Dear Adrian and Magnus, > 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. Thank you very much for your review. I will address Magnus's concerns in a new revision. Regards, -- Hitoshi Asaeda > 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-track= ing [Was: > Re: Security directorate reveiw of draft-asaeda-mboned-explicit-track= ing > = > = > [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 = wrote: > I have reviewed this document as part of the security directorate's o= ngoing > effort to review all IETF documents being processed by the IESG. Thes= e 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 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 secti= ons makes > vague references to "serious threats" that may be introduced by malic= ious hosts > on the network yet only states that "abuse" can be mitigated by limit= ing the > amount of information a router can store (which seems like a given an= yway?). It > would be good if the document enumerated the "serious threats" and th= eir > mitigations. > = > -- Magnus = > = > = > = > -- = > -- Magnus = From radiaperlman@gmail.com Tue Nov 12 22:35:39 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D47521F8FF5; Tue, 12 Nov 2013 22:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBATKwbgTOCq; Tue, 12 Nov 2013 22:35:38 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id B6EFD11E8177; Tue, 12 Nov 2013 22:35:35 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id er20so2768050lab.22 for ; Tue, 12 Nov 2013 22:35:34 -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=/7uEX6SyeUBbTCDGx7z+cigrEJn113azdvEcea00BNA=; b=fTPKz2AR8tAHomLRiHn2vJ9+9rCLwVN3vyh0/sF4fBscdi5/nsHLU5eSDWeObMhj8n D6LHi1dS2D1ILwnpdPV0v6TwzwuNWI30TFTPQ2OX3EfFrGeuPoH7OcZgHY7SqwkdKX/U 2nIYPBilmRSpSsMUI2aWLdBeq7lKyD3vIy7iBuVK4/NWXEfTz59afGpmqmeZ2N8W345H hpVdTRGSeKh4ZLGlc9H8BzbZ7GzNVG9LTZw2ZmPcyThDkZQpOKz1kDNpiib1FNJvtnks FRJyZo+HoqgxgMWbs5s6H2/rh75JFQzqDkUtL3IX2NjCkIi476WWSklT7x2QnbDFot2l F8EA== MIME-Version: 1.0 X-Received: by 10.112.210.136 with SMTP id mu8mr12884515lbc.25.1384324534677; Tue, 12 Nov 2013 22:35:34 -0800 (PST) Received: by 10.112.188.197 with HTTP; Tue, 12 Nov 2013 22:35:34 -0800 (PST) Date: Tue, 12 Nov 2013 22:35:34 -0800 Message-ID: From: Radia Perlman To: The IESG , "secdir@ietf.org" , draft-ietf-karp-ops-model.all@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c3c70424b84904eb092c5b Subject: [secdir] Secdir review of draft-ietf-karp-ops-mode-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 06:35:39 -0000 --001a11c3c70424b84904eb092c5b Content-Type: text/plain; charset=ISO-8859-1 I previously reviewed version -07. This version (-09) is slightly updated. I'd requested an introduction about what is different for "routing protocol security" rather than, say, an endnode authenticating to an access point. The authors did add a sentence or so: " routers need to function in order to establish network connectivity. As a result, centralized services cannot typically be used for authentication or other security tasks; see Section 4.4. In addition, routers' roles affect how new routers are installed and how problems are handleded;" There's a couple of typos in the added sentences. "routers" should be capitalized. "Handleded" is a typo. I don't have any objections to the document. Radia On Tue, Aug 13, 2013 at 10:02 PM, 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. > > This is a useful document as an informational RFC. The technical content > is interesting and useful. > > I think the document would be much improved with an introduction about > what is different for "routing protocol security" rather than, say, an > endnode authenticating to an access point, or nodes forming a peer > relationship in an overlay network. So, for instance, "normal security > issues" (i.e., outside the scope of KARP) might assume the network is up, > so that it's possible to get CRLs, or be available to be managed, whereas > perhaps KARP is targetting cases which depend on less infrastructure. It > would be nice if this document were to have an introduction that talks > about things like that. > > As for typos...3rd line up from bottom of page 14 has a glitch involving a > bunch of spaces and an extra comma after the word "peers". And I can't > parse the last sentence of the 1st paragraph of section 7. "...complexity > of and update and risk...." > > Speaking of PKI...the document talks about certificates expiring, but not > being revoked (CRL, OCSP). > > Radia > --001a11c3c70424b84904eb092c5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I previously reviewed version -07. =A0This version (-09) i= s slightly updated. =A0I'd requested an introduction about what is diff= erent for "routing protocol security" rather than, say, an endnod= e authenticating to an access point. =A0The authors did add a sentence or s= o:

" routers need to function in order to
   establish network connectivity.  As a result, centralized services
   cannot typically be used for authentication or other security tasks;
   see Section 4.4.  In addition, routers' roles affect how new routers
   are installed and how problems are handleded;"

There's a couple of typos in the added sentences.  "routers" =
should be capitalized.  "Handleded" is a typo.

I don't have any objections to the doc=
ument.

Radia





On Tue, Aug 13, 2013 at 10:02 PM, Radia Perlman <ra=
diaperlman@gmail.com> wrote:


I have reviewed this document as part of the security dire=
ctorate's ongoing effort to review all IETF documents being processed b=
y the IESG. =A0These comments were written primarily for the benefit of the=
 security area directors. =A0Document editors and WG chairs should treat th=
ese comments just like any other last call comments.



This is a useful document as an informational RFC. The techn=
ical content is interesting and useful.

I think th=
e document would be much improved with an introduction about what is differ=
ent for "routing protocol security" rather than, say, an endnode =
authenticating to an access point, or nodes forming a peer relationship in =
an overlay network. =A0So, for instance, "normal security issues"=
 (i.e., outside the scope of KARP) might assume the network is up, so that =
it's possible to get CRLs, or be available to be managed, whereas perha=
ps KARP is targetting cases which depend on less infrastructure. =A0It woul=
d be nice if this document were to have an introduction that talks about th=
ings like that.




As for typos...3rd line up from bottom of page 14 has a=
 glitch involving a bunch of spaces and an extra comma after the word "=
;peers". =A0And I can't parse the last sentence of the 1st paragra=
ph of section 7. "...complexity of and update and risk...."




Speaking of PKI...the document talks about certificates=
 expiring, but not being revoked (CRL, OCSP).

Radia

--001a11c3c70424b84904eb092c5b-- From hilarie@purplestreak.com Tue Nov 12 23:44:16 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EC511E8113; Tue, 12 Nov 2013 23:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC2pu0ITVveE; Tue, 12 Nov 2013 23:44:10 -0800 (PST) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF1D11E810E; Tue, 12 Nov 2013 23:44:10 -0800 (PST) Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1VgV7R-00010b-5s; Wed, 13 Nov 2013 00:44:09 -0700 Received: from [72.250.219.84] (helo=sylvester.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1VgV7O-0001bG-Gr; Wed, 13 Nov 2013 00:44:09 -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 rAD7hr1r002179; Wed, 13 Nov 2013 00:43:53 -0700 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id rAD7hqQg002177; Wed, 13 Nov 2013 00:43:52 -0700 Date: Wed, 13 Nov 2013 00:43:52 -0700 Message-Id: <201311130743.rAD7hqQg002177@sylvester.rhmr.com> From: "Hilarie Orman" To: draft-shore-icmp-aup@tools.ietf.org X-XM-AID: U2FsdGVkX1+D0nx641CQI/B+errFi7sl X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;draft-shore-icmp-aup@tools.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 in01.mta.xmission.com) Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] Security review of draft-shore-icmp-aup-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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: Wed, 13 Nov 2013 07:44:16 -0000 Security review of draft-shore-icmp-aup-06 An Acceptable Use Policy for New ICMP Types and Codes Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document discusses the current uses of ICMP and how it may or may not fit into management or control planes, depending on your view of what those are. The recommendation is to limit uses to reporting downstream forwarding anomalies, discovering on-link routers and hosts and network parameters. "ICMP should not be used as a routing or network management protocol." While there are ostensibly no new security considerations, it is worthwhile noting that ICMP plays a part in the Photuris protocol and was also used in SKIP (though that usage is deprecated). In general, I have some concern about using ICMP to discover network security parameters or to report on network security anomalies in the forwarding plane. I would recommend adding something to the security considerations about avoiding such usage or using special caution if defining new protocols. Hilarie From melinda.shore@nomountain.net Wed Nov 13 00:19:29 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F3F21E80B1; Wed, 13 Nov 2013 00:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsmBROZPqTtB; Wed, 13 Nov 2013 00:19:24 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB7A11E8116; Wed, 13 Nov 2013 00:18:34 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 68D651DE060; Wed, 13 Nov 2013 00:18:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=nomountain.net; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=nomountain.net ; b=wnw5/bvt6XKx003AKD5DPjQzLzSXRUieEbrnbC57BHaEEeUeUcELCyL51JUi LMul2t3GS9UyYwWZQTzd6JrIGdIgTKuEGovZ+AC+zhpHsSqzjNVgm3+wOq7BAlua 6tJ5ghVlNdimwTXcyJruWskNtZDWa+ql/bEOrWVRd7crDd8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nomountain.net; h= message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s= nomountain.net; bh=LSPJmlyX7HQzIJ83wxCRnnk0SL8=; b=MBhRBK07LlZ4d 2ULYxvn/evJfoBTQVg3Tbe6EMAFkp4MKxSRbVzdphSCJUBWXNXTAt9/E0p9RSsgv ML9RoXZ0tU/gZOW9U87Elv4dCxXKicFARQak/D9j11VaC6H3yrJP5d7uV5YhjvjO UvJFb2W217uCi1E8SltdItI6kejZOY= Received: from spandex.local (216-67-62-34-rb3.nwc.dsl.dynamic.acsalaska.net [216.67.62.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id B75651DE05D; Wed, 13 Nov 2013 00:18:32 -0800 (PST) Message-ID: <528335D6.2010109@nomountain.net> Date: Tue, 12 Nov 2013 23:18:30 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hilarie Orman References: <201311130743.rAD7hqQg002177@sylvester.rhmr.com> In-Reply-To: <201311130743.rAD7hqQg002177@sylvester.rhmr.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 13 Nov 2013 08:08:06 -0800 Cc: iesg@ietf.org, draft-shore-icmp-aup@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Security review of draft-shore-icmp-aup-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 08:19:30 -0000 On 11/12/13 10:43 PM, Hilarie Orman wrote: > While there are ostensibly no new security considerations, it is > worthwhile noting that ICMP plays a part in the Photuris protocol and > was also used in SKIP (though that usage is deprecated). In general, > I have some concern about using ICMP to discover network security > parameters or to report on network security anomalies in the > forwarding plane. I hadn't been aware of its use in Photuris. We'll get some text in there mentioning that, as well as some discussion of the problems you've mentioned with regard to reporting of security parameters/anomalies. And now that you mention it that's actually a more general security problem. Melinda -- Melinda Shore No Mountain Software melinda.shore@nomountain.net "Software longa, hardware brevis." From stephen.farrell@cs.tcd.ie Wed Nov 13 14:05:34 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8512821E811A; Wed, 13 Nov 2013 14:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.926 X-Spam-Level: X-Spam-Status: No, score=-102.926 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_00=-2.599, SARE_SUB_11CONS_WORD=0.352, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Awvabs-ic2w7; Wed, 13 Nov 2013 14:05:28 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A2B3B21E8104; Wed, 13 Nov 2013 14:05:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F171BBE80; Wed, 13 Nov 2013 22:05:26 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie 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 nFovoWoxQeEh; Wed, 13 Nov 2013 22:05:25 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.41.61.15]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 14096BE7D; Wed, 13 Nov 2013 22:05:25 +0000 (GMT) Message-ID: <5283F7A2.5040106@cs.tcd.ie> Date: Wed, 13 Nov 2013 22:05:22 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "\"saag@ietf.org\" per" , perpass , "cfrg@irtf.org" , "secdir@ietf.org" References: <20131113215822.13869.69647.idtracker@ietfa.amsl.com> In-Reply-To: <20131113215822.13869.69647.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <20131113215822.13869.69647.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: [secdir] Fwd: New Non-WG Mailing List: dsfjdssdfsd X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 22:05:34 -0000 Hi, There was some discussion in Vancouver at the secdir lunch and the perpass BoF about better randomness recommendations and we agreed to set up a new list. Details for that are below. Many thanks to Dan Harkins and Paul Hoffman for agreeing to moderate this. I think Don Eastlake is also working on an update to RFC 4086 so this could be a useful place to talk about that. I'm hoping that one of them will kick off the discussion in a few days, once folks have had a chance to sign up. Regards, Stephen. -------- Original Message -------- Subject: New Non-WG Mailing List: dsfjdssdfsd Date: Wed, 13 Nov 2013 13:58:22 -0800 From: IETF Secretariat Reply-To: ietf@ietf.org To: IETF Announcement List CC: dsfjdssdfsd@ietf.org, dharkins@lounge.org, paul.hoffman@vpnc.org A new IETF non-working group email list has been created. List address: dsfjdssdfsd@ietf.org Archive: http://www.ietf.org/mail-archive/web/dsfjdssdfsd/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/dsfjdssdfsd Purpose: The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086. For additional information, please contact the list administrators. From cpignata@cisco.com Wed Nov 13 16:42:22 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A73611E8122; Wed, 13 Nov 2013 16:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.47 X-Spam-Level: X-Spam-Status: No, score=-110.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipVCYU16ahSg; Wed, 13 Nov 2013 16:42:17 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C69BB11E8102; Wed, 13 Nov 2013 16:42:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6692; q=dns/txt; s=iport; t=1384389736; x=1385599336; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dlGDg6tGupJPpFHKtxE7gnGuFG4Wh/hfzSzkcrylScI=; b=MVf2xaRbvc5TWaudjg+m6AqkU6DBuFg1+Llh+hfnLN06cuRdOnmMJWPm VRx79/gljT6zmqY/UGvoUWFqmnAGoTgHbnfr/TmdDixhPjERE/Ofef1PE xMPJ70hGCEp3YbZXFpOvY0W/YSafyJ2sznD6DvvM7btKUQ8kXirBszp8q M=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAAAbhFKtJXG8/2dsb2JhbABZgweBC78qgSUWdIIlAQEBAwF5BQsCAQgYLjIlAgQBDQUOh20GwBGPXweDIIERA5AwgTCGMJILgyiCKg X-IronPort-AV: E=Sophos;i="4.93,696,1378857600"; d="asc'?scan'208,217";a="284538141" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 14 Nov 2013 00:42:16 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAE0gGYu003010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 00:42:16 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.229]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 18:42:15 -0600 From: "Carlos Pignataro (cpignata)" To: Melinda Shore , Hilarie Orman Thread-Topic: Security review of draft-shore-icmp-aup-06 Thread-Index: AQHO4EQ5HTlaGMkN0EGJGvvyQ8I+zpojNesAgAES24A= Date: Thu, 14 Nov 2013 00:42:15 +0000 Message-ID: <3A1F8736-5E28-4841-BA01-61A602087FB3@cisco.com> References: <201311130743.rAD7hqQg002177@sylvester.rhmr.com> <528335D6.2010109@nomountain.net> In-Reply-To: <528335D6.2010109@nomountain.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.59] Content-Type: multipart/signed; boundary="Apple-Mail=_FACB674C-5227-4B75-8989-FCA75D8FB211"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: The IESG , "" , "secdir@ietf.org" Subject: Re: [secdir] Security review of draft-shore-icmp-aup-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 00:42:22 -0000 --Apple-Mail=_FACB674C-5227-4B75-8989-FCA75D8FB211 Content-Type: multipart/alternative; boundary="Apple-Mail=_09D486CD-A46D-42B4-A40A-E70B06C52636" --Apple-Mail=_09D486CD-A46D-42B4-A40A-E70B06C52636 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Thanks, Hilarie, How's this updated Security Considerations? 5. Security considerations This document attempts to describe a high-level policy for adding ICMP types and codes. While special attention must be paid to the security implications of any particular new ICMP type or code, this recommendation presents no new security considerations. =46rom a security perspective, ICMP plays a part in the Photuris protocol. But more generally, ICMP is not a secure protocol, and does not include features to be used to discover network security parameters or to report on network security anomalies in the forwarding plane. Thanks, -- Carlos. On Nov 13, 2013, at 3:18 AM, Melinda Shore = wrote: > On 11/12/13 10:43 PM, Hilarie Orman wrote: >> While there are ostensibly no new security considerations, it is >> worthwhile noting that ICMP plays a part in the Photuris protocol and >> was also used in SKIP (though that usage is deprecated). In general, >> I have some concern about using ICMP to discover network security >> parameters or to report on network security anomalies in the >> forwarding plane. >=20 > I hadn't been aware of its use in Photuris. We'll get some > text in there mentioning that, as well as some discussion of > the problems you've mentioned with regard to reporting of > security parameters/anomalies. And now that you mention it > that's actually a more general security problem. >=20 > Melinda >=20 >=20 > --=20 > Melinda Shore > No Mountain Software > melinda.shore@nomountain.net >=20 > "Software longa, hardware brevis." --Apple-Mail=_09D486CD-A46D-42B4-A40A-E70B06C52636 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Thanks, Hilarie,

How's this = updated Security Considerations?

5.  Security = considerations

   This document attempts to describe a high-level policy = for adding
   = ICMP types and codes.  While special attention must be paid to = the
   security = implications of any particular new ICMP type or code, this
   recommendation = presents no new security considerations.

   =46rom a security perspective, ICMP plays a = part in the Photuris
   protocol.  But more generally, ICMP is not a = secure protocol, and
   does not include features to be used to discover = network security
   parameters or to report on network security anomalies = in the
   = forwarding = plane.


Thanks,
-- Carlos.

On Nov 13, 2013, at 3:18 = AM, Melinda Shore <melinda.shore@nomountain.net<= /a>> wrote:

On 11/12/13 10:43 PM, Hilarie Orman wrote:
While there are ostensibly no new security considerations, = it is
worthwhile noting that ICMP plays a part in the Photuris = protocol and
was also used in SKIP (though that usage is deprecated). =  In general,
I have some concern about using ICMP to discover = network security
parameters or to report on network security = anomalies in the
forwarding plane.

I hadn't been = aware of its use in Photuris.  We'll get some
text in there = mentioning that, as well as some discussion of
the problems you've = mentioned with regard to reporting of
security parameters/anomalies. =  And now that you mention it
that's actually a more general = security problem.

Melinda


--
Melinda Shore
No = Mountain Software
melinda.shore@nomountain.net<= /a>

"Software longa, hardware = brevis."

= --Apple-Mail=_09D486CD-A46D-42B4-A40A-E70B06C52636-- --Apple-Mail=_FACB674C-5227-4B75-8989-FCA75D8FB211 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKEHGcACgkQtfDPGTp3USweWgCcC7cvo/+js0gZCH+YuDi5bjYV gdwAnjo0bc7ZfLwrmTvMQ1T5eklsdqFo =uebK -----END PGP SIGNATURE----- --Apple-Mail=_FACB674C-5227-4B75-8989-FCA75D8FB211-- From hilarie@purplestreak.com Wed Nov 13 16:43:55 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E571821F9C1D; Wed, 13 Nov 2013 16:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmiYQBrFI9UN; Wed, 13 Nov 2013 16:43:49 -0800 (PST) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by ietfa.amsl.com (Postfix) with ESMTP id 52C9E21F9C55; Wed, 13 Nov 2013 16:43:49 -0800 (PST) Received: from mx02.mta.xmission.com ([166.70.13.212]) by out02.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1Vgl2B-0004qk-M2; Wed, 13 Nov 2013 17:43:47 -0700 Received: from mta1.zcs.xmission.com ([166.70.13.65]) by mx02.mta.xmission.com with esmtp (Exim 4.76) (envelope-from ) id 1Vgl29-0002Ub-Cf; Wed, 13 Nov 2013 17:43:47 -0700 Received: from localhost (localhost [127.0.0.1]) by mta1.zcs.xmission.com (Postfix) with ESMTP id 545991680BB; Wed, 13 Nov 2013 17:43:45 -0700 (MST) Received: from mta1.zcs.xmission.com ([127.0.0.1]) by localhost (mta1.zcs.xmission.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id OwqlJXhL3R0U; Wed, 13 Nov 2013 17:43:45 -0700 (MST) Received: from localhost (localhost [127.0.0.1]) by mta1.zcs.xmission.com (Postfix) with ESMTP id 36D8C1680C0; Wed, 13 Nov 2013 17:43:45 -0700 (MST) Received: from mta1.zcs.xmission.com ([127.0.0.1]) by localhost (mta1.zcs.xmission.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7jQ8fOqEE1M4; Wed, 13 Nov 2013 17:43:45 -0700 (MST) Received: from zms04.zcs.xmission.com (zms04.zcs.xmission.com [166.70.13.74]) by mta1.zcs.xmission.com (Postfix) with ESMTP id 1C9581680BB; Wed, 13 Nov 2013 17:43:45 -0700 (MST) Date: Wed, 13 Nov 2013 17:43:43 -0700 (MST) From: Hilarie Orman To: "Carlos Pignataro (cpignata)" Message-ID: <1679028552.3762717.1384389823659.JavaMail.zimbra@purplestreak.com> In-Reply-To: <3A1F8736-5E28-4841-BA01-61A602087FB3@cisco.com> References: <201311130743.rAD7hqQg002177@sylvester.rhmr.com> <528335D6.2010109@nomountain.net> <3A1F8736-5E28-4841-BA01-61A602087FB3@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [166.70.13.74] X-Mailer: Zimbra 8.0.4_GA_5739 (zclient/8.0.4_GA_5739) Thread-Topic: Security review of draft-shore-icmp-aup-06 Thread-Index: AQHO4EQ5HTlaGMkN0EGJGvvyQ8I+zpojNesAgAES24DMB09GHg== X-SA-Exim-Connect-IP: 166.70.13.65 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;"Carlos Pignataro (cpignata)" 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 mx02.mta.xmission.com) Cc: Melinda Shore , The IESG , "" , secdir@ietf.org Subject: Re: [secdir] Security review of draft-shore-icmp-aup-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 00:43:56 -0000 That'll do. Hilarie ----- Original Message ----- From: Carlos Pignataro (cpignata) To: Melinda Shore , Hilarie Orman Cc: , The IESG , secdir@ietf.org Sent: Wed, 13 Nov 2013 17:42:15 -0700 (MST) Subject: Re: Security review of draft-shore-icmp-aup-06 Thanks, Hilarie, How's this updated Security Considerations? 5. Security considerations This document attempts to describe a high-level policy for adding ICMP types and codes. While special attention must be paid to the security implications of any particular new ICMP type or code, this recommendation presents no new security considerations. From a security perspective, ICMP plays a part in the Photuris protocol. But more generally, ICMP is not a secure protocol, and does not include features to be used to discover network security parameters or to report on network security anomalies in the forwarding plane. Thanks, -- Carlos. On Nov 13, 2013, at 3:18 AM, Melinda Shore wrote: > On 11/12/13 10:43 PM, Hilarie Orman wrote: >> While there are ostensibly no new security considerations, it is >> worthwhile noting that ICMP plays a part in the Photuris protocol and >> was also used in SKIP (though that usage is deprecated). In general, >> I have some concern about using ICMP to discover network security >> parameters or to report on network security anomalies in the >> forwarding plane. > > I hadn't been aware of its use in Photuris. We'll get some > text in there mentioning that, as well as some discussion of > the problems you've mentioned with regard to reporting of > security parameters/anomalies. And now that you mention it > that's actually a more general security problem. > > Melinda > > > -- > Melinda Shore > No Mountain Software > melinda.shore@nomountain.net > > "Software longa, hardware brevis." From kivinen@iki.fi Thu Nov 14 08:03:31 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA34C11E8176 for ; Thu, 14 Nov 2013 08:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8om2XlphtHB for ; Thu, 14 Nov 2013 08:03:31 -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 B3AC911E814F for ; Thu, 14 Nov 2013 08:03:30 -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 rAEG3RJu011678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 14 Nov 2013 18:03:27 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rAEG3RUM023144; Thu, 14 Nov 2013 18:03:27 +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: <21124.62543.349074.93676@fireball.kivinen.iki.fi> Date: Thu, 14 Nov 2013 18:03:27 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 16:03:31 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview David Harrington is next in the rotation. For telechat 2013-11-21 Reviewer LC end Draft Chris Lonvick TR2013-10-25 draft-ietf-mmusic-rfc2326bis-38 Sandy Murphy T 2013-10-31 draft-ietf-netext-pd-pmip-12 Vincent Roca T 2013-09-24 draft-ietf-mmusic-duplication-grouping-03 Joe Salowey TR2013-09-23 draft-ietf-sidr-bgpsec-threats-07 Yaron Sheffer TR2013-08-16 draft-ietf-tls-oob-pubkey-10 David Waltermire T 2013-09-30 draft-ietf-opsec-ip-options-filtering-05 Tom Yu T 2013-10-01 draft-ietf-sidr-origin-ops-22 For telechat 2013-12-05 Shawn Emery T 2013-11-26 draft-ietf-cdni-requirements-12 Tobias Gondrom T 2013-11-25 draft-ietf-json-rfc4627bis-07 For telechat 2013-12-19 Dave Cridland T 2013-11-04 draft-ietf-httpbis-p5-range-24 Dorothy Gellert T 2013-12-06 draft-bundesbank-eurosystem-namespace-02 Matt Lepinski T 2013-11-04 draft-ietf-httpbis-p2-semantics-24 Catherine Meadows T 2013-11-04 draft-ietf-httpbis-authscheme-registrations-08 Klaas Wierenga TR2013-11-04 draft-ietf-httpbis-p4-conditional-24 Last calls and special requests: Derek Atkins 2013-11-27 draft-ietf-xrblock-rtcp-xr-qoe-12 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 Dave Cridland 2013-11-28 draft-leiba-smime-type-registry-02 Alan DeKok 2013-12-01 draft-moonesamy-ietf-conduct-3184bis-03 Donald Eastlake 2013-11-19 draft-ietf-soc-load-control-event-package-10 Phillip Hallam-Baker E 2013-11-28 draft-ietf-pcp-description-option-02 Steve Hanna E 2013-11-28 draft-ietf-pcp-nat64-prefix64-04 Dan Harkins 2013-11-26 draft-ietf-trill-oam-framework-03 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05 Tero Kivinen 2013-10-24 draft-ietf-roll-trickle-mcast-05 Julien Laganier E 2013-11-21 draft-ietf-avtcore-rtp-security-options-09 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-08 Julien Laganier 2013-11-06 draft-ietf-forces-ceha-08 Alexey Melnikov E 2013-11-21 draft-ietf-payload-rtp-howto-09 Vincent Roca 2013-04-26 draft-ietf-6man-stable-privacy-addresses-14 Joe Salowey 2013-11-27 draft-ietf-clue-telepresence-requirements-06 Yaron Sheffer 2013-11-27 draft-ietf-idr-extcomm-iana-01 Ondrej Sury 2013-11-18 draft-ietf-l2vpn-etree-reqt-05 Tina TSOU 2013-11-27 draft-ietf-l2vpn-evpn-req-05 Carl Wallace 2013-11-27 draft-ietf-mmusic-sdp-g723-g729-04 Brian Weis 2013-11-26 draft-ietf-ospf-rfc6506bis-02 Klaas Wierenga 2013-11-27 draft-ietf-pwe3-dynamic-ms-pw-19 Tom Yu 2013-11-27 draft-ietf-sidr-rpki-rtr-impl-04 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 Glen Zorn 2013-11-27 draft-turner-ct-keypackage-receipt-n-error-algs-03 -- kivinen@iki.fi From aland@deployingradius.com Thu Nov 14 08:36:00 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B69621E80D0; Thu, 14 Nov 2013 08:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noWbgWltVuii; Thu, 14 Nov 2013 08:35:47 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42F8421E80E3; Thu, 14 Nov 2013 08:35:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id F17E1224013E; Thu, 14 Nov 2013 17:34:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTUomB6wosZA; Thu, 14 Nov 2013 17:34:40 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1176121806.dsl.bell.ca [70.26.49.206]) by power.freeradius.org (Postfix) with ESMTPSA id 14FD72240087; Thu, 14 Nov 2013 17:34:39 +0100 (CET) Message-ID: <5284FBA2.3000404@deployingradius.com> Date: Thu, 14 Nov 2013 11:34:42 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "secdir@ietf.org" , sm+ietf@elandsys.com, draft-moonesamy-ietf-conduct-3184bis.all@tools.ietf.org, IESG IESG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] Secdir review of draft-moonesamy-ietf-conduct-3184bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 16:36:02 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document provides a set of guidelines for personal interaction at the IETF. This review therefore ignores any computer protocol issues or attacks, and focuses on personal and procedural attacks. ... 2. Principles of Conduct 1. IETF participants extend respect and courtesy to their colleagues at all times. This is a lofty goal, especially considering the next sentence: IETF participants come from diverse origins and backgrounds and are equipped with multiple capabilities and ideals. I would suggest adding "expectations and assumptions" to that sentence. Very often, misunderstandings come from differing expectations. Two participants might believe they share a language. However, underlying assumptions mean that the words have different meanings. The expectations means that the approach people take is different. On a simplistic level, everyone believes that they are a reasonable person. Everyone believes that other people have the same mental models they do. Everyone believes that other people do (and will) behave the way that they do. These assumptions are often wrong. Discord in groups often comes from the misunderstanding what other people mean, and attributing maliciousness to what is actually differing assumptions and expectations. 2. IETF participants discuss ideas impersonally without finding fault with the person proposing the idea. It may be useful to re-phrase this as a positive statement. i.e.: IETF participants discuss impersonal ideas, using evidence, fact, and logic. Discussions of persons, personalities, or motivations are outside of the scope of the IETF. Items (3) and (4) seem reasonable to me. Other items which may be considered are the following. They are less inter-personal behavior, than behavior of an individual interacting with the larger IETF. - progress. Participants are expected to contribute to the progress of the working group. Simple participation isn't enough. We have to get things *done*. - consensus. Participants are expected to accept the consensus of the WG or the larger IETF. Standards creation necessarily involves compromise. Compromise doesn't mean you've been personally put down. It just means life is imperfect. IMHO, the Security Considerations section is not correct. Guidelines about IETF conduct do not affect the security of the Internet in any way. A social denial of service attack can affect the security of the Internet. The way to shut down progress on security solutions is simple and cheap. Attack the relevant players in court with spurious accusations of harassment. Sideline the group with discussion of politics. Have people "pick sides", and generally devolve the group into endless bickering. The IETF has been subject to minor attacks by people who engage in attacks, appeals, and who are repeatedly banned from WG participation. If one person made it their life goal to destroy the IETF with false allegations, they could have a significant impact on progress. From hallam@gmail.com Thu Nov 14 16:56:56 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1112A21E808A for ; Thu, 14 Nov 2013 16:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VqsH7l4A7d0 for ; Thu, 14 Nov 2013 16:56:52 -0800 (PST) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id E6B4621E809F for ; Thu, 14 Nov 2013 16:56:50 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id ec20so2237433lab.38 for ; Thu, 14 Nov 2013 16:56:49 -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=8PAxeDnyquxtb/nbODCgRAEKL+9FplkuVakvVRHgElU=; b=m69LXxsueTsFFFVqxpUCVL7YXdr9rG8ZNVtH5s9iLu7jzoFHgImkSDwPNZjUVfWvrg uSigXa+bY4upkWsEt/qAZCk10LSceffnxnGS7HJuxnpYo1IhI7Q3LI/CC8u9aQGvWuYa 6AgTXvX3YN1jqI6SaaqPGWGBOyXpZGgvNF8utw9eCR8KhEE3NdHgU8ktBddmBqWHOLCn lAghy9dMX8kkwaRU10fnSKiKqmmVzyDRPPLItAVSC+DKr3gznSrfBDyAmYzrWo51oP+O cGTah9s4MKNtWuPwjiCvKr4vFA3f6C7IkK5NVhMEPWxhKGvqtoJ/TvsHvsHAEeYg76WA jr0w== MIME-Version: 1.0 X-Received: by 10.112.168.170 with SMTP id zx10mr2251682lbb.0.1384477009627; Thu, 14 Nov 2013 16:56:49 -0800 (PST) Received: by 10.112.46.98 with HTTP; Thu, 14 Nov 2013 16:56:49 -0800 (PST) Date: Thu, 14 Nov 2013 19:56:49 -0500 Message-ID: From: Phillip Hallam-Baker To: "secdir@ietf.org" , draft-ietf-pcp-description-option@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c23c885bce8304eb2cac32 Subject: [secdir] SECDIR Review of draft-ietf-pcp-description-option-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 00:56:56 -0000 --001a11c23c885bce8304eb2cac32 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. The document adds a 'description' option to the PCP protocol. The description does not have defined semantics in PCP. As such the Security Considerations relies on the considerations in the PCP specification. This seems ill advised to me. Even though the field has no semantics in PCP it is essentially the equivalent of a TXT RR in the DNS, possibly the most over-used and abused RR in the DNS protocol. If the description option is added then people are going to start using it to define site local semantics unless there is some other mechanism for that purpose. I suggest that the draft authors either add a description of how to use the PCP mechanisms for this purpose (if applicable) or describe a mechanism to support this use and preferably providing some sort of protection against collisions. Such a mechanism needs to consider the authenticity of the data provided and the risk that it might disclose data to another application. -- Website: http://hallambaker.com/ --001a11c23c885bce8304eb2cac32 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0 I have reviewed this document as part of the security= directorate's
ongoing effort to review all IETF documents being processed by the<= br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">I= ESG. =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.

The document adds a 'description' option to the PCP protocol. = The description does not have defined semantics in PCP. As such the Securit= y Considerations relies on the considerations in the PCP specification.

 --001a11c23c885bce8304eb2cac32-- From mohamed.boucadair@orange.com Thu Nov 14 23:40:07 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5692111E80DC for ; Thu, 14 Nov 2013 23:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VHEG-q0WceS for ; Thu, 14 Nov 2013 23:40:03 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB5111E80F6 for ; Thu, 14 Nov 2013 23:39:59 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 5A97A18C1FB; Fri, 15 Nov 2013 08:39:58 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 3C15A4C056; Fri, 15 Nov 2013 08:39:58 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Fri, 15 Nov 2013 08:39:58 +0100 From: To: Phillip Hallam-Baker , "secdir@ietf.org" , "draft-ietf-pcp-description-option@tools.ietf.org" Date: Fri, 15 Nov 2013 08:39:54 +0100 Thread-Topic: SECDIR Review of draft-ietf-pcp-description-option-02 Thread-Index: Ac7hnZZWE/nBvyXiT1OSQ6TChDQvwQANGxuA Message-ID: <94C682931C08B048B7A8645303FDC9F36F324262D9@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36F324262D9PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.14.54215 Subject: Re: [secdir] SECDIR Review of draft-ietf-pcp-description-option-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 07:40:07 -0000 --_000_94C682931C08B048B7A8645303FDC9F36F324262D9PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Phillip, Thank you for the review. The option as defined in the document does not influence the decision-makin= g process of the PCP Server. Furthermore, a PCP client is not allowed to re= trieve a description associated with a state maintained by the server; all = what it can do is to erase it, add one or update an existing one. Given this clarification, do you still think there is an issue that should = be addressed? Thanks. Cheers, Med De : Phillip Hallam-Baker [mailto:hallam@gmail.com] Envoy=E9 : vendredi 15 novembre 2013 01:57 =C0 : secdir@ietf.org; draft-ietf-pcp-description-option@tools.ietf.org Objet : SECDIR Review of draft-ietf-pcp-description-option-02 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 adds a 'description' option to the PCP protocol. The descripti= on does not have defined semantics in PCP. As such the Security Considerati= ons relies on the considerations in the PCP specification. This seems ill advised to me. Even though the field has no semantics in PCP= it is essentially the equivalent of a TXT RR in the DNS, possibly the most= over-used and abused RR in the DNS protocol. If the description option is added then people are going to start using it = to define site local semantics unless there is some other mechanism for tha= t purpose. I suggest that the draft authors either add a description of how= to use the PCP mechanisms for this purpose (if applicable) or describe a m= echanism to support this use and preferably providing some sort of protecti= on against collisions. Such a mechanism needs to consider the authenticity of the data provided an= d the risk that it might disclose data to another application. -- Website: http://hallambaker.com/ --_000_94C682931C08B048B7A8645303FDC9F36F324262D9PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Phillip,=

 

Thank you for the review.

=  

The option as defined in the= document does not influence the decision-making process of the PCP Server.= Furthermore, a PCP client is not allowed to retrieve a description associa= ted with a state maintained by the server; all what it can do is to erase i= t, add one or update an existing one.

 

Given this clarification,= do you still think there is an issue that should be addressed? Thanks.

 

Cheers,

Med

 

=  

= De : Phillip Hallam-Baker [mailto:hallam@gmail.com]
<= b>Envoy=E9 : vendredi 15 novembre 2013 01:57
=C0 : = secdir@ietf.org; draft-ietf-pcp-description-option@tools.ietf.org
Obj= et : SECDIR Review of draft-ietf-pcp-description-option-02

 

  I have reviewed this document as part of the security direc= torate'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 shoul= d treat
these comments just like any other last call comments.

 

The docume= nt adds a 'description' option to the PCP protocol. The description does no= t have defined semantics in PCP. As such the Security Considerations relies= on the considerations in the PCP specification.

 

This seems ill advise= d to me. Even though the field has no semantics in PCP it is essentially th= e equivalent of a TXT RR in the DNS, possibly the most over-used and abused= RR in the DNS protocol.

 

If the description option is added then peopl= e are going to start using it to define site local semantics unless there i= s some other mechanism for that purpose. I suggest that the draft authors e= ither add a description of how to use the PCP mechanisms for this purpose (= if applicable) or describe a mechanism to support this use and preferably p= roviding some sort of protection against collisions.

<= /div>

 

Such a mechanism needs to consider the authenticity of the data pr= ovided and the risk that it might disclose data to another application.

= --_000_94C682931C08B048B7A8645303FDC9F36F324262D9PUEXCB1Bnante_-- From sm@elandsys.com Fri Nov 15 00:26:27 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A4A21F9A59; Fri, 15 Nov 2013 00:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaqGzQkLzQBK; Fri, 15 Nov 2013 00:26:25 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8038E11E8106; Fri, 15 Nov 2013 00:26:24 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.143.151]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rAF8PwUb009498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Nov 2013 00:26:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1384503974; bh=wt1jOy4+ApxDpy6ZHcQoy60FcEPopExSeA65V8N2/cE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=haV0frKuC0eERv7P+xf5XtUKMAKi82P96dwkSS37mm8v8qcAs8WSfLau6q+ilnhLC PgYIGUpw5O2QT1O0JEXwBs/FHoXjaYmsvNpD+Vk15EOLeuRzzGMMqHYPpYZC8EeVdw RKP7YBCEFQ+JOeJ4A8XxXFA7hfkzzyMNT1YcNugA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1384503974; i=@elandsys.com; bh=wt1jOy4+ApxDpy6ZHcQoy60FcEPopExSeA65V8N2/cE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=yzEdcB79H7ZRePHxG4d4wcpKhTafaJYnwRYOI0gcCIg58D/TzrLNnHTT9JjH4wrze 4I1g98x0vzgJvH+eouuWSMYgyyt+atR7SvfG0a6cHfPhO8/DT7YeLEYVKW5qnM9i+2 y1YRiZuF6/b3SpnpJ2X4sGxbwqOprSWGHYHemBOg= Message-Id: <6.2.5.6.2.20131114210001.06d56f78@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 15 Nov 2013 00:10:50 -0800 To: Alan DeKok , secdir@ietf.org, draft-moonesamy-ietf-conduct-3184bis.all@tools.ietf.org From: S Moonesamy In-Reply-To: <5284FBA2.3000404@deployingradius.com> References: <5284FBA2.3000404@deployingradius.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Ines Robles , ietf@ietf.org Subject: Re: [secdir] Secdir review of draft-moonesamy-ietf-conduct-3184bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 08:26:28 -0000 Hi Alan, At 08:34 14-11-2013, Alan DeKok 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 provides a set of guidelines for personal interaction at >the IETF. This review therefore ignores any computer protocol issues or >attacks, and focuses on personal and procedural attacks. > >... >2. Principles of Conduct > > 1. IETF participants extend respect and courtesy to their colleagues > at all times. > > This is a lofty goal, especially considering the next sentence: > > IETF participants come from diverse origins and backgrounds and > are equipped with multiple capabilities and ideals. > > I would suggest adding "expectations and assumptions" to that >sentence. Very often, misunderstandings come from differing >expectations. Two participants might believe they share a language. >However, underlying assumptions mean that the words have different >meanings. The expectations means that the approach people take is >different. Quoting from Section 2 of RFC 3184: "1. IETF participants extend respect and courtesy to their colleagues at all times. IETF participants come from diverse origins and backgrounds and are equipped with multiple capabilities and ideals." I read it more of a guideline than a goal. Please note that the guideline or goal has been there for over ten years and every participant since then agreed to follow it. I agree that misunderstandings come from differing expectations. I'll suggest the following change to the first sentence of the second paragraph in Section 2: IETF participants come from diverse origins and backgrounds; there can be different expectations or assumptions. Regardless of these individual differences, participants treat their colleagues with respect as persons especially when it is difficult to agree with them. Seeing from another's point of view is often revealing even when it fails to be compelling. > On a simplistic level, everyone believes that they are a reasonable >person. Everyone believes that other people have the same mental models >they do. Everyone believes that other people do (and will) behave the >way that they do. Agreed. > These assumptions are often wrong. Discord in groups often comes from >the misunderstanding what other people mean, and attributing >maliciousness to what is actually differing assumptions and expectations. Agreed. > 2. IETF participants discuss ideas impersonally without finding fault > with the person proposing the idea. > > It may be useful to re-phrase this as a positive statement. i.e.: > > IETF participants discuss impersonal ideas, using evidence, fact, and >logic. Discussions of persons, personalities, or motivations are >outside of the scope of the IETF. There is the following two paragraphs after the above: "try to provide data and facts for your standpoints". That would cover evidence and fact. I'll suggest the following text based on the "positive statement" comment. I'll include the text from the following paragraph as there has been changes to it: 2. IETF participants have impersonal discussions. We dispute ideas by using reasoned argument rather than through intimidation or personal attack. Try to provide data and facts for your standpoints so the rest of the participants who are sitting on the sidelines watching the discussion can form an opinion. The discussion is easier when the response to a simple question is a polite answer [SQPA]. > Items (3) and (4) seem reasonable to me. > > Other items which may be considered are the following. They are less >inter-personal behavior, than behavior of an individual interacting with >the larger IETF. > >- progress. Participants are expected to contribute to the progress of >the working group. Simple participation isn't enough. We have to get >things *done*. Agreed. The question I would ask is: how can Person X contribute to the progress of the working group? It helps to have participants who take a critical view of the work. Personally, I would not consider that as hampering progress. It's difficult for an individual to determine whether he or she is being too insistent or not. >- consensus. Participants are expected to accept the consensus of the >WG or the larger IETF. Standards creation necessarily involves >compromise. Compromise doesn't mean you've been personally put down. >It just means life is imperfect. Yes. There are times when a group gets into group-think. A person might consider conforming to the opinions expressed by others as accepting the consensus even though the person considers that the group's decision is incorrect. The items (see above) would fit within a discussion about both conduct and consensus. It would be useful to document it in a Wiki. > IMHO, the Security Considerations section is not correct. > > Guidelines about IETF conduct do not affect the security of the > Internet in any way. The following text was suggested [1]: Guidelines about IETF conduct do not directly affect the security of the Internet. > A social denial of service attack can affect the security of the >Internet. The way to shut down progress on security solutions is simple >and cheap. Attack the relevant players in court with spurious >accusations of harassment. Sideline the group with discussion of >politics. Have people "pick sides", and generally devolve the group >into endless bickering. I agree that the above can be a problem. RFC 3552 can be used for the security aspect. The document can fix the social issues. It is up to whomever is responsible to step in when there is bickering. > The IETF has been subject to minor attacks by people who engage in >attacks, appeals, and who are repeatedly banned from WG participation. Appeals are a part of the process. I would look at the above as an inconvenience instead of an attack. >If one person made it their life goal to destroy the IETF with false >allegations, they could have a significant impact on progress. Yes. It's better not to give a person a reason to do that. Thanks for the review. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/ietf/current/msg83994.html From new-work-bounces@ietf.org Thu Nov 14 09:23: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 89E1D21E8098; Thu, 14 Nov 2013 09:23:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1384449810; bh=4PRvp07mLySCbKQlwi+8BGVvHlNMRijU6BsVssZAzJE=; h=From:To:Date:Message-ID:References:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=Z+a6YB8fgBxtE32PrOr1SEyQw5EoLAX+us9NwelAuCTgU9KqzUp6cEEy+UBa+gxmw zWgxLkpGt9pslY+VHkwfrncFlSftSj3kR/g8R7m1sPmEewVFsJmX2gTTT5tD+04ZIt lutnOUmPfQOvxmPTYmvGG85zujxPb6iG6CV2M7V4= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A86221E81A6 for ; Wed, 13 Nov 2013 21:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[AWL=-2.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7y6-uZJQE+w for ; Wed, 13 Nov 2013 21:05:18 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 851A021E81A4 for ; Wed, 13 Nov 2013 21:05:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,697,1378882800"; d="asc'?scan'208";a="74888413" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx11-out.netapp.com with ESMTP; 13 Nov 2013 21:05:18 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.51]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 21:05:18 -0800 From: "Eggert, Lars" To: "new-work@ietf.org" Thread-Topic: New: Network Coding Research Group (NWCRG) Thread-Index: AQHO4PZc1G8OyGWq+U+T0bHKy7nOjw== Date: Thu, 14 Nov 2013 05:05:17 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.114] MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 14 Nov 2013 09:23:29 -0800 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: multipart/mixed; boundary="===============3063426013990835459==" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 15 Nov 2013 08:26:07 -0800 Subject: [secdir] [new-work] Fwd: New: Network Coding Research Group (NWCRG) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 17:23:30 -0000 --===============3063426013990835459== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_0924CCF8-9120-4EA3-BB6B-5D95338E4032"; protocol="application/pgp-signature"; micalg=pgp-sha1 --Apple-Mail=_0924CCF8-9120-4EA3-BB6B-5D95338E4032 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: "Eggert, Lars" > Subject: New: Network Coding Research Group (NWCRG) > Date: November 14, 2013 at 5:59:55 GMT+1 > To: "irtf-announce@irtf.org" , = "irtf-discuss@irtf.org" > Reply-To: "irtf-discuss@irtf.org" >=20 > A new IRTF research group on Network Coding has been chartered: >=20 > The objective of the Network Coding Research Group (NWCRG) is > to research Network Coding principles and methods that can benefit > Internet communication. One goal of the NWCRG is to gather the > research results and posit the open questions related to Network > Coding in order to develop practical applications of Network Coding > that improve Internet communication. Another goal is to gather > information on the existing practical implementations of Network > Coding, distill common functionalities and propose a path to > standardization of Network Coding-enabled communication. >=20 > The full charter text and participation information can be found at = http://irtf.org/nwcrg >=20 > Lars Eggert > IRTF Chair --Apple-Mail=_0924CCF8-9120-4EA3-BB6B-5D95338E4032 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUoRaBNZcnpRveo1xAQKM4gP8DVrpMf0Xs/6Rn4YbPlWdvZWnCt0pr7je 7U538Zt9sya1V7PTpGuTwxHxd+RrKGDCuHpWcpx1CeulcNDTzf2YVbKcdIARSoSJ zK+m9T+ymGc0AeXdsyoZFT8FsAzKF/FaPFcYOXek1O43W2Vz549gia7wailkJW4q Sh1Sz4/xkTE= =zpP2 -----END PGP SIGNATURE----- --Apple-Mail=_0924CCF8-9120-4EA3-BB6B-5D95338E4032-- --===============3063426013990835459== 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 --===============3063426013990835459==-- From repenno@cisco.com Thu Nov 14 20:25:02 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F48D11E817E for ; Thu, 14 Nov 2013 20:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3kxf1XTI1a7 for ; Thu, 14 Nov 2013 20:24:57 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC3C11E8177 for ; Thu, 14 Nov 2013 20:24:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8864; q=dns/txt; s=iport; t=1384489497; x=1385699097; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=olkfOzxUxN01iUb3xGuvig5J6FRw3e/KY3Mf/gKcHoA=; b=dxx1qZV0B8Rho2IF+hl3DC5exrcrykvVLWrnotiSDEAx8uj4rI06NMsf Cr6ZftTFKV7kmC8qCPG7EoiGJ4pfYG6YTK7k+QGubTy2AAAhUc4+7pDlL zLjfsRQw8sSsIL3+a33g5EY/lkDfbOho+I7G8+4vxB1XSSpaddPjXvKqQ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIIAG+hhVKtJV2b/2dsb2JhbABZgkNEOFOEFKhniV+IRYEiFnSCJQECBIELAQgRAwECKCgRFAkIAgQBEodvAw8Ntn8NiVOMbYJkDQuEMQOWJYFrgS+LJYU4gyiCKg X-IronPort-AV: E=Sophos;i="4.93,704,1378857600"; d="scan'208,217";a="284900328" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 15 Nov 2013 04:24:35 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAF4OZ0H001223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Nov 2013 04:24:35 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.192]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 22:24:34 -0600 From: "Reinaldo Penno (repenno)" To: Phillip Hallam-Baker , "secdir@ietf.org" , "draft-ietf-pcp-description-option@tools.ietf.org" Thread-Topic: SECDIR Review of draft-ietf-pcp-description-option-02 Thread-Index: AQHO4Z2d3yMYBDQllE2JVi50kvlW4ZolkGiA Date: Fri, 15 Nov 2013 04:24:34 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.119.168] Content-Type: multipart/alternative; boundary="_000_CEAADCA1602Arepennociscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 15 Nov 2013 08:26:07 -0800 Subject: Re: [secdir] SECDIR Review of draft-ietf-pcp-description-option-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 04:25:02 -0000 --_000_CEAADCA1602Arepennociscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Phillip, Thanks for the review. Inline with [RP] From: Phillip Hallam-Baker > Date: Thursday, November 14, 2013 4:56 PM To: "secdir@ietf.org" >, "draft-ietf-pcp-description-option@tools.ietf.org" > Subject: SECDIR Review of draft-ietf-pcp-description-option-02 Resent-From: > Resent-To: >, "mohamed.boucadair@or= ange.com" >, Cisco Employee > Resent-Date: Thursday, November 14, 2013 4:57 PM 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 adds a 'description' option to the PCP protocol. The descripti= on does not have defined semantics in PCP. As such the Security Considerati= ons relies on the considerations in the PCP specification. This seems ill advised to me. Even though the field has no semantics in PCP= it is essentially the equivalent of a TXT RR in the DNS, possibly the most= over-used and abused RR in the DNS protocol. If the description option is added then people are going to start using it = to define site local semantics unless there is some other mechanism for tha= t purpose. [RP] Different from DNS a PCP client can not query the description of its m= appings. Can you give me an example of such site local semantics so I can = understand better your concern? I found this: https://support.google.com/a/answer/2716800?hl=3Den But it relies on the fact that DNS clients can query such information. I suggest that the draft authors either add a description of how to use the= PCP mechanisms for this purpose (if applicable) or describe a mechanism to= support this use and preferably providing some sort of protection against = collisions. Such a mechanism needs to consider the authenticity of the data provided an= d the risk that it might disclose data to another application. -- Website: http://hallambaker.com/ --_000_CEAADCA1602Arepennociscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <61C93E6EED991F4BA841CC26256EF514@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hello Phillip,

Thanks for the review. Inline with [RP]


  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 adds a 'description' opti= on to the PCP protocol. The description does not have defined semantics in = PCP. As such the Security Considerations relies on the considerations in th= e PCP specification.

This seems ill advised to me. Even tho= ugh the field has no semantics in PCP it is essentially the equivalent of a= TXT RR in the DNS, possibly the most over-used and abused RR in the DNS pr= otocol.

If the description option is added the= n people are going to start using it to define site local semantics unless = there is some other mechanism for that purpose.

[RP] Different from DNS a PCP client can not query the description of = its mappings.  Can you give me an example of such site local semantics= so I can understand better your concern?  I found this:

But it relies on the fact that DNS clients can query such information.=  

I suggest that the draft authors eithe= r add a description of how to use the PCP mechanisms for this purpose (if a= pplicable) or describe a mechanism to support this use and preferably provi= ding some sort of protection against collisions.

Such a mechanism needs to consider the authenticity of the data provid= ed and the risk that it might disclose data to another application.
 --_000_CEAADCA1602Arepennociscocom_-- From hallam@gmail.com Fri Nov 15 19:18:30 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583C911E816B for ; Fri, 15 Nov 2013 19:18:30 -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=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeW5AoiEETuI for ; Fri, 15 Nov 2013 19:18:29 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E4C1E11E813A for ; Fri, 15 Nov 2013 19:18:28 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id w7so3330363lbi.18 for ; Fri, 15 Nov 2013 19:18:27 -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=doYmOSPsjpv6mWidXWXW1RGeHf+0gqNOQ24R4eIXZ3s=; b=TOft7KDFWs0IBiY/VVfXwFSilH92xBtZYxRqx/iozuYR8SjPuNDFzDiB55mB+5ez56 vbHwINb+reWW4Aoh1HQXDgf9YRtjKTppoJIZGxBLa6jgZbfF+Pv7bjmpFnvyhhXgIE9e rgcxvqwIuv2kOaX4MX+PuSEIDdWbVZ5ZGZ3nknqbQBEE1kdlzhlqU2ZoHf0BYHGPaOx+ L9ZW47/khhx3c+F4IbRB/Ev36LmbV6bC/JS2ieZQeaXwzRDj4yZb3vTgpODj6Epo4m6N 3BnSnUxraJrjUUQfG/TIA0KYq7V4dfkuimCSEaIwwarTTgEpmk0vjYXAKI3JnaMZC19k SQ9w== MIME-Version: 1.0 X-Received: by 10.112.56.177 with SMTP id b17mr536363lbq.74.1384571907759; Fri, 15 Nov 2013 19:18:27 -0800 (PST) Received: by 10.112.46.98 with HTTP; Fri, 15 Nov 2013 19:18:27 -0800 (PST) In-Reply-To: References: Date: Fri, 15 Nov 2013 22:18:27 -0500 Message-ID: From: Phillip Hallam-Baker To: "Reinaldo Penno (repenno)" Content-Type: multipart/alternative; boundary=001a1133ab8aba63df04eb42c40f Cc: "draft-ietf-pcp-description-option@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR Review of draft-ietf-pcp-description-option-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 03:18:30 -0000 --001a1133ab8aba63df04eb42c40f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 14, 2013 at 11:24 PM, Reinaldo Penno (repenno) < repenno@cisco.com> wrote: > Hello Phillip, > > Thanks for the review. Inline with [RP] > > From: Phillip Hallam-Baker > Date: Thursday, November 14, 2013 4:56 PM > To: "secdir@ietf.org" , " > draft-ietf-pcp-description-option@tools.ietf.org" < > draft-ietf-pcp-description-option@tools.ietf.org> > Subject: SECDIR Review of draft-ietf-pcp-description-option-02 > Resent-From: > Resent-To: , "mohamed.boucadair@orange.com" < > mohamed.boucadair@orange.com>, Cisco Employee > Resent-Date: Thursday, November 14, 2013 4:57 PM > > 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 adds a 'description' option to the PCP protocol. The > description does not have defined semantics in PCP. As such the Security > Considerations relies on the considerations in the PCP specification. > > This seems ill advised to me. Even though the field has no semantics in > PCP it is essentially the equivalent of a TXT RR in the DNS, possibly the > most over-used and abused RR in the DNS protocol. > > If the description option is added then people are going to start using > it to define site local semantics unless there is some other mechanism for > that purpose. > > [RP] Different from DNS a PCP client can not query the description of > its mappings. Can you give me an example of such site local semantics so I > can understand better your concern? I found this: > > https://support.google.com/a/answer/2716800?hl=en > > But it relies on the fact that DNS clients can query such information. > > I suggest that the draft authors either add a description of how to > use the PCP mechanisms for this purpose (if applicable) or describe a > mechanism to support this use and preferably providing some sort of > protection against collisions. > > Such a mechanism needs to consider the authenticity of the data > provided and the risk that it might disclose data to another application. > > I presume that the reason that information is being fed into this system is that it is expected that there will be parties that read it out. Those may not be PCP clients but it is surely not the empty set or what would be the point of the feature? If you provide a communication channel between two pieces of apparatus which has no defined function then expect it to be used in lots of unexpected ways. -- Website: http://hallambaker.com/ --001a1133ab8aba63df04eb42c40f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Nov 14, 2013 at 11:24 PM, Reinaldo Penno (repenno) <repenn= o@cisco.com> wrote:
Hello Phillip,

Thanks for the review. Inline with [RP]

From: Phillip Hallam-Baker <hallam@gmail.com><= br> Date: Thursday, November 14, 2013 4= :56 PM
To: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-pcp-description-option@tools.ietf.org" <draft-ietf-pcp-description-option@tools.ietf.org> Subject: SECDIR Review of draft-iet= f-pcp-description-option-02
Resent-From: <draft-alias-bounces@t= ools.ietf.org>
Resent-To: <dwing@cisco.com>, "mohamed.boucadair@or= ange.com" <mohamed.boucadair@orange.com>, Cisco Employee <= repenno@cisco.com>
Resent-Date: Thursday, November 14,= 2013 4:57 PM

=A0 I have reviewed this document as part of the security= directorate's
ongoing effort to review all IETF documents being processed by the<= br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"> 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.

The document adds a 'description&#= 39; option to the PCP protocol. The description does not have defined seman= tics in PCP. As such the Security Considerations relies on the consideratio= ns in the PCP specification.

This seems ill advised to me. Even tho= ugh the field has no semantics in PCP it is essentially the equivalent of a= TXT RR in the DNS, possibly the most over-used and abused RR in the DNS pr= otocol.

If the description option is added the= n people are going to start using it to define site local semantics unless = there is some other mechanism for that purpose.

[RP] Different from DNS a PCP client can not query the description of = its mappings. =A0Can you give me an example of such site local semantics so= I can understand better your concern? =A0I found this:


But it relies on the fact that DNS clients can query such information.= =A0

I suggest that the draft authors eithe= r add a description of how to use the PCP mechanisms for this purpose (if a= pplicable) or describe a mechanism to support this use and preferably provi= ding some sort of protection against collisions.

Such a mechanism needs to consider the authenticity of the data provid= ed and the risk that it might disclose data to another application.


<= /div>
I presume that the reason that information is being fed into this= system is that it is expected that there will be parties that read it out.=

Those may not be PCP clients but it is surely not the e= mpty set or what would be the point of the feature?

If you provide a communication channel between two pieces of apparatus wh= ich has no defined function then expect it to be used in lots of unexpected= ways.


--
Website: http://hallambaker.com/
--001a1133ab8aba63df04eb42c40f-- From repenno@cisco.com Sat Nov 16 14:23:55 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A974D11E81AC for ; Sat, 16 Nov 2013 14:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16V3av3b6oB2 for ; Sat, 16 Nov 2013 14:23:49 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id A361811E8357 for ; Sat, 16 Nov 2013 14:23:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13338; q=dns/txt; s=iport; t=1384640629; x=1385850229; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=aH968FQbQiWzDYwKcWq+WFTifssPusOjOH4J+gYSVMI=; b=VBNkoOCLejGmIevStuX4QAdj3VVem0nKnb+4FxAgeYc7MVAbMpzYBtqZ EkUUuoErkZIXz8Kqb8fToGLDg9EEmxaXK+tO2X3HLU6wfoLNlOe7JuT5n ksmDQr79kn/KWBgePFAE2eODozVSumjpgqMW9yva/d+0gtdcdXS4thaVs A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4HABPwh1KtJV2b/2dsb2JhbABZgkNEOFOtCYlgiEWBHRZ0giUBAgR5EgEIEQMBAigoERQJCAIEDgWHbwMPDbdSDYk5F4xzgmUNBAcJhCgDliWBa4EviyaFOIMogio X-IronPort-AV: E=Sophos;i="4.93,715,1378857600"; d="scan'208,217";a="87083" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP; 16 Nov 2013 22:23:47 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAGMNlMI000817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 16 Nov 2013 22:23:47 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.192]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Sat, 16 Nov 2013 16:23:47 -0600 From: "Reinaldo Penno (repenno)" To: Phillip Hallam-Baker Thread-Topic: SECDIR Review of draft-ietf-pcp-description-option-02 Thread-Index: AQHO4Z2d3yMYBDQllE2JVi50kvlW4ZolkGiAgAIF+oCAALkuAA== Date: Sat, 16 Nov 2013 22:23:46 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.127.247] Content-Type: multipart/alternative; boundary="_000_CEAD2EF76145repennociscocom_" MIME-Version: 1.0 Cc: "draft-ietf-pcp-description-option@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR Review of draft-ietf-pcp-description-option-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 22:23:56 -0000 --_000_CEAD2EF76145repennociscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Phillip Hallam-Baker > Date: Friday, November 15, 2013 7:18 PM To: Cisco Employee > Cc: "secdir@ietf.org" >, "draft-ietf-pcp-description-option@tools.ietf.org" > Subject: Re: SECDIR Review of draft-ietf-pcp-description-option-02 On Thu, Nov 14, 2013 at 11:24 PM, Reinaldo Penno (repenno) > wrote: Hello Phillip, Thanks for the review. Inline with [RP] From: Phillip Hallam-Baker > Date: Thursday, November 14, 2013 4:56 PM To: "secdir@ietf.org" >, "draft-ietf-pcp-description-option@tools.ietf.org" > Subject: SECDIR Review of draft-ietf-pcp-description-option-02 Resent-From: > Resent-To: >, "mohamed.boucadair@or= ange.com" >, Cisco Employee > Resent-Date: Thursday, November 14, 2013 4:57 PM 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 adds a 'description' option to the PCP protocol. The descripti= on does not have defined semantics in PCP. As such the Security Considerati= ons relies on the considerations in the PCP specification. This seems ill advised to me. Even though the field has no semantics in PCP= it is essentially the equivalent of a TXT RR in the DNS, possibly the most= over-used and abused RR in the DNS protocol. If the description option is added then people are going to start using it = to define site local semantics unless there is some other mechanism for tha= t purpose. [RP] Different from DNS a PCP client can not query the description of its m= appings. Can you give me an example of such site local semantics so I can = understand better your concern? I found this: https://support.google.com/a/answer/2716800?hl=3Den But it relies on the fact that DNS clients can query such information. I suggest that the draft authors either add a description of how to use the= PCP mechanisms for this purpose (if applicable) or describe a mechanism to= support this use and preferably providing some sort of protection against = collisions. Such a mechanism needs to consider the authenticity of the data provided an= d the risk that it might disclose data to another application. I presume that the reason that information is being fed into this system is= that it is expected that there will be parties that read it out. [RP2] Yes, an admin can see the description associated with each mapping fo= r troubleshooting purposes. Those may not be PCP clients but it is surely not the empty set or what wou= ld be the point of the feature? If you provide a communication channel between two pieces of apparatus whic= h has no defined function then expect it to be used in lots of unexpected w= ays. [RP2] I see it as a troubleshooting tool for admins since client knows its = own description or can override if it wants. -- Website: http://hallambaker.com/ --_000_CEAD2EF76145repennociscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable


From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Friday, November 15, 2013 7:1= 8 PM
To: Cisco Employee <repenno@cisco.com>
Cc: "secdir@ietf.org" <= secdir@ietf.org>, "draft-ietf-pcp-description-option@tools.ietf.org" <dr= aft-ietf-pcp-description-option@tools.ietf.org>
Subject: Re: SECDIR Review of draft= -ietf-pcp-description-option-02




On Thu, Nov 14, 2013 at 11:24 PM, Reinaldo Penno= (repenno) <repenno@cisco.com> wrote:
Hello Phillip,

Thanks for the review. Inline with [RP]

From: Phillip Hallam-Baker <hallam@gmail.com><= br> Date: Thursday, November 14, 2013 4= :56 PM
To: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-pcp-description-option@tools.ietf.org" <draft-ietf-pcp-description-option@tools.ietf.org> Subject: SECDIR Review of draft-iet= f-pcp-description-option-02
Resent-From: <draft-alias-bounces@t= ools.ietf.org>
Resent-To: <dwing@cisco.com>, "mohamed.boucadair@or= ange.com" <mohamed.boucadair@orange.com>, Cisco Employee <= repenno@cisco.com>
Resent-Date: Thursday, November 14,= 2013 4:57 PM

  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 adds a 'description' opti= on to the PCP protocol. The description does not have defined semantics in = PCP. As such the Security Considerations relies on the considerations in th= e PCP specification.

This seems ill advised to me. Even tho= ugh the field has no semantics in PCP it is essentially the equivalent of a= TXT RR in the DNS, possibly the most over-used and abused RR in the DNS pr= otocol.

If the description option is added the= n people are going to start using it to define site local semantics unless = there is some other mechanism for that purpose.

[RP] Different from DNS a PCP client can not query the description of = its mappings.  Can you give me an example of such site local semantics= so I can understand better your concern?  I found this:


But it relies on the fact that DNS clients can query such information.=  

I suggest that the draft authors eithe= r add a description of how to use the PCP mechanisms for this purpose (if a= pplicable) or describe a mechanism to support this use and preferably provi= ding some sort of protection against collisions.

Such a mechanism needs to consider the authenticity of the data provid= ed and the risk that it might disclose data to another application.


I presume that the reason that information is being fed into this syst= em is that it is expected that there will be parties that read it out.

[RP2] Yes, an admin can see the description associated with each mappi= ng for troubleshooting purposes. 

Those may not be PCP clients but it is surely not the empty set or wha= t would be the point of the feature?

If you provide a communication channel between two pieces of apparatus= which has no defined function then expect it to be used in lots of unexpec= ted ways.

[RP2] I see it as a troubleshooting tool for admins since client knows= its own description or can override if it wants.
--_000_CEAD2EF76145repennociscocom_-- From vincent.roca@inria.fr Mon Nov 18 07:03:52 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE9011E8226; Mon, 18 Nov 2013 07:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.248 X-Spam-Level: X-Spam-Status: No, score=-110.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNSc7+7sCnUC; Mon, 18 Nov 2013 07:03:45 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id CB3D711E81A1; Mon, 18 Nov 2013 06:58:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,724,1378850400"; d="scan'208,217";a="43508314" Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 18 Nov 2013 15:58:04 +0100 From: Vincent Roca Content-Type: multipart/alternative; boundary=Apple-Mail-27-605074784 Date: Mon, 18 Nov 2013 15:58:04 +0100 Message-Id: To: IESG , draft-ietf-mmusic-duplication-grouping@tools.ietf.org, secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [secdir] Secdir review of draft-ietf-mmusic-duplication-grouping-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 15:03:53 -0000 --Apple-Mail-27-605074784 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. IMHO, the document is Almost ready. My main comment WRT this I-D is the following: 1- There is no reference to RFC4566 (SDP) security section! This is a = pity as the security considerations are very well addressed in this RFC, much better than in the present I-D I would say. Additionally, I don't think that adding duplication grouping to SDP = changes so much the situation WRT SDP security, so this is one more reason to have this reference. Otherwise: 2- The authors say that "there is a weak threat". Is the threat weak in = the sense it is unlikely to happen (why?), or is it weak in the sense it = will have limited consequences? In any case, I would be in favor of removing "weak" altogether. 3- Since we are now all aware of the necessity of making pervasive monitoring more complex, it could be useful to say that having some confidentiality is recommended (in addition to integrity and = authentication of course). This is not discussed in RFC4566 (but it was published in = 2006), so it's worth mentioning it in this I-D (no need to say much). Non security related comment: 4- The [IC2011] reference should be updated. It's published, and the volume/number are now known. Cheers, Vincent= --Apple-Mail-27-605074784 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Almost = ready.

My main comment WRT = this I-D is the following:

1- There is no = reference to RFC4566 (SDP) security section! This is a pity
as = the security considerations are very well addressed in this RFC, = much
better than in the present I-D I would = say.
Additionally, I don't think that adding duplication = grouping to SDP changes
so much the situation WRT SDP = security, so this is one more reason to
have = this reference.


Otherwise:

2- The authors say that "there is a weak threat". = Is the threat weak in the
sense it is unlikely to happen = (why?), or is it weak in the sense it will = have
limited consequences? In any case, I would be in = favor of removing
"weak" = altogether.

3- Since we are now all aware of = the necessity of making pervasive
monitoring more =  complex, it could be useful to say that having = some
confidentiality is recommended (in addition to = integrity and authentication
of course). This is not = discussed in RFC4566 (but it was published in 2006),
so = it's worth mentioning it in this I-D (no need to say = much).


Non security related = comment:

4- The [IC2011] reference should be = updated. It's published, and the
volume/number are now = known.


Cheers,
   Vincent
= --Apple-Mail-27-605074784-- From abegen@cisco.com Mon Nov 18 07:25:04 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB2D11E80ED; Mon, 18 Nov 2013 07:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6i4J6iS5SjS; Mon, 18 Nov 2013 07:24:58 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD9C11E8159; Mon, 18 Nov 2013 07:22:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2290; q=dns/txt; s=iport; t=1384788155; x=1385997755; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nIivDV8bhaqbEBpqOOadLbOte1CPX/n4Nn6ZFhZGJ4k=; b=Q2d0SuNPhFEzVtNOjvUhttsqz9YHuDSS05tb2ODlmSsDfdhWsbttclpk 11Sx2yNVdrwrnniLVSZIfs22a+UXtylhkObahYU4foM5rXprOzEoCalc1 rDugOIF4DSjJC1YalxBfFXaYPhQY8lEy5JAj6JC0Np+KokLPFc0G50rv2 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAPAvilKtJXG//2dsb2JhbABZgmYhgQu/NoEaFnSCJQEBAQMBOj8FCwIBCDYQMiUCBA4Fh3sGAcJGF44ngQ8zB4MggREDmBCSDYMogWhC X-IronPort-AV: E=Sophos;i="4.93,724,1378857600"; d="scan'208";a="282840396" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 18 Nov 2013 15:22:35 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAIFMYXK005098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Nov 2013 15:22:34 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Mon, 18 Nov 2013 09:22:33 -0600 From: "Ali C. Begen (abegen)" To: Vincent Roca Thread-Topic: Secdir review of draft-ietf-mmusic-duplication-grouping-03 Thread-Index: AQHO5G6l0VmmAn1+8kCtbmpRZWJM4Jorf7gA Date: Mon, 18 Nov 2013 15:22:33 +0000 Message-ID: <2816F03A-D44B-4408-A86A-26585F6B583D@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.243.139] Content-Type: text/plain; charset="us-ascii" Content-ID: <3C20DEFCA8189F4BBBAAD1EC2213DCBD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-mmusic-duplication-grouping-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 15:25:04 -0000 Hi Vincent, On Nov 18, 2013, at 4:58 PM, Vincent Roca wrote: > Hello, >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > IMHO, the document is Almost ready. >=20 > My main comment WRT this I-D is the following: >=20 > 1- There is no reference to RFC4566 (SDP) security section! This is a pit= y > as the security considerations are very well addressed in this RFC, much > better than in the present I-D I would say. > Additionally, I don't think that adding duplication grouping to SDP chang= es > so much the situation WRT SDP security, so this is one more reason to > have this reference. We can add this, no worries. I think we simply followed RFC 5888 in this se= ction but your point is taken. >=20 >=20 > Otherwise: >=20 > 2- The authors say that "there is a weak threat". Is the threat weak in t= he > sense it is unlikely to happen (why?), or is it weak in the sense it will= have > limited consequences? In any case, I would be in favor of removing > "weak" altogether. It means it is unlikely to happen because if someone can modify the SDP for= changing the grouping, it can actually do much worse things by changing ot= her things.=20 >=20 > 3- Since we are now all aware of the necessity of making pervasive > monitoring more complex, it could be useful to say that having some > confidentiality is recommended (in addition to integrity and authenticati= on > of course). This is not discussed in RFC4566 (but it was published in 200= 6), > so it's worth mentioning it in this I-D (no need to say much). Personally I dont think anything we say in this draft will have any impact = in this regard but I can add this when doing the revision. >=20 >=20 > Non security related comment: >=20 > 4- The [IC2011] reference should be updated. It's published, and the > volume/number are now known. Good point, I thought this was fixed. Thanks. >=20 >=20 > Cheers, >=20 > Vincent From catherine.meadows@nrl.navy.mil Mon Nov 18 15:26: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 8CCCE1AE298; Mon, 18 Nov 2013 15:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525] 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 xlUmo8_MiMBM; Mon, 18 Nov 2013 15:26:27 -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 A4EFC1AE11F; Mon, 18 Nov 2013 15:26:27 -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 rAINQIO9006744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Nov 2013 18:26:18 -0500 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_6E5816FF-84FD-4050-83C8-F3F78F02B8A4" Date: Mon, 18 Nov 2013 18:26:51 -0500 Message-Id: <0B7C3927-F400-4059-893C-61FB71BED69B@nrl.navy.mil> To: secdir@ietf.org, iesg@ietf.org, draft-ietf-httpbis-authscheme-registrations.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-httpbis-authscheme-registrations-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, 18 Nov 2013 23:26:29 -0000 --Apple-Mail=_6E5816FF-84FD-4050-83C8-F3F78F02B8A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 registers Hypertext Transfer Protocol (HTTP) = authentication schemes which have been defined in standards=3Dtract RCFs before the IANA HTTP Authentication Scheme Registry was = established. My understanding is that registration does not constitute an endorsement = of security; it simply allows IANA do make sure that any identifiers, etc. specified remain unique. Thus I do not see any = security issues with this document. 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=_6E5816FF-84FD-4050-83C8-F3F78F02B8A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I = have reviewed this document as part of the security = directorate's 
ongoing effort to review all IETF = documents being processed by the 
IESG.  These = comments were written primarily for the benefit of = the 
security area directors.  Document editors and = WG chairs should treat 
these comments just like any other = last call comments.


This document = registers Hypertext Transfer Protocol (HTTP) authentication schemes = which have been defined in standards=3Dtract
RCFs before the IANA = HTTP Authentication Scheme Registry was = established.

My understanding is that = registration does not constitute an endorsement of security; it simply = allows IANA do make sure that any
identifiers, etc. specified = remain unique.  Thus I do not see any security issues with this = document.




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=_6E5816FF-84FD-4050-83C8-F3F78F02B8A4-- From tlyu@mit.edu Mon Nov 18 19:51: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 30F451AEC8D; Mon, 18 Nov 2013 19:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.126 X-Spam-Level: X-Spam-Status: No, score=-3.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525, 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 gX25IXKUJMwk; Mon, 18 Nov 2013 19:51:37 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5B61AEC8A; Mon, 18 Nov 2013 19:51:36 -0800 (PST) X-AuditID: 12074422-b7f9d6d000000bc0-8b-528ae0421928 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 46.8A.03008.240EA825; Mon, 18 Nov 2013 22:51:30 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id rAJ3pTWS013969; Mon, 18 Nov 2013 22:51:30 -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 rAJ3pR5Q002933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Nov 2013 22:51:28 -0500 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id rAJ3pQ1Q007674; Mon, 18 Nov 2013 22:51:26 -0500 (EST) To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sidr-origin-ops.all@tools.ietf.org From: Tom Yu Date: Mon, 18 Nov 2013 22:51:26 -0500 Message-ID: Lines: 22 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUixG6nruv0oCvI4NFNSYtLc9ktZvyZyGzx YeFDFgdmjyVLfjJ5fLn8mS2AKYrLJiU1J7MstUjfLoErY+3b12wFH9gq/lxextjAeIm1i5GT Q0LARGLH/GfsELaYxIV769m6GLk4hARmM0ncnPKHEcLZyCjx8M9dKOcck8T5aeuYIJwuRom2 tTdZQPpFBKIkLk1ZDjZXWMBc4vq/o0CzODjYBKQlji4uAwmzCKhK7N90kwnE5hWwkHiwZSaY zSPAKdF7eCorRFxQ4uTMJ2AjmQW0JG78e8k0gZFvFpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1 i5MT8/JSi3RN9XIzS/RSU0o3MYJDzUVpB+PPg0qHGAU4GJV4eCe4dwUJsSaWFVfmHmKU5GBS EuWNuwMU4kvKT6nMSCzOiC8qzUktPsQowcGsJMIreQUox5uSWFmVWpQPk5LmYFES573FYR8k JJCeWJKanZpakFoEk5Xh4FCS4DW9D9QoWJSanlqRlplTgpBm4uAEGc4DNPzqPZDhxQWJucWZ 6RD5U4yKUuK8C0ASAiCJjNI8uF5YKnjFKA70ijDvS5AqHmAaget+BTSYCWjw8edtIINLEhFS Ug2MLAnqCTFvbr34PrF4+6bou5XvOjcySPLM0Zt686wF74mlcZ6FL4/OurPkaeW2zndHw98f uPSBvWvxo9Umgh9WaUj7aF6buGFN3D3TJy8ePe5Ty/nmLrN1+s1j99XYp+jO/mGet74tTX3h B5XLzfY7s+d4BjrvDJwi9+ZWetGWIOX7Xz856794ukSJpTgj0VCLuag4EQCeih5H4AIAAA== Subject: [secdir] secdir review of draft-ietf-sidr-origin-ops-22 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, 19 Nov 2013 03:51:38 -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: Ready with nits. The Security Considerations section appears to accurately document the significant limitations of Route Origin Authorizations. There should probably be an example of the sort of privilege escalation attacks that can result from incautious Local-Preference attributes. Editorial: In Section 4, "along with it's traffic engineering characteristic(s)", change "it's" to "its". Section 5 mentions a block 10.0.666.0/24, which is somewhat distracting because that is not a valid IPv4 address block. From randy@psg.com Mon Nov 18 20:22:00 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 3353C1AED2E; Mon, 18 Nov 2013 20:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] 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 T2JzuVWF6r1S; Mon, 18 Nov 2013 20:21:58 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id C5E651AE667; Mon, 18 Nov 2013 20:21:58 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1Vicox-000117-D3; Tue, 19 Nov 2013 04:21:51 +0000 Date: Tue, 19 Nov 2013 13:21:44 +0900 Message-ID: From: Randy Bush To: Tom Yu In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: draft-ietf-sidr-origin-ops.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-sidr-origin-ops-22 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, 19 Nov 2013 04:22:00 -0000 thanks for the review > There should probably be an example of the sort of privilege > escalation attacks that can result from incautious Local-Preference > attributes. how about Local-Preference may be used to carry both the validity state of a prefix along with its traffic engineering (TE) characteristic(s). It is likely that an operator already using Local-Preference will have to change policy so they can encode these two separate characteristics in the same BGP attribute without negative impact or opening privilege escalation attacks. E.g. do not encode validation state in higher bits than used for TE. or do we need to spell it out with a hammer? > In Section 4, "along with it's traffic engineering characteristic(s)", > change "it's" to "its". > Section 5 mentions a block 10.0.666.0/24, which is somewhat > distracting because that is not a valid IPv4 address block. it's meant to be clearly invalid. the standard docco block could not be used as it was not big enough for the example (ops will laugh at 666 but freak out and rathole on a prefix longer than a /24). again, thanks. randy From tlyu@mit.edu Tue Nov 19 15:08:00 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 A3ECD1AE137; Tue, 19 Nov 2013 15:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.126 X-Spam-Level: X-Spam-Status: No, score=-3.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525, 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 83dICi3iqX1K; Tue, 19 Nov 2013 15:07:58 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id 212E81AE138; Tue, 19 Nov 2013 15:07:58 -0800 (PST) X-AuditID: 1209190e-b7efb6d000000bb9-72-528bef4707c6 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id 2E.47.03001.74FEB825; Tue, 19 Nov 2013 18:07:51 -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 rAJN7oZm007919; Tue, 19 Nov 2013 18:07:50 -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 rAJN7lgB008050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Nov 2013 18:07:49 -0500 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id rAJN7lVK010395; Tue, 19 Nov 2013 18:07:47 -0500 (EST) To: Randy Bush References: From: Tom Yu Date: Tue, 19 Nov 2013 18:07:47 -0500 In-Reply-To: (Randy Bush's message of "Tue, 19 Nov 2013 13:21:44 +0900") Message-ID: Lines: 69 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrev+vjvIoK9Px+LSXHaLGX8mMls8 a33JZPFh4UMWBxaPJUt+MnlMnTmb0ePL5c9sAcxRXDYpqTmZZalF+nYJXBmXt19lKVglWXHu xTz2BsYFIl2MnBwSAiYSE0/OYoawxSQu3FvP1sXIxSEkMJtJYs3Wv1DORkaJnr7T7CBVQgLn mCTevROHSHQxSjxqm8AKkhARkJO4eOIdI4jNLBAl8fniabCxwgLWEid+P2ODaI6QePBgMVMX IwcHm4C0xNHFZSAmi4CqxK5XciAVnAJpEscm7ASbwitgIXF53R8WEJtHgFNi3tvXLBBxQYmT M5+wQGzSkrjx7yXTBEbBWUhSs5CkFjAyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI11svNLNFL TSndxAgOYUm+HYxfDyodYhTgYFTi4ZVY0B0kxJpYVlyZe4hRkoNJSZR3wSugEF9SfkplRmJx RnxRaU5q8SFGCQ5mJRHeNS+AcrwpiZVVqUX5MClpDhYlcd6bHPZBQgLpiSWp2ampBalFMFkZ Dg4lCV79d0CNgkWp6akVaZk5JQhpJg5OkOE8QMMnvQUZXlyQmFucmQ6RP8WoKCXOaw3SLACS yCjNg+uFpZhXjOJArwjzmoJU8QDTE1z3K6DBTECD2SXBBpckIqSkGhhX60jr9ulMyGGeY7fs rnvyprCdOsaq2+35r/OG/tT4vO7pn96Yw8reXS/M5UX+PP8ucHi6/xJ398KtVsot60VbN7dL G/7/+/xTOG+J874D668psd1rdr+zMCFj3dTjF2wjHzg+KxLxKzF443r7gXb6PruDGtZqG/Vk L3Ituhr24u8i5Y8nPrIpsRRnJBpqMRcVJwIAX/OwigwDAAA= Cc: draft-ietf-sidr-origin-ops.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-sidr-origin-ops-22 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, 19 Nov 2013 23:08:00 -0000 Randy Bush writes: > thanks for the review > >> There should probably be an example of the sort of privilege >> escalation attacks that can result from incautious Local-Preference >> attributes. > > how about > > Local-Preference may be used to carry both the validity state of a > prefix along with its traffic engineering (TE) characteristic(s). It > is likely that an operator already using Local-Preference will have > to change policy so they can encode these two separate > characteristics in the same BGP attribute without negative impact or > opening privilege escalation attacks. E.g. do not encode validation > state in higher bits than used for TE. > > or do we need to spell it out with a hammer? I'm not sure I fully understand the scenarios, but I'm not very familiar with network operations. On further reflection, the paragraph you have written above greatly clarifies paragraph 6 of Section 5 and should probably replace it. The scenario you describe above seems to be one of multiple cases described in Section 5. Am I correct in understanding that there at least the following two sorts of inadvertent Local-Preference signaling that can occur when encoding policy information into Local-Preference? (1) As you describe above, RPKI validity state can override TE characteristics, contrary to operator intentions and possibly creating a security exposure. This can happen if RPKI validation state is encoded in higher bits than TE characteristics. (2) As described in paragraph 7 of Section 5, other policy metrics that depend on peer community signaling could override information about RPKI validity state, contrary to operator intentions and possibly creating a security exposure. (I assume "peer community" here means external BGP peers?) How about using something like the following text to replace the final paragraph of Security Considerations? When simultaneously encoding RPKI validity state and other policy information into Local-Preference, operators should take care to avoid creating privilege escalation exposures through such an encoding scheme, as described in Section 5. For example, RPKI validity state could inadvertently override other policy information such as traffic engineering preferences, or policy information computed based on signaling from external peers could inadvertently override RPKI validity state. >> Section 5 mentions a block 10.0.666.0/24, which is somewhat >> distracting because that is not a valid IPv4 address block. > > it's meant to be clearly invalid. the standard docco block could not be > used as it was not big enough for the example (ops will laugh at 666 but > freak out and rathole on a prefix longer than a /24). I defer to your greater familiarity with what readers in the operations community will find distracting. (Now that I think about it, a reasonable (if overly permissive) parsing of 10.0.666.0 would be equivalent to 10.2.154.0.) In the interest of consistency, I noticed that Section 3 uses a different example block: 10.0.66.0/24; did you intend to also use 10.0.666.0/24 there? From randy@psg.com Tue Nov 19 19:37: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 A9CC51AE1B6; Tue, 19 Nov 2013 19:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] 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 lmHlMApeyILU; Tue, 19 Nov 2013 19:37:47 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBB41AE1A2; Tue, 19 Nov 2013 19:37:47 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1Viybi-000455-HQ; Wed, 20 Nov 2013 03:37:39 +0000 Date: Wed, 20 Nov 2013 12:37:36 +0900 Message-ID: From: Randy Bush To: Tom Yu In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: draft-ietf-sidr-origin-ops.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-sidr-origin-ops-22 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 03:37:48 -0000 > The scenario you describe above seems to be one of multiple cases > described in Section 5. we have 42 ways to encode policy. there are more knobs than an antique hardware shop, and someone has asked for and used every one. [ i view this as a bug, not a feature, but i lost these battles many years ago ] i feared trying to enumerate the traps, hence the simple warning. perhaps what could help most is a once sentence definition of a downgrade attack. randy From vincent.roca@inria.fr Tue Nov 19 23:59:12 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 10DBD1AE394; Tue, 19 Nov 2013 23:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.075 X-Spam-Level: X-Spam-Status: No, score=-7.075 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525] 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 gVTSOJhc7F6q; Tue, 19 Nov 2013 23:59:10 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 91DA61AE391; Tue, 19 Nov 2013 23:59:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,735,1378850400"; d="scan'208";a="36660710" Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 20 Nov 2013 08:59:02 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Vincent Roca In-Reply-To: <2816F03A-D44B-4408-A86A-26585F6B583D@cisco.com> Date: Wed, 20 Nov 2013 08:59:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8A6B6759-BF9A-4C7B-9DBB-FEE3929CC7BD@inria.fr> References: <2816F03A-D44B-4408-A86A-26585F6B583D@cisco.com> To: Ali C. Begen (abegen) X-Mailer: Apple Mail (2.1085) Cc: "" , IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-mmusic-duplication-grouping-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, 20 Nov 2013 07:59:12 -0000 Hi Ali, Le 18 nov. 2013 =E0 16:22, Ali C. Begen (abegen) a =E9crit : > Hi Vincent, >=20 > On Nov 18, 2013, at 4:58 PM, Vincent Roca = wrote: >=20 >> IMHO, the document is Almost ready. >>=20 >> My main comment WRT this I-D is the following: >>=20 >> 1- There is no reference to RFC4566 (SDP) security section! This is a = pity >> as the security considerations are very well addressed in this RFC, = much >> better than in the present I-D I would say. >> Additionally, I don't think that adding duplication grouping to SDP = changes >> so much the situation WRT SDP security, so this is one more reason to >> have this reference. >=20 > We can add this, no worries. I think we simply followed RFC 5888 in = this section but your point is taken. I've missed this RFC. Anyway, a reference to RFC 4566 is fine as it = details security aspects with a reasonable level of details. >> Otherwise: >>=20 >> 2- The authors say that "there is a weak threat". Is the threat weak = in the >> sense it is unlikely to happen (why?), or is it weak in the sense it = will have >> limited consequences? In any case, I would be in favor of removing >> "weak" altogether. >=20 > It means it is unlikely to happen because if someone can modify the = SDP for changing the grouping, it can actually do much worse things by = changing other things.=20 Of course, but "weak" remains ambiguous (unless you say more) and in = fact not that important. >> 3- Since we are now all aware of the necessity of making pervasive >> monitoring more complex, it could be useful to say that having some >> confidentiality is recommended (in addition to integrity and = authentication >> of course). This is not discussed in RFC4566 (but it was published in = 2006), >> so it's worth mentioning it in this I-D (no need to say much). >=20 > Personally I dont think anything we say in this draft will have any = impact in this regard but I can add this when doing the revision. Yes, but focusing on integrity and source authentication only suggests that confidentiality is not an important service. That's my point. A = single sentence saying that it can sometimes be useful to use a secure, = encrypted channel or transport to carry the SDP is sufficient. Cheers, Vincent= From marc@petit-huguenin.org Wed Nov 20 06:08: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 438BF1ADFA3; Wed, 20 Nov 2013 06:08:20 -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 GfAY9s2YRI25; Wed, 20 Nov 2013 06:08:17 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id A84251ADF9F; Wed, 20 Nov 2013 06:08:16 -0800 (PST) Received: from [IPv6:2001:5c0:1101:2d00:5d1a:2875:2f86:e3ec] (unknown [IPv6:2001:5c0:1101:2d00:5d1a:2875:2f86:e3ec]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id A661720B97; Wed, 20 Nov 2013 15:08:08 +0100 (CET) Message-ID: <528CC246.3060102@petit-huguenin.org> Date: Wed, 20 Nov 2013 07:08:06 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: ietfdbh References: <03ad01cecb69$b3630a20$1a291e60$@comcast.net> In-Reply-To: <03ad01cecb69$b3630a20$1a291e60$@comcast.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: draft-ietf-avtext-multiple-clock-rates.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] FW: secdir review of draft-ietf-avtext-multiple-clock-rates-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 14:08:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi David, Thanks for the review and sorry for the late reply - a new job and an interstate move got in the way. See my answer below. On 10/17/2013 12:50 PM, ietfdbh wrote: > Hi, > > Whoops. I forgot to copy this beyond the > draft-ietf-avtext-multiple-clock-rates@ expansion. > > David Harrington ietfdbh@comcast.net +1-603-828-1401 > >> -----Original Message----- From: ietfdbh [mailto:ietfdbh@comcast.net] >> Sent: Wednesday, October 16, 2013 1:11 PM To: >> 'draft-ietf-avtext-multiple-clock-rates@tools.ietf.org' Subject: secdir >> review of draft-ietf-avtext-multiple-clock-rates-10 >> >> 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 clarifies the RTP specification when different clock rates >> are used in an RTP session. It also provides guidance on how to >> interoperate with legacy RTP implementations that use multiple clock >> rates. It updates RFC 3550. >> >> The security considerations section says " This document is not believed > to >> effect the security of the RTP sessions described here in any way." >> >> I have a concern. >> >> RFC3550 section 9.1 describes an encryption approach, and discusses the >> weakness of the encryption method because of poor randomness of timestamp >> offsets, and the potential for manipulation of the SSRC. >> >> Section 4 of the current document changes how SSRCs should be (must be) >> manipulated for different scenarios, and recommends, but does not >> require, different SSRCs for each clock rate. It also modifies how >> timestamps are calculated. The text does not really change the way SSRC have been supposed to be used; the text in RFC 3550 should have been interpreted as mandating different SSRC for different clock rates. But the fact is that most implementations were using it wrong (i.e. using non-monotonic timestamps), so whatever the security properties are of using non-monotonic timestamps, this draft mandates to go back to what RFC 3550 was saying from the beginning, and so when using section 4.1, the security properties are the same than for RFC 3550. But section 4.2 makes it legal to use the same SSRC when changing clock rates (making RTP receivers compatible with legacy RTP senders that got RFC 3550 wrong), so the question would be: Does using the formula in section 4.2 instead of the formula in section 3.2.2 introduce vulnerabilities when the packet is encrypted, as the timestamp value will be influenced by changes in the clock rate? Note that the algorithm does not change the fact that the RTP timestamp is initialized with a random offset. Honestly, IANAC, so I do not know. My intuition would be no, but intuitions are rarely right in security, so would just adding some text saying that we do not know be acceptable in the security section? (see proposed text below). >> >> Since timestamps and SSRC manipulation are weaknesses of the encryption >> approach in RFC 3550, section 9.1, I would expect more discussion of the >> potential impact, or non-impact, of these changes to SSRCs and >> timestamps vis-à-vis the encryption strength. >> OLD TEXT: This document is not believed to effect the security of the RTP sessions described here in any way. NEW TEXT: When the algorithm described in section 4.1 is used the security considerations described in RFC 3550 applies. The algorithm described in section 4.2 is new and so its security properties were not considered in RFC 3550. Although the RTP timestamp is initialized with a random value like before, the timestamp value depends on the current and previous clock rates and this may or may not introduce a security vulnerability in the protocol. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSjMJEAAoJECnERZXWan7EngMQAKAI8zah36BThpBTFpZNKBX6 vtl+l6J51Agj8/kE7PlPFjhPipysOle5AeWyazeMjO4q53Zpxb6tXEoYtaAxIYS/ yIFhSMUgoGLADUFkX1bkRvZHZi5Lt1//rabDggllxdkd/d7ueHSwvXYs40T9AgR6 F4D7nyFE7NqmCN0KpfIA12L+6T5qrVqvQWh7UxI09R+R5XfSEYRy8zqQ3j+hMI8j Tqtmf9yFQIRYje07dUF7BDN0wBesrh5j5pEwV7VKzX9q7OQ/ZElFZqbkARLw8zBg UpZNsQjObV7PjyMVaH9fzPw2xRVZ6KSdRUWy7vrJussfnLTU+JiNQIVIFgsgdxtq MEtMpSxqDIb+rrghah/GlrIQvzYx7pX8+UhUM6J+kcsky8vTdl4Z+EE4ykVXfWud VS2rnTLsekNZuYaHuHyP8xq3s9BByS+V4fXChImnR8vNppJFcbx7bAXgykIERyqI xCkQtoJAmvgCDO6WJthTHB4GDGcoFc6665cohNDyUa3JQ0grMw7SHE7qfxiY7TKl PPE7wIJaDSKaLh6UF+v9uaatEyUJ5otyVW6QOQ53w1va0dUWuscirFSCRp2Mc5pu XhIGby/llsYqWGRHQbO015/k7CntjlKtWVgGddpuaimrP6SWLKSKN1dWR2MDNoA/ eQh/BMRYM5lmHIRFNe9t =b7RB -----END PGP SIGNATURE----- From repenno@cisco.com Thu Nov 21 02:59:30 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 C830C1AD944 for ; Thu, 21 Nov 2013 02:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.025 X-Spam-Level: X-Spam-Status: No, score=-15.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, 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 1trYSZk0duBu for ; Thu, 21 Nov 2013 02:59:28 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 334351AD958 for ; Thu, 21 Nov 2013 02:59:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16554; q=dns/txt; s=iport; t=1385031562; x=1386241162; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Qar0PZnxaSaVrPxNEsgP7uPQ6kOaoe46sEPKborSYfg=; b=HYdCLgWTzhmKLdC8U8Qd3lGfWE2+Af3t/+FimODmnK8du5bmHPlngbLJ 0BAIeh3hCINqLCpmUvIvWc+BZprAqzTWqVVTzAaXwBxfrl8GpNCGZXz0L ajb0whUujWW0yQC52/+Y2kiCLf4kGI27PkC5RIqlaWQD0sl6SsDCrZlz6 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMGAEPnjVKtJV2Y/2dsb2JhbABZgkNEOEgLqkyJZYhLgR8WdIIlAQIEeRIBCBEDAQIoKBEUCQgCBAENBYdvAw8NuB8NiEWMcoJoDQQHCYQpA5YngWuBMIsohTiDKIIq X-IronPort-AV: E=Sophos;i="4.93,743,1378857600"; d="scan'208,217";a="286593741" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 21 Nov 2013 10:59:20 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rALAxK2b011222 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Nov 2013 10:59:20 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.192]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Thu, 21 Nov 2013 04:59:19 -0600 From: "Reinaldo Penno (repenno)" To: "Reinaldo Penno (repenno)" , Phillip Hallam-Baker Thread-Topic: SECDIR Review of draft-ietf-pcp-description-option-02 Thread-Index: AQHO4Z2d3yMYBDQllE2JVi50kvlW4ZolkGiAgAIF+oCAALkuAIAHHSGA Date: Thu, 21 Nov 2013 10:59:19 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.99.182] Content-Type: multipart/alternative; boundary="_000_CEB327786752repennociscocom_" MIME-Version: 1.0 Cc: "draft-ietf-pcp-description-option@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR Review of draft-ietf-pcp-description-option-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, 21 Nov 2013 10:59:31 -0000 --_000_CEB327786752repennociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =85Crickets.. From: Cisco Employee > Date: Saturday, November 16, 2013 at 2:23 PM To: Phillip Hallam-Baker > Cc: "secdir@ietf.org" >, "draft-ietf-pcp-description-option@tools.ietf.org" > Subject: Re: SECDIR Review of draft-ietf-pcp-description-option-02 Resent-From: > Resent-To: >, "mohamed.boucadair@or= ange.com" >, Cisco Employee > Resent-Date: Saturday, November 16, 2013 at 2:24 PM From: Phillip Hallam-Baker > Date: Friday, November 15, 2013 7:18 PM To: Cisco Employee > Cc: "secdir@ietf.org" >, "draft-ietf-pcp-description-option@tools.ietf.org" > Subject: Re: SECDIR Review of draft-ietf-pcp-description-option-02 On Thu, Nov 14, 2013 at 11:24 PM, Reinaldo Penno (repenno) > wrote: Hello Phillip, Thanks for the review. Inline with [RP] From: Phillip Hallam-Baker > Date: Thursday, November 14, 2013 4:56 PM To: "secdir@ietf.org" >, "draft-ietf-pcp-description-option@tools.ietf.org" > Subject: SECDIR Review of draft-ietf-pcp-description-option-02 Resent-From: > Resent-To: >, "mohamed.boucadair@or= ange.com" >, Cisco Employee > Resent-Date: Thursday, November 14, 2013 4:57 PM 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 adds a 'description' option to the PCP protocol. The descripti= on does not have defined semantics in PCP. As such the Security Considerati= ons relies on the considerations in the PCP specification. This seems ill advised to me. Even though the field has no semantics in PCP= it is essentially the equivalent of a TXT RR in the DNS, possibly the most= over-used and abused RR in the DNS protocol. If the description option is added then people are going to start using it = to define site local semantics unless there is some other mechanism for tha= t purpose. [RP] Different from DNS a PCP client can not query the description of its m= appings. Can you give me an example of such site local semantics so I can = understand better your concern? I found this: https://support.google.com/a/answer/2716800?hl=3Den But it relies on the fact that DNS clients can query such information. I suggest that the draft authors either add a description of how to use the= PCP mechanisms for this purpose (if applicable) or describe a mechanism to= support this use and preferably providing some sort of protection against = collisions. Such a mechanism needs to consider the authenticity of the data provided an= d the risk that it might disclose data to another application. I presume that the reason that information is being fed into this system is= that it is expected that there will be parties that read it out. [RP2] Yes, an admin can see the description associated with each mapping fo= r troubleshooting purposes. Those may not be PCP clients but it is surely not the empty set or what wou= ld be the point of the feature? If you provide a communication channel between two pieces of apparatus whic= h has no defined function then expect it to be used in lots of unexpected w= ays. [RP2] I see it as a troubleshooting tool for admins since client knows its = own description or can override if it wants. -- Website: http://hallambaker.com/ --_000_CEB327786752repennociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
=85Crickets..

From: Cisco Employee <repenno@cisco.com>
Date: Saturday, November 16, 2013 a= t 2:23 PM
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: "secdir@ietf.org" <= secdir@ietf.org>, "draft-ietf-pcp-description-option@tools.ietf.org" <dr= aft-ietf-pcp-description-option@tools.ietf.org>
Subject: Re: SECDIR Review of draft= -ietf-pcp-description-option-02
Resent-From: <draft-alias-bounces@tools.ietf.org&= gt;
Resent-To: <dwing@cisco.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Cisco Employee <repenno@cisco.com<= /a>>
Resent-Date: Saturday, November 16,= 2013 at 2:24 PM



From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Friday, November 15, 2013 7:1= 8 PM
To: Cisco Employee <repenno@cisco.com>
Cc: "secdir@ietf.org" <= secdir@ietf.org>, "draft-ietf-pcp-description-option@tools.ietf.org" <dr= aft-ietf-pcp-description-option@tools.ietf.org>
Subject: Re: SECDIR Review of draft= -ietf-pcp-description-option-02




On Thu, Nov 14, 2013 at 11:24 PM, Reinaldo Penno= (repenno) <repenno@cisco.com> wrote:
Hello Phillip,

Thanks for the review. Inline with [RP]

From: Phillip Hallam-Baker <hallam@gmail.com><= br> Date: Thursday, November 14, 2013 4= :56 PM
To: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-pcp-description-option@tools.ietf.org" <draft-ietf-pcp-description-option@tools.ietf.org> Subject: SECDIR Review of draft-iet= f-pcp-description-option-02
Resent-From: <draft-alias-bounces@t= ools.ietf.org>
Resent-To: <dwing@cisco.com>, "mohamed.boucadair@or= ange.com" <mohamed.boucadair@orange.com>, Cisco Employee <= repenno@cisco.com>
Resent-Date: Thursday, November 14,= 2013 4:57 PM

  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 adds a 'description' opti= on to the PCP protocol. The description does not have defined semantics in = PCP. As such the Security Considerations relies on the considerations in th= e PCP specification.

This seems ill advised to me. Even tho= ugh the field has no semantics in PCP it is essentially the equivalent of a= TXT RR in the DNS, possibly the most over-used and abused RR in the DNS pr= otocol.

If the description option is added the= n people are going to start using it to define site local semantics unless = there is some other mechanism for that purpose.

[RP] Different from DNS a PCP client can not query the description of = its mappings.  Can you give me an example of such site local semantics= so I can understand better your concern?  I found this:


But it relies on the fact that DNS clients can query such information.=  

I suggest that the draft authors eithe= r add a description of how to use the PCP mechanisms for this purpose (if a= pplicable) or describe a mechanism to support this use and preferably provi= ding some sort of protection against collisions.

Such a mechanism needs to consider the authenticity of the data provid= ed and the risk that it might disclose data to another application.


I presume that the reason that information is being fed into this syst= em is that it is expected that there will be parties that read it out.

[RP2] Yes, an admin can see the description associated with each mappi= ng for troubleshooting purposes. 

Those may not be PCP clients but it is surely not the empty set or wha= t would be the point of the feature?

If you provide a communication channel between two pieces of apparatus= which has no defined function then expect it to be used in lots of unexpec= ted ways.

[RP2] I see it as a troubleshooting tool for admins since client knows= its own description or can override if it wants.
--_000_CEB327786752repennociscocom_-- From kivinen@iki.fi Thu Nov 21 04:27: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 EA6BF1ADEBF; Thu, 21 Nov 2013 04:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, 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 U0IW-Ae04Tqs; Thu, 21 Nov 2013 04:27:51 -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 618BE1ADEBE; Thu, 21 Nov 2013 04:27:50 -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 rALCRe3L028643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Nov 2013 14:27:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rALCRdcg029876; Thu, 21 Nov 2013 14:27:39 +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: <21133.64571.158642.421795@fireball.kivinen.iki.fi> Date: Thu, 21 Nov 2013 14:27:39 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-roll-trickle-mcast.all@tools.ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 6 min Subject: [secdir] Secdir review of draft-ietf-roll-trickle-mcast-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: Thu, 21 Nov 2013 12:27:54 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes the Multicast protocol for Low and Lossy Networks. This protocol uses trickle algorithm. I am not familiar enough to trickle to really analyze what the protocol does. Security considerations section mentions that the protocol uses sequence numbers to keep track of messages, and attacker who can insert messages can mess up with those sequence numbers, and attacker can then flush messages from the buffered messages list, and can also allow setting it high enough so recipients will not get any messages as they have too small sequence number. The protocol has no protection against this attack, but notes that both of those are denial-of-service attacks and devices can protect against them by using link-layer security mechanisms. It also claims that those mechanisms are typically employed without specifying which security methods it is pointing to. I do not know how often those link-layer security methods are really used. Perhaps it would be useful to list some of those security methods here. I do not have any other comments for the protocol, and otherwise I think the document is ready, but as I said I did not have time to really analyze the protocol itself. -- kivinen@iki.fi From kivinen@iki.fi Thu Nov 21 05:15: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 A7E8A1ADF6A for ; Thu, 21 Nov 2013 05:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, 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 Qe8vgMT9vgsQ for ; Thu, 21 Nov 2013 05:15:44 -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 8A1811ADC03 for ; Thu, 21 Nov 2013 05:15:43 -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 rALDFY5K028565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 21 Nov 2013 15:15:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rALDFYPK028217; Thu, 21 Nov 2013 15:15:34 +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: <21134.1909.980928.245465@fireball.kivinen.iki.fi> Date: Thu, 21 Nov 2013 15:15:33 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 3 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, 21 Nov 2013 13:15:45 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Jeffrey Hutzelman is next in the rotation. For telechat 2013-11-21 Reviewer LC end Draft Chris Lonvick TR2013-10-25 draft-ietf-mmusic-rfc2326bis-38 Sandy Murphy T 2013-10-31 draft-ietf-netext-pd-pmip-12 Joe Salowey TR2013-09-23 draft-ietf-sidr-bgpsec-threats-07 Yaron Sheffer TR2013-08-16 draft-ietf-tls-oob-pubkey-10 David Waltermire T 2013-09-30 draft-ietf-opsec-ip-options-filtering-05 For telechat 2013-12-05 Shawn Emery T 2013-11-26 draft-ietf-cdni-requirements-12 Tobias Gondrom T 2013-11-25 draft-ietf-json-rfc4627bis-07 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 Matt Lepinski T 2013-11-04 draft-ietf-httpbis-p2-semantics-25 Klaas Wierenga TR2013-11-04 draft-ietf-httpbis-p4-conditional-25 Last calls and special requests: Derek Atkins 2013-11-27 draft-ietf-xrblock-rtcp-xr-qoe-12 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 Dave Cridland 2013-11-28 draft-leiba-smime-type-registry-02 Donald Eastlake 2013-11-19 draft-ietf-soc-load-control-event-package-10 Steve Hanna E 2013-11-28 draft-ietf-pcp-nat64-prefix64-04 Dan Harkins 2013-11-26 draft-ietf-trill-oam-framework-03 David Harrington 2013-11-28 draft-ietf-6man-ug-05 Sam Hartman 2013-12-02 draft-ietf-bfd-on-lags-02 Paul Hoffman E 2013-11-28 draft-ietf-v6ops-balanced-ipv6-security-00 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05 Julien Laganier E 2013-11-21 draft-ietf-avtcore-rtp-security-options-09 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-08 Julien Laganier 2013-11-06 draft-ietf-forces-ceha-09 Alexey Melnikov E 2013-11-21 draft-ietf-payload-rtp-howto-09 Vincent Roca 2013-04-26 draft-ietf-6man-stable-privacy-addresses-14 Joe Salowey 2013-11-27 draft-ietf-clue-telepresence-requirements-06 Yaron Sheffer 2013-11-27 draft-ietf-idr-extcomm-iana-01 Ondrej Sury 2013-11-18 draft-ietf-l2vpn-etree-reqt-05 Tina TSOU 2013-11-27 draft-ietf-l2vpn-evpn-req-05 Carl Wallace 2013-11-27 draft-ietf-mmusic-sdp-g723-g729-04 Brian Weis 2013-11-26 draft-ietf-ospf-rfc6506bis-02 Klaas Wierenga 2013-11-27 draft-ietf-pwe3-dynamic-ms-pw-19 Tom Yu 2013-11-27 draft-ietf-sidr-rpki-rtr-impl-04 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 Glen Zorn 2013-11-27 draft-turner-ct-keypackage-receipt-n-error-algs-03 -- kivinen@iki.fi From dbharrington@comcast.net Fri Nov 22 11:05: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 6A0771AE21E for ; Fri, 22 Nov 2013 11:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.525, 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 bDCtL5vrAEy2 for ; Fri, 22 Nov 2013 11:05:14 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1C71AE086 for ; Fri, 22 Nov 2013 11:05:14 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta03.westchester.pa.mail.comcast.net with comcast id siWL1m00927AodY53j57hL; Fri, 22 Nov 2013 19:05:07 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta19.westchester.pa.mail.comcast.net with comcast id sj571m0072yZEBF3fj576B; Fri, 22 Nov 2013 19:05:07 +0000 From: "David Harrington" To: , , Date: Fri, 22 Nov 2013 14:05:10 -0500 Message-ID: <000001cee7b5$c41cc640$4c5652c0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7ntRpR8+feNhrqQDqlEMCCOP1l0g== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1385147107; bh=+NRxPa6gptlltrsV1rP5sXdI/hVfwWMzxcifMGxf4J0=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=P4zK0a8yQyXmK4BNQ8dp6ciiFASVK4cLRQbTBXsurjZPCMZ3H2Vuy5dBFkOUFk8a0 5e4fLt3yTH+H5A2J+OKTueCIDuJUlwGI/b0FATMqjUenshw3sLqaUB8J4PxJsd1d9T 8Ql04o7JA5fLUcnOpFKaTXK0zn+luqtZza1g/nimt/Oti9+yNSQksrbXWsxW1fK37r O6GvWZqdqBFE1HhNsGcCDzKHZ2xtdAd/r7Mm6dG6DGJ7iGfoHCJCFq/jb0vNuhGpmI wnlwopkS383ooKhOfZ4rPHOEH2hV2biym/0OVV2xq7E2eG6y+wOOsld9lf+uPFfk6M MdnX4QKYRjGoQ== Subject: [secdir] secdir review of draft-ietf-6man-ug-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: Fri, 22 Nov 2013 19:05: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 IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses. Interface identifiers are formed by a variety of methods. This document clarifies that the bits in an interface identifier have no meaning and that the entire identifier should be treated as an opaque value. In particular, RFC 4291 defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier. This document clarifies that those two bits are significant only in the process of deriving interface identifiers from an IEEE link-layer address, and updates RFC 4291 accordingly. The document states "No new security exposures or issues are raised by this document." In my opinion, this is accurate. David Harrington dbharrington@comcast.net +1-603-828-1401 From derek@ihtfp.com Sun Nov 24 18:02: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 6BBCC1AE277; Sun, 24 Nov 2013 18:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 N3pbcA9mSSbI; Sun, 24 Nov 2013 18:01:52 -0800 (PST) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id 949321AE1BF; Sun, 24 Nov 2013 18:01:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 6B8AF260211; Sun, 24 Nov 2013 21:01:48 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 19002-10; Sun, 24 Nov 2013 21:01:47 -0500 (EST) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id DA9A92600B4; Sun, 24 Nov 2013 21:01:46 -0500 (EST) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.7/Submit) id rAP21ihI005655; Sun, 24 Nov 2013 21:01:44 -0500 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Sun, 24 Nov 2013 21:01:44 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: Roland.Schott@telekom.de, sunseawq@huawei.com, alan.d.clark@telchemy.com, xrblock-chairs@tools.ihtfp.org, gwz@net-zen.net Subject: [secdir] sec-dir review of draft-ietf-xrblock-rtcp-xr-qoe-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 02:02:05 -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 defines an RTP Control Protocol (RTCP) Extended Report (XR) Block including two new segment types and associated SDP parameters that allow the reporting of MOS Metrics for use in a range of RTP applications. I see no security concerns with this document. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From paul.hoffman@vpnc.org Sun Nov 24 18:09: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 B0D281AE399; Sun, 24 Nov 2013 18:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[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 TI1Www8T34pd; Sun, 24 Nov 2013 18:09:55 -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 55CAB1AE2D9; Sun, 24 Nov 2013 18:09:55 -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 rAP29rDj046069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 24 Nov 2013 19:09:54 -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] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Nov 2013 18:09:51 -0800 Message-Id: <95E90374-1EC4-4AFB-99E1-C24653BE8EA3@vpnc.org> To: secdir Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Cc: v6ops@ietf.org Subject: [secdir] SecDir and WG LC review of draft-ietf-v6ops-balanced-ipv6-security X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 02:09:56 -0000 Greetings. The v6ops chairs apparently asked for an early (pre-IETF-LC) = review of draft-ietf-v6ops-balanced-ipv6-security, "Balanced Security = for IPv6 Residential CPE" which is in WG LC. In short: from a security = standpoint, the document seems fine if you are of the same point of view = as the authors, and terrible if you are not. Neither point of view is = better than the other, so this review will probably not make anyone = happy. The topic of the document is what the initial firewall configuration for = an IPv6 residential gateway should be. It is based on actual deployment = experiences from an ISP. The view of the authors of the document is, = approximately, "IPv6 lets us re-enable the end-to-end principle, so make = that the default for home gateways, modulo closing a couple of = long-standing vulnerabilities". The opposing camp is "end hosts in the = home often have terrible security, so you need to prevent initial = contact from the Internet", with a subset of that group saying "but let = those hosts do PCP to open holes". The IPv6 aspect of the argument seems = to be mostly lost in the noise of the WG LC comments, even though it is = the lead for the draft itself. Calling this draft "Balanced" is kind of like titling a security = protocol with "Simple" (something that I am guilty of...). Please = consider changing the title to something more representative of the = discussion, such as "Permissive" or "Open". =46rom a security standpoint, the document seems self-consistent in its = stance (and certainly more than RFC 6092 was). The list of threats in = section 2 has a few problems, however: - Most of the bullet points are about incoming threats, but then the = last bullet talks about an outgoing threat, and not very well at that. = Either the list should be broken into two and my more outgoing threats = listed, or the last bullet should be removed. - The list doesn't include denial of service from the outside that = exhausts stateful tables in the CPE itself. Give that what is being = described is small-footprint firewalls, this seems like a great attack = that could cause some interesting failure modes. - The example of vulnerable hosts being "old versions of Windows" is out = of place. New versions of all operating systems that live in the home, = and even the CPE itself, are often vulnerable. Given the large amount of discussion from the "closed, open it with PCP" = folks, it is odd that PCP isn't mentioned at all in Section 3, even for = the services that are initially blocked such as HTTP. Given the number = of HTTP-based devices out there that someone might want to control from = outside the home, this seems like a major oversight. The AllowManagement rule in Section 3.1 mentions Broadband Forum TR-69 = as if it is done either at layer 2 or using some non-IP protocol at = layer 3. This should be described in a bit more detail, and that should = be an informative reference. The paragraph after Table 2 makes it seem like doing firmware updates = and policy updates to a CPE are equivalent. =46rom a security = standpoint, that's a terrible comparison. Updating firmware can = introduce many more security issues than updating a policy table. Please = consider removing the firmware option. The last paragraph of Section 3.2 has sexist bullshit in it. I guess I = should give you points for not making it racist too, but still. --Paul Hoffman= From alexey.melnikov@isode.com Mon Nov 25 07:06:02 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 13D461ADEDC for ; Mon, 25 Nov 2013 07:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 iqJc70xy4Kin for ; Mon, 25 Nov 2013 07:06:00 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id E75AD1ADEBE for ; Mon, 25 Nov 2013 07:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1385391959; d=isode.com; s=selector; i=@isode.com; bh=c1SzDHf39F+tC6lby61QgvhQCN6qZFJt2BIRYowHRr4=; 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=CzO9AHB8Cjx3UUM527DR5YSaqYoGgKoPRte/hfw6vn13RI8D3UpA/EOWIPO+2HiLeu32ZB evf5cSjwvPssuSveAFrnawz9zpoOXY69bApDJskfC0Ael05uRSPs7nlUFAlDPMaHGOvUum 2Plz3xeOXevttu0u0thhUZs65cX1WmA=; Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 25 Nov 2013 15:05:59 +0000 Message-ID: <52936755.1020204@isode.com> Date: Mon, 25 Nov 2013 15:05:57 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: IETF Security Directorate , draft-ietf-payload-rtp-howto.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir review of draft-ietf-payload-rtp-howto-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: Mon, 25 Nov 2013 15:06:02 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document contains information on how to best write an RTP payload format specification. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions. The Security Considerations section of the document points out that while the document doesn't have direct security considerations, it contains suggestions about what security considerations should be thought about when writing a new RTP payload format. I found these suggestions (last two paragraphs of Section 3.2.2, Section 6.1 and Section 7.2) to be quite complete/good. So I think the document is ready for publication. From new-work-bounces@ietf.org Fri Nov 22 09:19:35 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 5F1A91AE06B; Fri, 22 Nov 2013 09:19:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1385140775; bh=CrVTF7iBTgT6+9K9HDan9XY4JIZZqBPwhIfUqzB1AyQ=; 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=BsGm5WKF5Tk4DD9Cmt58AjMe2dbFF16WtDfSHgUnl/YbRj0bWR+4Ht1QdjbcajivX 9GEyC4/QWwN0rckfkuSdN0NdJmht6Nj7Im0qHhveuZ5R954gckabxVhHRzszKRqRLG CKvarw/D1x5UZrHj1cw4Fn3+DnU6vxNFHwhBh4qE= 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 B0B9C1AE047; Fri, 22 Nov 2013 09:19:31 -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 BuDIbXL8eWtP; Fri, 22 Nov 2013 09:19:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 425AD1AE177; Fri, 22 Nov 2013 09:19:29 -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: <20131122171929.16611.62104.idtracker@ietfa.amsl.com> Date: Fri, 22 Nov 2013 09:19:29 -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: Mon, 25 Nov 2013 08:03:38 -0800 Subject: [secdir] [new-work] WG Review: Extensible Provisioning Protocol Extensions (eppext) 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, 22 Nov 2013 17:19:35 -0000 A new IETF working group has been proposed in the Applications 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-02. Extensible Provisioning Protocol Extensions (eppext) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Pete Resnick Charter: The Extensible Provisioning Protocol (EPP) was a work product of the IETF Provisioning Registry Protocol (provreg) working group. EPP was published as a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March 2004. It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934) in May 2007, and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733, and 5734) in August 2009. It is the standard domain name provisioning protocol for generic top-level domain name registries that operate under the auspices of the Internet Corporation for Assigned Names and Numbers (ICANN). It is also used by a number of country code top-level domain registries. Domain name registries implement a variety of business models. The difference in these models made it very difficult to come up with a "one size fits all" provisioning protocol, so the provreg working group made a conscious decision to focus on a minimal set of common functionality. EPP was designed to be extensible to allow additional features to be specified on an "as needed" basis. Guidelines for extending EPP were published as Informational RFC 3735 in March 2004. The provreg working group was chartered to develop EPP, but not these additional extensions. The working group was closed in 2004 after producing a number of Proposed Standard specifications. As registries began to implement and deploy EPP the need for extensions became real, and the user community found itself facing a situation in which multiple extensions were being developed by different registries to solve the same basic problems, such as registering additional contact information. EPP is widely implemented by generic top-level domain name registry operators. It is also used by multiple country-code top-level domain name registry operators. The Internet Corporation for Assigned Names and Numbers (ICANN) has an active program to delegate a large number of new generic top-level domains. EPP will be used to provision those domains, and new registry operators are expected to develop additional protocol extensions. With no way to coordinate the development of these extensions, the problem of non-standard extension duplication by multiple operators is only expected to become worse. The goal of the EPP Extensions (eppext) working group is to create an IANA registry of EPP extensions and to review specifications of extensions for inclusion in the registry. It will accomplish this goal in two steps: 1. Develop a specification for a registry of and corresponding registration procedures for EPP extensions. One proposal is documented in https://datatracker.ietf.org/doc/draft-hollenbeck-epp-ext-reg/. 2. Produce a small number of extensions based on existing Internet Draft documents and use the IANA registration process as developed in 1 to register those extensions, as follows: DNSSEC key relay: draft-gieben-epp-keyrelay (http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/) Internationalized domain names: draft-obispo-epp-idn (http://datatracker.ietf.org/doc/draft-obispo-epp-idn/) New TLD launch phases: draft-tan-epp-launchphase (http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/) Trademark Clearinghouse: draft-lozano-tmch-smd (https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/) Note: draft-tan-epp-launchphase has a normative dependency on draft-lozano-tmch-smd. Only the development of the registration process and the publication/registration of the four extensions noted above are in scope for the working group. The working group can choose not to publish or register one or more of the extensions noted above, but it is out of scope to work on other extensions. Milestones: May 2014 - Extensions registry document to IESG Jul 2014 - DNSSEC key relay extension to IESG Jul 2014 - New TLD launch phases extension to IESG Sep 2014 - Internationalized domain names extension to IESG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Fri Nov 22 09:31:27 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 E389D1AE06B; Fri, 22 Nov 2013 09:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1385141486; bh=To4c4QiVLgrBDxLvq4DCUTgn6ngMlDeo85JHK7lyCN4=; 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=YUnadENe50lSAarmKH6d5JDUN13iUN1BthBuDV2qnG6bgEbgJFyqdmyh7TeVY/+Fd iGoPp6Vu8/Ib/efF+LIs7M4ObhbqIFhXIDA/YKkvDNd76JYkLku/iR5TwFZ1vaKEaI sKo0TNgMN3qwmd4UjJH6AL9vEigJOWqcNJy/u5IU= 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 2B1AC1AE201; Fri, 22 Nov 2013 09:31: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=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 pxoRitg9XnUB; Fri, 22 Nov 2013 09:31:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F02D1AE013; Fri, 22 Nov 2013 09:31:23 -0800 (PST) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131122173123.16611.42709.idtracker@ietfa.amsl.com> Date: Fri, 22 Nov 2013 09:31: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: Mon, 25 Nov 2013 08:03:38 -0800 Subject: [secdir] [new-work] WG Review: Emergency Context Resolution with Internet Technologies (ecrit) 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, 22 Nov 2013 17:31:27 -0000 The Emergency Context Resolution with Internet Technologies (ecrit) working group in the Real-time Applications and Infrastructure Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-12-02. Emergency Context Resolution with Internet Technologies (ecrit) ------------------------------------------------ Current Status: Active WG Chairs: Marc Linsner Roger Marshall Assigned Area Director: Richard Barnes Mailing list Address: ecrit@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ecrit Archive: http://www.ietf.org/mail-archive/web/ecrit/ Charter: In a number of areas, the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (usually one that is short and easily memorized) as a request for emergency services. These numbers (e.g., 911, 112) are related to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained approach for service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires an association of both the physical location of the originating device along with appropriate call routing to an emergency service center. Calls placed using Internet technologies do not use the same systems mentioned above to achieve those same goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting these goals even more challenging. There are, however, Internet technologies available to manage location and to perform call routing. This working group has described where and how these mechanisms may be used. The group specified how location data and call routing information are used to enable communication between a user and a relevant emergency response center [RFC6443,RFC6444]. Though the term "call routing" is used, it should be understood that some of the mechanisms described might be used to enable other types of media streams. Beyond human initiated emergency call request mechanisms, this group will develop new methods to enable non-human-initiated requests for emergency assistance, such as sensor initiated emergency requests. The working group will also address topics required for the operation of emergency calling systems, such as: authentication of location, management of the service URN namespace, augmented information that could assist emergency call takers or responders. Explicitly outside the scope of this group is the question of pre- emption or prioritization of emergency services traffic in the network. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. While this group anticipates a close working relationship with groups such as NENA, EENA, 3GPP, and ETSI , any solution presented must be general enough to be potentially useful in or across multiple regions or jurisdictions, and it must be possible to use without requiring a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, things such as call routing for specific emergency types, media types, language contents, etc., may be routed differently depending on established policies and availability. This working group will address privacy and security concerns within its documents. Milestones: Done - Informational RFC containing terminology definitions and the requirements Done - An Informational document describing the threats and security considerations Done - A Standards Track RFC describing how to identify a session set-up request is to an emergency response center Done - A Standards Track RFC describing how to route an emergency call based on location information Done - An Informational document describing the Mapping Protocol Architecture Done - Submit 'Location Hiding: Problem Statement and Requirements' to the IESG for consideration as an Informational RFC. Done - Submit 'Framework for Emergency Calling using Internet Multimedia' to the IESG for consideration as an Informational RFC. Done - Submit 'Best Current Practice for Communications Services in support of Emergency Calling' to the IESG for consideration as a BCP document Done - Submit 'LoST Extension for returning Boundary Information for Services' to the IESG for consideration as an Experimental RFC Done - Submit 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' to the IESG for consideration as an Experimental RFC Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG for consideration as an Informational RFC Done - Submit 'Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration as a Standards Track RFC Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an Experimental RFC Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for consideration as an Informational RFC Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC Dec 2013 - Submit a draft 'Policy for defining new service-identifying labels' to the IESG for consideration as BCP Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services' to the IESG for consideration as a Standards Track RFC Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing' to the IESG for consideration as an Informational RFC _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Fri Nov 22 09:36:26 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 31B381AE39A; Fri, 22 Nov 2013 09:36:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1385141786; bh=RNCxeyirWSRKCgugSLdobjHv1O3AROVaiBOmFJPfRrU=; 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=X5U+qcuI6Z0wCQnTDWb1mDxurjS3CO+hSdIzPAKp1KtQNrTttvLRAylDCqWO/TcJL IK7SzR641d0Rvcb+x37Y8gWXC0rDLJYyxLbDL9ECJkd65gfTG7/4OM1UdEFPpCjFV6 Wlv1WlNZi5vDgFK2weHTu8T1Dhoev2yX6Zi1QZgg= 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 ADDBB1AE3B6; Fri, 22 Nov 2013 09:36:24 -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 k9q9BkFWiuu9; Fri, 22 Nov 2013 09:36:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8BD1AE1EE; Fri, 22 Nov 2013 09:36:22 -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: <20131122173622.16611.65213.idtracker@ietfa.amsl.com> Date: Fri, 22 Nov 2013 09:36:22 -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: Mon, 25 Nov 2013 08:03:39 -0800 Subject: [secdir] [new-work] WG Review: Using TLS in Applications (uta) 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, 22 Nov 2013 17:36:26 -0000 A new IETF working group has been proposed in the Applications 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-02. Using TLS in Applications (uta) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Barry Leiba Charter: There is a renewed and urgent interest in the IETF to increase the security of transmissions over the Internet. Many application protocols have defined methods for using TLS to authenticate the server (and sometimes the client), and to encrypt the connection between the client and server. However, there is a diversity of definitions and requirements, and that diversity has caused confusion for application developers and also has led to lack of interoperability or lack of deployment. Implementers and deployers are faced with multiple security issues in real-world usage of TLS, which currently does not preclude insecure ciphers and modes of operation. This WG has the following tasks: - Update the definitions for using TLS over a set of representative application protocols. This includes communication with proxies, between servers, and between peers, where appropriate, in addition to client/server communication. - Specify a set of best practices for TLS clients and servers, including but not limited to recommended versions of TLS, using forward secrecy, and one or more ciphersuites and extensions that are mandatory to implement. - Consider, and possibly define, a standard way for an application client and server to use unauthenticated encryption through TLS when server and/or client authentication cannot be achieved. - Create a document that helps application protocol developers use TLS in future application definitions. The initial set of representative application protocols is SMTP, POP, IMAP, XMPP, and HTTP 1.1. It is expected that other protocols that use TLS might later be updated using the guidelines from this WG, and that those updates will happen through other WGs or through individual submissions. The WG will make the fewest changes needed to achieve good interoperable security for the applications using TLS. No changes to TLS itself will be made in this WG, and the WG will ensure that changes to current versions of popular TLS libaries will not be required to conform to the WG's specifications. This WG will collaborate with other IETF WGs, in particular with the TLS and DANE WGs. Milestones: _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Fri Nov 22 10:12:37 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 876E31AE171; Fri, 22 Nov 2013 10:12:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1385143957; bh=vBm5uwmlLcpeT1H+Hb0vDe5cDYco5q90/UcqwjpraQs=; 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=doDSeEAhBDhCgzuY9mRQE7fbDxZ0NJEWYynnyuwH4z8or35A+Mm2clzGEBWFDN53l C8a2Jm6saN81+Y0AIOySOP4zntD4jbaX+Jndr/noAjohc/ySuM2LCr7eZy4Lq9N6as opGnHCzr/44GObEoRsEk/VKyZEnKFmHFQgvtkMo0= 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 C88A91AE19F; Fri, 22 Nov 2013 10:12:35 -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 s477Bh2Ifibp; Fri, 22 Nov 2013 10:12:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9B71AE171; Fri, 22 Nov 2013 10:12:33 -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: <20131122181233.16611.44151.idtracker@ietfa.amsl.com> Date: Fri, 22 Nov 2013 10:12:33 -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: Mon, 25 Nov 2013 08:03:40 -0800 Subject: [secdir] [new-work] WG Review: Content Delivery Networks Interconnection (cdni) 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, 22 Nov 2013 18:12:37 -0000 The Content Delivery Networks Interconnection (cdni) working group in the Transport 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-02. Content Delivery Networks Interconnection (cdni) ------------------------------------------------ Current Status: Active WG Chairs: Daryl Malas Francois Le Faucheur Assigned Area Director: Spencer Dawkins Mailing list Address: cdni@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cdni Archive: http://www.ietf.org/mail-archive/web/cdni/ Charter: A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content. Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs). CDNs provide numerous benefits: a shared platform for multi-service content delivery, reduced transmission costs for cacheable content, improved quality of experience for end users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery. As a result of the significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure and many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Subject to the policy of the CSP, it is generally desirable that a given item of content can be delivered to an end user regardless of that end user's location or attachment network. This creates a need for interconnecting (previously) standalone CDNs so they can interoperate and collectively behave as a single delivery infrastructure. The goal of the CDNI Working Group is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (via their respective User Agents). The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe as needed by the industry. It is expected that the CDNI interfaces will be realized using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics. In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter. The working group will focus on the following items: - A "requirements" document. This document lists the requirements for the CDNI architecture and the CDNI interfaces. In particular, this document will focus on identifying a reasonable set of more urgent and important requirements that will be addressed in the initial set of CDNI protocols and solutions produced by the working group. This document will list the requirements stemming from the threat analysis and to be met by each of the CDNI interfaces. - A "framework" document providing a description of the different components of the CDNI architecture and how they interact with one another. This document will also include a "threat analysis" discussing the security concerns and threats, the trust model and privacy issues specific to CDNI. - A specification of the "CDNI Request Routing Redirection interface". This interface will allow an upstream CDN Request Routing system to obtain from the downstream CDN the information necessary to perform request redirection. It is actually a logical bundling of two separate but related interfaces: * Footprint & Capability Advertisement interface: Asynchronous operations to exchange routing information (e.g., the network footprint and capabilities served by a given CDN) that enables CDN selection for subsequent user requests; and * Request Routing Redirection interface: Synchronous operations to select a delivery CDN (surrogate) for a given user request. - A specification of the "CDNI Metadata interface". This interface will allow the CDNs to exchange content distribution metadata of inter-CDN scope. Content distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore is to be processed by CDNs (for example, this may include information enabling: content acquisition, geo-blocking, enforcement of availability windows or access control). - A specification of the "CDNI Logging interface". This interface will allow CDN logging systems to exchange logging information associated with actions that are relevant across CDNs (such as content distribution, content delivery and content routing actions) for purposes of accounting, analytics, monitoring, etc. - A specification of the "CDNI Control interface". In particular, this interface will allow an upstream CDN to remove or invalidate content in a downstream CDN. - A specification for "CDNI URI Signing". This document will specify a mechanism that allows interconnected CDNs to support access control by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). The WG will discuss and address the security, management and operational issues specific to CDNI, inside the above documents and specifications. The working group will only define solutions for aspects of the CDN Interconnection problem space that require direct communication or interoperation between CDNs. In particular, the WG will not define: - New session, transport or network protocols. - New protocols for delivering content from a CDN to an End User/User Agent. - New protocols for ingestion of content or metadata between a CSP and a CDN. - New protocols for acquiring content across CDNs. - Protocols and algorithms for intra-CDN operations. - Support for Transparent Caching across CDNs. - New applications consuming CDNI logs. - Digital Right Management (DRM) mechanisms. The CDNI WG will work with other IETF WGs to assess, and where appropriate, leverage protocols developed by those WGs, in order to realize the CDNI requirements and CDNI interfaces. For example, the WG may assess the suitability of the ALTO protocol as a protocol to enable downstream CDNs to exchange information which may aid an upstream CDN with making CDNI request routing decisions. The CDNI WG will also coordinate with relevant groups outside the IETF, if and where appropriate. Milestones: Done - Submit CDNI problem statement to IESG as Informational Done - Submit CDNI use cases to IESG as Informational Sep 2013 - Submit CDNI requirements to IESG as Informational Dec 2013 - Submit CDNI framework to IESG as Informational Dec 2013 - Submit specification of the CDNI Logging interface to IESG as Proposed Standard Dec 2013 - Submit specification of the CDNI Metadata interface to IESG as Proposed Standard Apr 2014 - Submit specification of the CDNI Control interface to IESG as proposed Standard Apr 2014 - Submit specification of the CDNI Request Routing Redirection interface to IESG as Proposed Standard Sep 2014 - Submit specification of the CDNI Footprint & Capabilities Advertisement interface to IESG as Proposed Standard Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Proposed Standard Oct 2014 - Recharter or dissolve _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From gonzalo.camarillo@ericsson.com Tue Nov 26 00:52: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 34AE31A1F3F for ; Tue, 26 Nov 2013 00:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dvkl8OFlcfhX for ; Tue, 26 Nov 2013 00:52:18 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7C21AC4A3 for ; Tue, 26 Nov 2013 00:52:17 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-a0-52946140fba6 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 8D.6D.27941.04164925; Tue, 26 Nov 2013 09:52:16 +0100 (CET) Received: from [147.214.22.133] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.2.328.9; Tue, 26 Nov 2013 09:52:13 +0100 Message-ID: <5294613D.5070003@ericsson.com> Date: Tue, 26 Nov 2013 09:52:13 +0100 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Zongning , Brian Weis References: <6340B78E-38C7-4B25-8CDD-36DC67C49A21@cisco.com> <133F40A5-2425-46C8-A434-A96E83D966C1@cisco.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUyM+Jvra5D4pQgg8tPrC363jayWvy52cdo Mf/tQyaLv+3MFh8WPmSxaLp8itGBzWPK742sHjtn3WX3aDnyltVjyZKfTAEsUVw2Kak5mWWp Rfp2CVwZl18sYSuY7VnxZukjxgbG+9ZdjJwcEgImEmuO/WKDsMUkLtxbD2RzcQgJHGGUWPpj LiuEs4ZRovl2M1MXIwcHr4C2xOsD+SANLAKqEr+272AFsdkELCS23LrPAmKLCkRJnD/3kgnE 5hUQlDg58wlYXETATqLh3ysWkJnMApMYJdYsX8kMkhAWMJPoX7adHWJZI5PE9C9PGEESnAJh Et2TDzODLJYQEJfoaQwCCTML6ElMudrCCGHLS2x/OwdsjhDQbcuftbBMYBSahWT3LCQts5C0 LGBkXsXIUZxanJSbbmSwiREY6Ae3/LbYwXj5r80hRmkOFiVx3o9vnYOEBNITS1KzU1MLUovi i0pzUosPMTJxcEo1MIq8Wpe/9GXQdzFxiZV5/pz/1k0Kr+3OieZ8zckZ+PZFYKHzr/nWBzyW n4sU3J5nZrnq6FeH8Iur5zy4x8d0+lpS1NlTkfNW7p9paGXtfKFGtPnHtEdsUXoO0ll+lxNP Twn42WRa3up18v9ey1kd6+ZdZZ3mvmf9Bf55dql+iRmGRz63rmeUiFdiKc5INNRiLipOBABd UpWIQgIAAA== Cc: Roni Even , 'yunfei zhang' , jiangxingfeng 00215458 , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-p2psip-drr-10 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, 26 Nov 2013 08:52:20 -0000 Hi, this was a secdir review. So, I am adding secdir@ietf.org to the cc: Cheers, Gonzalo On 26/11/2013 9:48 AM, Zongning wrote: > Hi, Brian, > > Just want to check if you are happy with the new revision (http://www.ietf.org/internet-drafts/draft-ietf-p2psip-drr-11.txt), which we believe addressed your original review comments - as below. > > ============================================================== > For the 1st and 2nd comments, we agree that Section 13.6 of the base draft does not provide normative language and we didn't mean to change any of the normative security recommendation of the base draft. Therefore, it maybe good to add the following line "The security recommendations of Section 13 of base draft [] are applicable to this document" in the beginning of the security section of DRR draft since Section 13.2 of the base draft provides the normative language you proposed. > > For the 3rd comment: > [Ning] Section 5.1 provides comparison of the No. of messages between different routing modes. DTLS session is persistent and there maybe cases where other security mechanisms will be used. So, the table compares the different options. > [Ning] Section 5.1 discuss only the routing of the response message. That's why in DRR it goes through one hop. > > For the 4th comment: > [Ning] This flag is about routing state. > > For the 5th comment: > [Ning] This is routing decision in order to verify that the initiator can supply a routable address. > > For the 6th comment: > [Ning] We agree that the line starting with "Instead" doesn't provide any value in this section, then we can delete it. > =============================================================== > > Thanks. > > -Ning > >>> -----Original Message----- >>> From: Brian Weis [mailto:bew@cisco.com] >>> Sent: Tuesday, October 22, 2013 7:04 AM >>> To: Zongning >>> Cc: Roni Even; 'yunfei zhang'; jiangxingfeng 00215458 >>> Subject: Re: Secdir review of draft-ietf-p2psip-drr-10 >>> >>> Hi Ning, >>> >>> Thanks for the note ... I'll look at the new draft and reply soon. >>> >>> Brian >>> >>> On Oct 21, 2013, at 12:47 AM, Zongning wrote: >>> >>>> Hi, Brian, >>>> >>>> Could you please review the updated version to confirm if your >>> comments/suggestions have been appropriately resolved? >>>> >>>> URL: >>> http://www.ietf.org/internet-drafts/draft-ietf-p2psip-drr-11.txt >>>> Status: http://datatracker.ietf.org/doc/draft-ietf-p2psip-drr >>>> Htmlized: http://tools.ietf.org/html/draft-ietf-p2psip-drr-11 >>>> Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-drr-11 >>>> >>>> Thanks, >>>> >>>> -Ning >>>> >>>>> -----Original Message----- >>>>> From: Brian Weis [mailto:bew@cisco.com] >>>>> Sent: Wednesday, October 02, 2013 8:16 AM >>>>> To: secdir@ietf.org; The IESG >>>>> Cc: draft-ietf-p2psip-drr.all@tools.ietf.org >>>>> Subject: Secdir review of draft-ietf-p2psip-drr-10 >>>>> >>>>> [Resent with proper cc] >>>>> >>>>> 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 a routing mechanism for Peer-to-Peer Session >>>>> Initiation Protocol (P2PSIP). The routing mechanism in the base P2PSIP >>> protocol >>>>> specifies an initiator sending a request message hop by hop through a DHT >>> to a >>>>> responder, with the responder returning a reply using the reverse path. >> The >>>>> alternative routing method defined in this I-D describes a shortcut for the >>>>> response message. The response is returned directly to the initiator using >>> an IP >>>>> address provided by the initiator. This shortcut method is described as an >>>>> optimization that is useful in private networks where a self-reported IP >>> address >>>>> is likely to be reliable (i.e., no NAT). >>>>> >>>>> The Security Considerations of this I-D depends entirely upon the Security >>>>> Considerations of the base document (draft-ietf-p2psip-base-26). It should >>>>> probably be expanded to include some more discussion on DRR so that it is >>>>> clear. I have some questions to start a discussion to help understand what >>>>> might need to be added. >>>>> >>>>> 1. The Security Considerations section states >>>>> >>>>> "According to section 13 of the base drat[sic] the forwarding header MUST >>> be >>>>> digitally signed protecting the DRR routing information." >>>>> >>>>> I hope it's actually true that the entire DRR message is signed. If so I >> would >>>>> recommend stating this something like "According to section 13 of the >> base >>>>> draft the entire routing message MUST be digitally signed, including the >>>>> forwarding header that specifies the DRR routing information". >>>>> >>>>> 2. My interpretation reading Section 13 of draft-ietf-p2psip-base-26 is that >>> all >>>>> routing messages must also be protected. For example, Section 13.6.3 in >>> the >>>>> base document says: >>>>> >>>>> "... whenever a peer establishes a direct connection to another peer it >>>>> authenticates via certificate-based mutual authentication. All messages >>>>> between peers are sent over this protected channel and therefore the >> peers >>>>> can verify the data origin of the last hop peer for requests and responses >>>>> without further cryptography." >>>>> >>>>> I don't believe that DRR messages should be any exception, since the DRR >>>>> request messages would be subject to the Eclipse and Sybil attacks >>> described in >>>>> the base document. The Security Considerations section in this I-D does >> not >>> say >>>>> that, even though it makes an effort to point out that the messages are >>>>> digitally signed. This I-D should also say that the messages are sent over a >>>>> protected channel, or else the section needs to have a good justification as >>> to >>>>> why the DRR request messages do not require the same protection as SRR >>>>> messages. I can't think of what that justification would be though! >>>>> >>>>> 3. Table 1 and the preceding paragraph are a little confusing because >>>>> sometimes it says the messages are DTLS protected and sometimes they >>> are >>>>> not. If all of the routing messages are required to be encrypted then I'm >> not >>>>> sure what the point of this comparison. The "No. of Hops" and "No. of >>> Msgs" >>>>> fields in Table 1 are also confusing because they seem to be comparing >>> cases >>>>> where sometimes DTLS messages are included in the counts and >> sometimes >>>>> they are not. >>>>> >>>>> - If it's true that SRR messages must always be protected by DTLS (or a >>> similar >>>>> protocol) then why isn't setting up the DTLS session included in the >> number >>> of >>>>> messages in the SRR row? Is that because the DLTS sessions are >> persistent >>>>> between the hops and are assumed to have already been setup? So are >> you >>>>> then including the DLTS setup messages in DRR(DTLS) because you >> assume >>>>> they had not previously setup? >>>>> >>>>> - The DRR rows shows 1 hop in the No. of Hops column, but that doesn't >>> seem >>>>> to be quite right because of the asymmetric nature of the DRR protocol. >>>>> Shouldn't it really be "log(N) + 1" to indicate the DRR request is log(N) hops >>> and >>>>> the DRR reply is one hop? >>>>> >>>>> Overall this section needs to be clarify these things so a reader >> understands >>>>> the relationship between the DRR routing messages and the DTLS secure >>>>> connections. >>>>> >>>>> 4. When an intermediate peer receives a DRR message with the >>>>> IGNORE-STATE-KEEPING flag in the header, is it supposed to not maintain >>> any >>>>> security state or just not maintain routing state? >>>>> >>>>> 5. Section 4.2 says: >>>>> >>>>> "using DRR SHOULD be discouraged in the open Internet or if the >>> administrator >>>>> does not feel he have enough information about the overlay network >>> topology." >>>>> >>>>> Is this due to any security reason, or just because the initiator's address >>>>> reported in the Destination structure might be wrong? >>>>> >>>>> 6. Section 5.1 says: >>>>> >>>>> "Note that establishing (D)TLS secure connections for P2P overlay is not >>>>> optimal in some cases, e.g. direct response routing where (D)TLS is heavy >>> for >>>>> temporary connections. Instead, some alternate security techniques, e.g. >>>>> using public keys of the destination to encrypt the messages, and signing >>>>> timestamps to prevent reply attacks can be adopted." >>>>> >>>>> It is not valuable to speculate on alternative security technique in this >>> section, >>>>> because the I-D does not define that security technique. If you think an >>>>> alternative to DTLS is useful, then I think that discussion belongs in a new >>> draft. >>>>> >>>>> Hope that helps, >>>>> Brian >>> >>> -- >>> Brian Weis >>> Security, Enterprise Networking Group, Cisco Systems >>> Telephone: +1 408 526 4796 >>> Email: bew@cisco.com > From mcr@sandelman.ca Tue Nov 26 16:57: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 05C481AE0A6; Tue, 26 Nov 2013 16:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYlWmlueQo1M; Tue, 26 Nov 2013 16:57:21 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id BF95D1AE00A; Tue, 26 Nov 2013 16:57:21 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0976C20316; Tue, 26 Nov 2013 21:10:13 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id AB94363B88; Tue, 26 Nov 2013 19:57:13 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9DF5E63B87; Tue, 26 Nov 2013 19:57:13 -0500 (EST) From: Michael Richardson To: Tero Kivinen In-Reply-To: <21133.64571.158642.421795@fireball.kivinen.iki.fi> References: <21133.64571.158642.421795@fireball.kivinen.iki.fi> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: iesg@ietf.org, draft-ietf-roll-trickle-mcast.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-roll-trickle-mcast-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, 27 Nov 2013 00:57:24 -0000 --=-=-= Tero Kivinen wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the Thank you. Tero Kivinen wrote: > This document describes the Multicast protocol for Low and Lossy > Networks. This protocol uses trickle algorithm. I am not familiar > enough to trickle to really analyze what the protocol does. Security > considerations section mentions that the protocol uses sequence > numbers to keep track of messages, and attacker who can insert > messages can mess up with those sequence numbers, and attacker can > then flush messages from the buffered messages list, and can also > allow setting it high enough so recipients will not get any messages > as they have too small sequence number. All correct observations. > The protocol has no protection against this attack, but notes that > both of those are denial-of-service attacks and devices can protect > against them by using link-layer security mechanisms. It also claims > that those mechanisms are typically employed without specifying which > security methods it is pointing to. I do not know how often those > link-layer security methods are really used. Perhaps it would be > useful to list some of those security methods here. At this pointin LLNs, use of layer-2 security *ONLY* is pretty much 100%. It's "WEP" == Wired Equivalent Privacy. No layer-3, no other authorization distinction between devices, etc. (Zigbee IP sometimes uses per-link keying as well, so it also defends against nodes inside the tent going corrupt) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUpVDaYqHRg3pndX9AQLE8AQAmAGPgpLK8N/dilCNIYkL9dFk+Q12OJNh taq2RfQw8WA7ZO5JE1I1QpU9sWTlZkIGFaKJ36YodbUGq03Ll4yQkxw5+/QIs4ZL j71gqVppu2IDf5gAyOPnc+Pfl4gUBvL0dPa70QcjPp0StA5oOnhPTnpwIp1oFd3l eO3dj0sweSA= =/c8o -----END PGP SIGNATURE----- --=-=-=-- From d3e3e3@gmail.com Tue Nov 26 19:52: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 D57731AE109; Tue, 26 Nov 2013 19:52:08 -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 p-d1lVnNsxwe; Tue, 26 Nov 2013 19:52:07 -0800 (PST) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 135A11AE105; Tue, 26 Nov 2013 19:52:06 -0800 (PST) Received: by mail-oa0-f43.google.com with SMTP id i7so7044778oag.2 for ; Tue, 26 Nov 2013 19:52:06 -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=GeZJb9td0Kxj66eFh8zQAlV3TQ6BOS/qWWqvw8Lv4ZI=; b=h1+Wj6TBUaXxK2ZTJbxUUZfiF0geJd7LyPuUtv741fQLeU1KP9oAzk+abBqf6Dw8WU OgAoSN7E61QpZzZjNdF8fQmbV/fw2cPfgFtpfYlZzk/+hw+iLnpPzR+uaWGsUS9Un65K gq52366lfUMqJ55jlA0aoUABYb7zUZJdLHB2euaHYT6eAqxB7X2/wtyaGIBqd+B2CQmF tl7L7ffofquCbZS5AX+jxZGaiaH50w/IpDw57MitHVU1WYMpFzs3Bel8qnN6fZ1KoxDi FPE3oILb87mI+VeE9JN/+7EDjNT57Huxf0bRyyJSbdNKQkujuosqQANfW38XVmHMHLOt TsrA== X-Received: by 10.60.42.168 with SMTP id p8mr716391oel.73.1385524326652; Tue, 26 Nov 2013 19:52:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.33.102 with HTTP; Tue, 26 Nov 2013 19:51:46 -0800 (PST) In-Reply-To: <23760.1385513833@sandelman.ca> References: <21133.64571.158642.421795@fireball.kivinen.iki.fi> <23760.1385513833@sandelman.ca> From: Donald Eastlake Date: Tue, 26 Nov 2013 22:51:46 -0500 Message-ID: To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-roll-trickle-mcast.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-roll-trickle-mcast-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, 27 Nov 2013 03:52:09 -0000 Hi, On Tue, Nov 26, 2013 at 7:57 PM, Michael Richardson wrote: > > Tero Kivinen wrote: > > ... >... > > The protocol has no protection against this attack, but notes that > > both of those are denial-of-service attacks and devices can protect > > against them by using link-layer security mechanisms. It also claims > > that those mechanisms are typically employed without specifying which > > security methods it is pointing to. I do not know how often those > > link-layer security methods are really used. Perhaps it would be > > useful to list some of those security methods here. > > At this pointin LLNs, use of layer-2 security *ONLY* is pretty much 100%. > It's "WEP" == Wired Equivalent Privacy. Are you talking about 802.11 WEP? To quote from IEEE Std 802.11-2012: "The use of WEP for confidentiality, authentication, or access control is deprecated. The WEP algorithm is unsuitable for the purposes of this standard." As they say, WEP is a digital security standard that was designed by excellent radio engineers... Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > No layer-3, no other authorization distinction between devices, etc. > > (Zigbee IP sometimes uses per-link keying as well, so it also defends against > nodes inside the tent going corrupt) > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From mcr@sandelman.ca Wed Nov 27 05:41: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 225ED1AD9B6; Wed, 27 Nov 2013 05:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AvOv5yw2OXp; Wed, 27 Nov 2013 05:41:35 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD741AD8EF; Wed, 27 Nov 2013 05:41:35 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2E5892028E; Wed, 27 Nov 2013 09:54:27 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id E265463B88; Wed, 27 Nov 2013 08:41:24 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D53FB63AED; Wed, 27 Nov 2013 08:41:24 -0500 (EST) From: Michael Richardson To: Donald Eastlake In-Reply-To: References: <21133.64571.158642.421795@fireball.kivinen.iki.fi> <23760.1385513833@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: draft-ietf-roll-trickle-mcast.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-roll-trickle-mcast-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, 27 Nov 2013 13:41:38 -0000 --=-=-= Donald Eastlake wrote: > On Tue, Nov 26, 2013 at 7:57 PM, Michael Richardson > wrote: >> >> Tero Kivinen wrote: >> > ... >> ... >> > The protocol has no protection against this attack, but notes that >> > both of those are denial-of-service attacks and devices can protect >> > against them by using link-layer security mechanisms. It also claims >> > that those mechanisms are typically employed without specifying which >> > security methods it is pointing to. I do not know how often those >> > link-layer security methods are really used. Perhaps it would be >> > useful to list some of those security methods here. >> >> At this pointin LLNs, use of layer-2 security *ONLY* is pretty much 100%. >> It's "WEP" == Wired Equivalent Privacy. > Are you talking about 802.11 WEP? No. I'm using a generic term. It's like WEP == if a host has the key, it can do anything, assume any role with any authority it likes. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUpX2hIqHRg3pndX9AQLZbgP+NxX5rz2nBugULmG1vXabJlDxDTsBSgob xbn+2cE/bW7g/oXZpvYlRjdw4keFhWFpbr7BdMQ4M3gE5FBlBqtywQm2uQGN5y3K V9VVBMmaYxE2B398zvQINpcHDM+EFWb0tb5ennE9x/bk80D4W6K9Tvj89kCkAcTn EazQjn4MaKg= =C8/m -----END PGP SIGNATURE----- --=-=-=-- From Tina.Tsou.Zouting@huawei.com Wed Nov 27 18:33: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 796361AE074; Wed, 27 Nov 2013 18:33:08 -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 pDBom3riniKG; Wed, 27 Nov 2013 18:33:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3AF1AE013; Wed, 27 Nov 2013 18:33:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYJ81789; Thu, 28 Nov 2013 02:33:04 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 28 Nov 2013 02:32:33 +0000 Received: from SJCEML402-HUB.china.huawei.com (10.212.94.43) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 28 Nov 2013 02:33:03 +0000 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.242]) by sjceml402-hub.china.huawei.com ([10.212.94.43]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 18:32:55 -0800 From: Tina TSOU To: "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: Ac7r4iSTTLuLU6ECRayqapxZmS2AZQ== Date: Thu, 28 Nov 2013 02:32:54 +0000 Message-ID: <36B74C19-0B78-40BC-8B7E-A161AD644DB3@huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <535BD9AA8DFFA242BAAAD022513EAC31@huawei.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [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: Thu, 28 Nov 2013 02:33:08 -0000 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 com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any = other last call comments. This document 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:=20 "The solution MUST also be able to leverage=20 work in the MPLS WG that is in progress to improve the load balancing=20 capabilities of the network based on entropy labels [RFC6790]."=20 Since this work is already published as RFC, the sentence should be rewrit= ten as:=20 "The solution MUST also be able to leverage the MPLS load balancing=20 capabilities based on entropy labels [RFC6790]."=20 2. In Section 4.2, it says:=20 "For example consider a scenario in which CE1 is multi-homed to PE1=20 and PE2, and CE2 is multi-homed to PE3 and PE4 running in all-active=20 mode. Furthermore, consider that there exist three ECMPs between any=20 of the CE1's and CE2's multi-homed PEs. Traffic from CE1 to CE2 can=20 be forwarded on twelve different paths over MPLS/IP core as follow:=20 CE1 load balances traffic to both PE1 and PE2. Each of the PE1 and=20 PE2 have three ECMPs to PE3 and PE4 for the total of twelve paths.=20 Finally, when traffic arrives at PE3 and PE4, it gets forwarded to=20 CE2 over the Ethernet channel (aka link bundle)."=20 It seems "ECMP", "ECMP path" and "path" are messed up in this paragraph. T= o make it straight, the following is suggested:=20 "For example consider a scenario in which CE1 is multi-homed to PE1=20 and PE2, and CE2 is multi-homed to PE3 and PE4 running in all-active=20 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=20 be forwarded on twelve different paths over MPLS/IP core as follow:=20 CE1 load balances traffic to both PE1 and PE2. Each of the PE1 and=20 PE2 have three paths to PE3 and PE4 for the total of twelve paths.=20 Finally, when traffic arrives at PE3 and PE4, it gets forwarded to=20 CE2 over the Ethernet channel (aka link bundle)."=20 3. In Section 12 "Security Considerations", it says:=20 "...The requirement is to introduce no=20 new vulnerabilities beyond those of [RFC4761] and [RFC4762] when MAC=20 learning is performed in data-plane and beyond that of [RFC4364] when=20 MAC learning is performed in control plane."=20 Though BGP is used similarly in E-VPN, some new vulnerabilities will inevit= ably be introduced, such as MAC forgery in BGP, and how to protect against = individual MACs may pose a challenge.=20 4. Section 12 "Security Considerations" It is very brief. It does not mention when using multi-homing. Thank you, Tina= From kivinen@iki.fi Thu Nov 28 03:27: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 5EEA01AD8DB for ; Thu, 28 Nov 2013 03:27: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 FFoRgsiOG01c for ; Thu, 28 Nov 2013 03:27:19 -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 50A781ADF5B for ; Thu, 28 Nov 2013 03:27:18 -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 rASBRENl001961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 28 Nov 2013 13:27:14 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rASBRE8T018909; Thu, 28 Nov 2013 13:27:14 +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: <21143.10386.524650.324709@fireball.kivinen.iki.fi> Date: Thu, 28 Nov 2013 13:27:14 +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, 28 Nov 2013 11:27:22 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Adam Montville 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 Donald Eastlake T 2013-11-19 draft-ietf-soc-load-control-event-package-11 Shawn Emery T 2013-11-26 draft-ietf-cdni-requirements-13 Tobias Gondrom T 2013-11-25 draft-ietf-json-rfc4627bis-07 Dan Harkins T 2013-11-26 draft-ietf-trill-oam-framework-03 Julien Laganier T 2013-11-06 draft-ietf-forces-ceha-09 Chris Lonvick TR2013-10-25 draft-ietf-mmusic-rfc2326bis-38 Ondrej Sury T 2013-11-18 draft-ietf-l2vpn-etree-reqt-05 Brian Weis T 2013-11-26 draft-ietf-ospf-rfc6506bis-03 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 Simon Josefsson T 2013-12-06 draft-ietf-jose-use-cases-05 Matt Lepinski T 2013-11-04 draft-ietf-httpbis-p2-semantics-25 Klaas Wierenga TR2013-11-04 draft-ietf-httpbis-p4-conditional-25 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 Sam Hartman 2013-12-02 draft-ietf-bfd-on-lags-02 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 Charlie Kaufman 2013-12-10 draft-ietf-mpls-mldp-hsmp-04 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 Warren Kumari 2013-12-09 draft-ietf-pce-vendor-constraints-11 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 Vincent Roca 2013-04-26 draft-ietf-6man-stable-privacy-addresses-15 Joe Salowey 2013-11-27 draft-ietf-clue-telepresence-requirements-06 Yaron Sheffer 2013-11-27 draft-ietf-idr-extcomm-iana-01 Carl Wallace 2013-11-27 draft-ietf-mmusic-sdp-g723-g729-04 Klaas Wierenga 2013-11-27 draft-ietf-pwe3-dynamic-ms-pw-19 Tom Yu R2013-12-09 draft-ietf-rtgwg-cl-requirement-13 Tom Yu 2013-11-27 draft-ietf-sidr-rpki-rtr-impl-04 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 Glen Zorn 2013-11-27 draft-turner-ct-keypackage-receipt-n-error-algs-03 -- kivinen@iki.fi From warren@kumari.net Fri Nov 29 14:03:27 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 E88B11ADEB4 for ; Fri, 29 Nov 2013 14:03:27 -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 YSpmg5Oprp7x for ; Fri, 29 Nov 2013 14:03:26 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB37F1ADE7C for ; Fri, 29 Nov 2013 14:03:26 -0800 (PST) Received: from [192.168.0.187] (c-98-244-98-35.hsd1.va.comcast.net [98.244.98.35]) by vimes.kumari.net (Postfix) with ESMTPSA id F264E1B405AA; Fri, 29 Nov 2013 17:03:24 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Nov 2013 17:03:23 -0500 Message-Id: <51830795-3E6A-4386-9CE9-67B9E3874E48@kumari.net> To: "secdir@ietf.org" , draft-ietf-pce-vendor-constraints.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [secdir] SecDir review of draft-ietf-pce-vendor-constraints X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 22:03:28 -0000 Be ye not afraid... I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. Summary: LGTM. Version reviewed: Conveying Vendor-Specific Constraints in the Path Computation Element communication Protocol draft-ietf-pce-vendor-constraints-11.txt Notes: I did *not* perform a formal language check. At a quick glance it = looks good though. Nits: I would like to have a table of contents. This may be a personal = preference though=85. While performing this review I kept thinking "Mwahaha. This can be used = to carry arbitrary information with any PCEP object that supports TLVs.... I can = kvetch about the DoS potential". But, the authors foiled my plan to rant by mentioning = this in the=20 Security Considerations section and even mentioning a mitigation. Curses! Foiled again. W --=20 Outside of a dog, a book is your best friend, and inside of a dog, it's = too dark to read=20 From afarrel@juniper.net Fri Nov 29 14:24: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 9E2BF1ADFDC for ; Fri, 29 Nov 2013 14:24:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 TL3KgOeBRGSG for ; Fri, 29 Nov 2013 14:24:45 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5EF1ADF71 for ; Fri, 29 Nov 2013 14:24:45 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id rATMOgeA028665; Fri, 29 Nov 2013 22:24:42 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id rATMOfZI028642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Nov 2013 22:24:41 GMT From: "Adrian Farrel" To: "'Warren Kumari'" References: <51830795-3E6A-4386-9CE9-67B9E3874E48@kumari.net> In-Reply-To: <51830795-3E6A-4386-9CE9-67B9E3874E48@kumari.net> Date: Fri, 29 Nov 2013 22:24:41 -0000 Message-ID: <0a1201ceed51$ccf31660$66d94320$@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFew8/4vHFrwArBIhpZzB1BHo0aP5sdGtnA Content-Language: en-gb Cc: draft-ietf-pce-vendor-constraints.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-pce-vendor-constraints X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: afarrel@juniper.net List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 22:24:47 -0000 Thanks Warren, Sorry to have disappointed you. Adrian > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net] > Sent: 29 November 2013 22:03 > To: secdir@ietf.org; draft-ietf-pce-vendor-constraints.all@tools.ietf.org > Cc: Warren Kumari > Subject: SecDir review of draft-ietf-pce-vendor-constraints > > Be ye not afraid... > 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: LGTM. > > Version reviewed: > Conveying Vendor-Specific Constraints in the Path Computation > Element communication Protocol > draft-ietf-pce-vendor-constraints-11.txt > > > Notes: I did *not* perform a formal language check. At a quick glance it looks > good though. > > Nits: I would like to have a table of contents. This may be a personal preference > though.. > > While performing this review I kept thinking "Mwahaha. This can be used to carry > arbitrary information with any PCEP object that supports TLVs.... I can kvetch > about the > DoS potential". But, the authors foiled my plan to rant by mentioning this in the > Security Considerations section and even mentioning a mitigation. > Curses! Foiled again. > > W > > > > > -- > Outside of a dog, a book is your best friend, and inside of a dog, it's too dark to > read From shawn.emery@oracle.com Sat Nov 30 09:27: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 0146B1AE477 for ; Sat, 30 Nov 2013 09:27:50 -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 OOeI8HMclEN9 for ; Sat, 30 Nov 2013 09:27:48 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 88C0E1AE046 for ; Sat, 30 Nov 2013 09:27:48 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rAUHRj2l029343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 30 Nov 2013 17:27:46 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAUHRgOS011410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Nov 2013 17:27:45 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAUHRgHw003498; Sat, 30 Nov 2013 17:27:42 GMT Received: from [10.159.107.127] (/10.159.107.127) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 30 Nov 2013 09:27:42 -0800 Message-ID: <529A2050.7090205@oracle.com> Date: Sat, 30 Nov 2013 10:28:48 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20130718 Thunderbird/17.0.6 MIME-Version: 1.0 To: secdir@ietf.org References: <52158CF5.4050001@oracle.com> In-Reply-To: <52158CF5.4050001@oracle.com> X-Forwarded-Message-Id: <52158CF5.4050001@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: draft-ietf-cdni-requirements.all@tools.ietf.org Subject: [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: Sat, 30 Nov 2013 17:27: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. This informational internet-draft describes the requirements to integrate multiple Content Delivery Networks (CDNs) for Content Service Providers (CSPs) so that end users have a single point of access for content. The security considerations section does exist and refers to a separate section for the discussion on security requirements. This section gives requirements priorities from high to low on the various types of attacks. The high level priorities are for authentication, confidentiality, integrity protection, 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 charliek@microsoft.com Sat Nov 30 23:11: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 E76AF1AE343; Sat, 30 Nov 2013 23:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xQB5oyKQh7LS; Sat, 30 Nov 2013 23:11:16 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id C8BF81AE0D5; Sat, 30 Nov 2013 23:11:15 -0800 (PST) Received: from BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) by BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) with Microsoft SMTP Server (TLS) id 15.0.820.5; Sun, 1 Dec 2013 07:11:12 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com ([169.254.4.113]) by BL2PR03MB592.namprd03.prod.outlook.com ([169.254.4.113]) with mapi id 15.00.0820.005; Sun, 1 Dec 2013 07:11:12 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-mpls-mldp-hsmp.all@tools.ietf.org" Thread-Topic: [secdir] secdir review of draft-ietf-mpls-hsmp-04 Thread-Index: Ac7uYU9mzm9sXTIqSXuhc2sxgMCpPg== Date: Sun, 1 Dec 2013 07:11:11 +0000 Message-ID: <2b12ea7449014b53a4b4118929921b75@BL2PR03MB592.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.158.7] x-forefront-prvs: 0047BC5ADE x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(47976001)(56776001)(85306002)(83072001)(77982001)(76576001)(2656002)(74366001)(74316001)(81816001)(74876001)(59766001)(56816005)(90146001)(76786001)(74706001)(54316002)(81686001)(77096001)(74662001)(80022001)(81342001)(76176001)(76796001)(50986001)(81542001)(47446002)(31966008)(87266001)(49866001)(4396001)(74502001)(80976001)(66066001)(87936001)(54356001)(79102001)(46102001)(83322001)(76482001)(47736001)(65816001)(69226001)(63696002)(53806001)(33646001)(51856001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB592; H:BL2PR03MB592.namprd03.prod.outlook.com; CLIP:50.46.158.7; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [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: Sun, 01 Dec 2013 07:11:18 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document 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 tw= ice instead of once and packet delivery has longer latency in that most pac= kets travel over more links from their original source to ultimate destinat= ion. The two advantages I can imagine are (1) in almost all cases, all pack= ets will arrive at all destinations in the same order (in the original prot= ocol, 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 sin= gle 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 wha= t 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 protoc= ol 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 b= elieve it should read "Direct communication among the leaf nodes is not all= owed." because communication among the leaf nodes is supported by this prot= ocol 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