From bew@cisco.com Fri Jul 1 16:57:00 2011 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 2C6001F0C4B; Fri, 1 Jul 2011 16:57:00 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ux6ykXrGq1aQ; Fri, 1 Jul 2011 16:56:59 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id DBA251F0C4C; Fri, 1 Jul 2011 16:56:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=3062; q=dns/txt; s=iport; t=1309564594; x=1310774194; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=ccZjSCWGySwoyTLUR5HTBWfnnZg+x+w0Sa/ZubCvvXU=; b=Vt6BMwd7yoB/BCQSgMz7qoPJnege0COiIrg8T/7dCZyRh/xQrJPf5+nN fMy3KSCeZH1kcm4RLyccTew0TTxOaueRW2sXhDtAEVq88Q1CD/f0E6kDK +Uy+RVv1Pcp5AxlTOCwbZ9yVv/Skm13ffcTWe44EliUyRhhymQiYOpoaY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADxeDk6rRDoH/2dsb2JhbABSqAF3rGOdXoYyBIc+inSQUQ X-IronPort-AV: E=Sophos;i="4.65,461,1304294400"; d="scan'208";a="473777489" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 01 Jul 2011 23:56:34 +0000 Received: from dhcp-128-107-147-1.cisco.com (dhcp-128-107-147-1.cisco.com [128.107.147.1]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p61NuY9D003231; Fri, 1 Jul 2011 23:56:34 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jul 2011 16:56:33 -0700 Message-Id: <571B7ACD-26B9-4A46-9791-0EA76134A585@cisco.com> To: secdir@ietf.org, iesg@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-6man-flow-ecmp.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-6man-flow-ecmp-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 23:57:00 -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. Intermediate systems in a routing system perform load balancing of = packets between a pair of nodes based on values in the packet. This I-D = defines a safe method by which the IPv6 flow label can be one of those = values. A necessary condition is that flow labels that have a uniform = distribution, and the method is restricting to use by IPv6 tunnel = endpoints that are more trusted to apply this method to packets they = encapsulate. The Security Considerations section describes a single availability = attack, which is an attacker able to "selectively overload a particular = path". I assume that this can happen if the hash calculation of the = intermediate systems will send too many packets down one path and = overload it rather than properly load balancing across the paths. The = values used by the intermediate system come from packet headers, and the = calculation is deterministic. If the flow label computed by the tunnel = endpoint is included in the calculation, and it is also deterministic, = then it seems that an attacker knowing the method used by the tunnel = endpoint to create flow labels can engage in this attack. That is, the = attacker crafting packets that will result in the tunnel end point = computing one or more flow labels that cause the intermediate system to = include in its hash calculation, which results in it routing over the = same path. This may be feasible for an informed attacker controlling a = suitable size botnet. So making the tunnel endpoint flow label = calculation unpredictable would be important to stop this attack.=20 The I-D recommends computing the flow label according to = [I-D.ietf-6man-flow-3697bis], and also states in Section 3 that the = result "will be hard for a malicious third party to predict". If so, = then this attack seems mitigated when the recommendation is taken. But = it would be helpful if the Security Considerations could also mention = the need for unpredictability, and perhaps also mention how the = unpredictability is added. As far as I can tell, the recommendation in = [I-D.ietf-6man-flow-3697bis] is to build the flow label from values in = the packet being encapsulated, which the attacker itself may have = generated. If the attacker can provide all of the inputs, and it knows = the tunnel endpoint flow label calculation, then there doesn't seem to = be any unpredictability. (The I-D says to see = [I-D.ietf-6man-flow-3697bis] for further discussion of this threat. I = can't seem to find it, but if it's there simply pointing to that = discussion would be fine too.) Other than clarifying how that attack is mitigated I do not see the need = for any changes.=20 Brian= From jari.arkko@piuha.net Sat Jul 2 02:24:44 2011 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 A00471F0C53; Sat, 2 Jul 2011 02:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.34 X-Spam-Level: X-Spam-Status: No, score=-102.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3TEKXHxlIo2; Sat, 2 Jul 2011 02:24:44 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 97BCF1F0C4B; Sat, 2 Jul 2011 02:24:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B7EFD2CEFF; Sat, 2 Jul 2011 12:24:42 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOlPWxmWuO-N; Sat, 2 Jul 2011 12:24:41 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 93B152CE66; Sat, 2 Jul 2011 12:24:41 +0300 (EEST) Message-ID: <4E0EE3D8.9040500@piuha.net> Date: Sat, 02 Jul 2011 11:24:40 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Brian Weis References: <571B7ACD-26B9-4A46-9791-0EA76134A585@cisco.com> In-Reply-To: <571B7ACD-26B9-4A46-9791-0EA76134A585@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-6man-flow-ecmp.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-6man-flow-ecmp-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: Sat, 02 Jul 2011 09:24:44 -0000 Thanks for your review, Brian. I do agree that the issue that you=20 mention should be explained better. Authors, please suggest some text. Jari Brian Weis kirjoitti: > 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. The= se comments were written primarily for the benefit of the security area d= irectors. Document editors and WG chairs should treat these comments just= like any other last call comments. > > Intermediate systems in a routing system perform load balancing of pack= ets between a pair of nodes based on values in the packet. This I-D defin= es a safe method by which the IPv6 flow label can be one of those values.= A necessary condition is that flow labels that have a uniform distributi= on, and the method is restricting to use by IPv6 tunnel endpoints that ar= e more trusted to apply this method to packets they encapsulate. > > The Security Considerations section describes a single availability att= ack, which is an attacker able to "selectively overload a particular path= ". I assume that this can happen if the hash calculation of the intermedi= ate systems will send too many packets down one path and overload it rath= er than properly load balancing across the paths. The values used by the = intermediate system come from packet headers, and the calculation is dete= rministic. If the flow label computed by the tunnel endpoint is included = in the calculation, and it is also deterministic, then it seems that an a= ttacker knowing the method used by the tunnel endpoint to create flow lab= els can engage in this attack. That is, the attacker crafting packets tha= t will result in the tunnel end point computing one or more flow labels t= hat cause the intermediate system to include in its hash calculation, whi= ch results in it routing over the same path. This may be feasible for an = informed attacker controlling a suitable size botnet. So making the tunne= l endpoint flow label calculation unpredictable would be important to sto= p this attack.=20 > > The I-D recommends computing the flow label according to [I-D.ietf-6man= -flow-3697bis], and also states in Section 3 that the result "will be har= d for a malicious third party to predict". If so, then this attack seems = mitigated when the recommendation is taken. But it would be helpful if th= e Security Considerations could also mention the need for unpredictabilit= y, and perhaps also mention how the unpredictability is added. As far as = I can tell, the recommendation in [I-D.ietf-6man-flow-3697bis] is to buil= d the flow label from values in the packet being encapsulated, which the = attacker itself may have generated. If the attacker can provide all of th= e inputs, and it knows the tunnel endpoint flow label calculation, then t= here doesn't seem to be any unpredictability. (The I-D says to see [I-D.i= etf-6man-flow-3697bis] for further discussion of this threat. I can't see= m to find it, but if it's there simply pointing to that discussion would = be fine too.) > > Other than clarifying how that attack is mitigated I do not see the nee= d for any changes.=20 > > Brian > =20 From brian.e.carpenter@gmail.com Sat Jul 2 05:13:19 2011 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 703BB11E80E5; Sat, 2 Jul 2011 05:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.569 X-Spam-Level: X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7iM4LjTati1; Sat, 2 Jul 2011 05:13:18 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C14211E80E3; Sat, 2 Jul 2011 05:13:18 -0700 (PDT) Received: by iwn39 with SMTP id 39so4282402iwn.31 for ; Sat, 02 Jul 2011 05:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EfuGeDMmPQiqeLPeDo4ns8wzVKys7V45tZUCLApWSQ8=; b=nD9wKw02QwnO8zjlXZUNQGMf6L1f4S0vZEQhEye5T/zFCEeBuRQ9X0Geodj54vAvo0 xalguxet1DawyGjcTlA3JMgCrsEm2xcAZytHlGyvel0s6iqPNusHu7rxtw9lxksC15b0 fx/Hag9coJMTfqdoh3kYJvkqubh+4qVqoYod4= Received: by 10.42.167.73 with SMTP id r9mr4917146icy.347.1309608798199; Sat, 02 Jul 2011 05:13:18 -0700 (PDT) Received: from [10.255.25.118] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id d8sm4367025icy.21.2011.07.02.05.13.16 (version=SSLv3 cipher=OTHER); Sat, 02 Jul 2011 05:13:17 -0700 (PDT) Message-ID: <4E0F0B53.2080809@gmail.com> Date: Sun, 03 Jul 2011 00:13:07 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jari Arkko References: <571B7ACD-26B9-4A46-9791-0EA76134A585@cisco.com> <4E0EE3D8.9040500@piuha.net> In-Reply-To: <4E0EE3D8.9040500@piuha.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-flow-ecmp.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-6man-flow-ecmp-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: Sat, 02 Jul 2011 12:13:19 -0000 > If the attacker can provide all of the inputs, and it knows the tunnel > endpoint flow label calculation, then there doesn't seem to be any unpredictability. That's correct, and means that if you are concerned about this risk, there needs to be an obfuscation step in the hash algorithm. > (The I-D says to see [I-D.ietf-6man-flow-3697bis] for further discussion > of this threat. I can't seem to find it, but if it's there simply pointing > to that discussion would be fine too.) I think it would be better to include any additional wording in 3697bis - can we look at this when we get the security review of that draft? I think Brian W is correct that it needs to be added. Regards Brian Carpenter On 2011-07-02 21:24, Jari Arkko wrote: > Thanks for your review, Brian. I do agree that the issue that you > mention should be explained better. Authors, please suggest some text. > > Jari > > Brian Weis kirjoitti: >> 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. >> >> Intermediate systems in a routing system perform load balancing of >> packets between a pair of nodes based on values in the packet. This >> I-D defines a safe method by which the IPv6 flow label can be one of >> those values. A necessary condition is that flow labels that have a >> uniform distribution, and the method is restricting to use by IPv6 >> tunnel endpoints that are more trusted to apply this method to packets >> they encapsulate. >> >> The Security Considerations section describes a single availability >> attack, which is an attacker able to "selectively overload a >> particular path". I assume that this can happen if the hash >> calculation of the intermediate systems will send too many packets >> down one path and overload it rather than properly load balancing >> across the paths. The values used by the intermediate system come from >> packet headers, and the calculation is deterministic. If the flow >> label computed by the tunnel endpoint is included in the calculation, >> and it is also deterministic, then it seems that an attacker knowing >> the method used by the tunnel endpoint to create flow labels can >> engage in this attack. That is, the attacker crafting packets that >> will result in the tunnel end point computing one or more flow labels >> that cause the intermediate system to include in its hash calculation, >> which results in it routing over the same path. This may be feasible >> for an informed attacker controlling a suitable size botnet. So making >> the tunnel endpoint flow label calculation unpredictable would be >> important to stop this attack. >> The I-D recommends computing the flow label according to >> [I-D.ietf-6man-flow-3697bis], and also states in Section 3 that the >> result "will be hard for a malicious third party to predict". If so, >> then this attack seems mitigated when the recommendation is taken. But >> it would be helpful if the Security Considerations could also mention >> the need for unpredictability, and perhaps also mention how the >> unpredictability is added. As far as I can tell, the recommendation in >> [I-D.ietf-6man-flow-3697bis] is to build the flow label from values in >> the packet being encapsulated, which the attacker itself may have >> generated. If the attacker can provide all of the inputs, and it knows >> the tunnel endpoint flow label calculation, then there doesn't seem to >> be any unpredictability. (The I-D says to see >> [I-D.ietf-6man-flow-3697bis] for further discussion of this threat. I >> can't seem to find it, but if it's there simply pointing to that >> discussion would be fine too.) >> >> Other than clarifying how that attack is mitigated I do not see the >> need for any changes. >> Brian >> > > > From yaronf.ietf@gmail.com Sun Jul 3 12:14:22 2011 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 0FA6D11E80A2; Sun, 3 Jul 2011 12:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkvMSAX5F902; Sun, 3 Jul 2011 12:14:21 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B1B7C11E80A1; Sun, 3 Jul 2011 12:14:20 -0700 (PDT) Received: by wwe5 with SMTP id 5so3036888wwe.13 for ; Sun, 03 Jul 2011 12:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=1DQMgXc+OBiLMnEka7Z87guAA2v/4FRNrMjo7ANm7N0=; b=BegAuR3T2iSA+RP/sph+wMSCpwnjkhLHT8idT/91tW4xmRzCpKCCb6GukTsSOXawKc s3X982JGu231sIi+dtkNhS9Wiw8AUJRj/96B3LQx4laa4V47hS6QTvxl1U3Dz0h5GCCB BpDdrTul32KUB07oquzTmLOM5ag4NtecNeT5U= Received: by 10.227.148.220 with SMTP id q28mr4820350wbv.29.1309720458573; Sun, 03 Jul 2011 12:14:18 -0700 (PDT) Received: from [10.0.0.4] (bzq-79-177-192-201.red.bezeqint.net [79.177.192.201]) by mx.google.com with ESMTPS id d19sm3898721wbh.8.2011.07.03.12.14.16 (version=SSLv3 cipher=OTHER); Sun, 03 Jul 2011 12:14:17 -0700 (PDT) Message-ID: <4E10BF86.6010003@gmail.com> Date: Sun, 03 Jul 2011 22:14:14 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: Security Area Directorate , The IESG , draft-ietf-sidr-repos-struct.all@tools.ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [secdir] SecDir review of draft-ietf-sidr-repos-struct-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 19:14:22 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments This draft describes the structure of the RPKI repositories. This is a dedicated, even more complex than usual PKI deployment. The security considerations are short, considering that the entire document is about the security underpinnings of a critical infrastructure. However they do make sense to me. I do have two comments: • The mandatory use or Rsync (vs. e.g. simple HTTP) in a one-way content retrieval context seems like a questionable security vs. operational cost trade-off. Rsync is complex and has seen various security vulnerabilities over the years: http://secunia.com/advisories/search/?search=rsync. BTW, the reference "to rsync" only defines the URI format. As to a formal specification of the protocol, guess what? http://lists.samba.org/archive/rsync/2008-October/021927.html. • The following sentence seems to require clarification, and hints at possible risks/mitigations: "However, even the use of manifests and CRLs will not allow a relying party to detect all forms of substitution attacks based on older (but not expired) valid objects." Thanks, Yaron From tlyu@mit.edu Mon Jul 4 00:46:09 2011 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 7848621F84D1; Mon, 4 Jul 2011 00:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jegZy7YVupP0; Mon, 4 Jul 2011 00:46:09 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id C01D521F84CF; Mon, 4 Jul 2011 00:46:08 -0700 (PDT) X-AuditID: 1209190c-b7c65ae00000117c-d3-4e116fc9961a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id C8.86.04476.9CF611E4; Mon, 4 Jul 2011 03:46:17 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p647k6BJ024061; Mon, 4 Jul 2011 03:46:08 -0400 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.6/8.12.4) with ESMTP id p647k4Pd026841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Jul 2011 03:46:05 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id p647k3I6017210; Mon, 4 Jul 2011 03:46:03 -0400 (EDT) To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mpls-ldp-p2mp.all@tools.ietf.org From: Tom Yu Date: Mon, 04 Jul 2011 03:46:03 -0400 Message-ID: Lines: 32 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixG6nrnsyX9DPYP8mNovNS/IsZvyZyGzx YeFDFgdmjyVLfjJ5fLn8mS2AKYrLJiU1J7MstUjfLoEr48uFZ8wFHTwVt5+eYWpg/MfZxcjJ ISFgIjH5xz8mCFtM4sK99WxdjFwcQgL7GCVWXVjLAuGsZ5TY0DKJGcK5zCRxs62REcLpZJQ4 /6+JDaRfRCBCYuH+Y2C2sICpxLYva4CKODjYBKQlji4uAwmzCKhKTFo6kQkkzCtgIfGoyxkk zCPAKXF61mcWEJtXQFDi5MwnYDazgJbEjX8vmSYw8s1CkpqFJLWAkWkVo2xKbpVubmJmTnFq sm5xcmJeXmqRrqFebmaJXmpK6SZGUKBxSvLsYHxzUOkQowAHoxIPL+MkAT8h1sSy4srcQ4yS HExKorzn8wT9hPiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwMngC5XhTEiurUovyYVLSHCxK4rzl 3v99hQTSE0tSs1NTC1KLYLIyHBxKErzCwIgSEixKTU+tSMvMKUFIM3FwggznARoeCLKYt7gg Mbc4Mx0if4pRUUqcVxakWQAkkVGaB9cLSwSvGMWBXhHm5Qep4gEmEbjuV0CDmYAGWyWCDS5J REhJNTDWclQ+vaEru7ZIxmmW1PIyVQ+up8ptxw/1M8Y21u+fd+iCwMXjZmy5J/Ka3N48y03+ drru28bMxPzAots7XI9q1Ude5pg1reVR7Y7s8LTUtX9U7FnSRESTE00MZbaHKMwTNc2Y+eXm zsyAG0tWXlxyT37SyW/vTa8fKN8Ud6shW+bS22L3Q25KLMUZiYZazEXFiQB4mg933wIAAA== Subject: [secdir] secdir review of draft-ietf-mpls-ldp-p2mp-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 07:46:09 -0000 This document extends the Label Distribution Protocol to support the operation of Point-to-Multipoint and Multipoint-to-Multipoint Label-Switched Paths. The Security Considerations section states that the same security considerations in RFC 5036 apply. It also states that authorization mechanisms for controlling which LSRs join a given MP LSP are out of scope for this document. These seem reasonable to me. The protocol appears to be initiated by the receivers (egress nodes), which could make the design of authorization mechanisms challenging. The following comments are not directly security-related: Section 2.4.1.1 (Determining one's 'upstream LSR') recommends using an operation based on CRC32 for selecting among candidate upstream LSRs. How important is it for the selection to be uniformly distributed? CRC32 is known to have poor avalanche properties that might make it unsuitable as a hash function, even for non-cryptographic purposes. Also, there is often ambiguity when specifying the use of CRC32, even if the particular generator polynomial (e.g., the ISO/IEC 3309 32-bit FCS as specified in this document) is specified. Some common implementations omit the ones-preload and/or post-complement. The input bit ordering also needs to be specified when using CRC32 with a byte-oriented protocol. (as does the translation of the CRC remainder bit vector into an integer to perform modulo operations when used as a hash function) Editorial: * There is no normative reference for CRC32. From carl@redhoundsoftware.com Tue Jul 5 04:49:42 2011 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 7470E11E8074; Tue, 5 Jul 2011 04:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxZd2BkMGr9p; Tue, 5 Jul 2011 04:49:41 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id AEF099E8005; Tue, 5 Jul 2011 04:49:41 -0700 (PDT) Received: by qyk29 with SMTP id 29so4629230qyk.10 for ; Tue, 05 Jul 2011 04:49:40 -0700 (PDT) Received: by 10.224.27.66 with SMTP id h2mr5706771qac.175.1309866580926; Tue, 05 Jul 2011 04:49:40 -0700 (PDT) Received: from [192.168.1.5] (pool-173-79-129-248.washdc.fios.verizon.net [173.79.129.248]) by mx.google.com with ESMTPS id t21sm5482732qcs.2.2011.07.05.04.49.39 (version=SSLv3 cipher=OTHER); Tue, 05 Jul 2011 04:49:40 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Tue, 05 Jul 2011 07:49:36 -0400 From: Carl Wallace To: , Message-ID: Thread-Topic: Secdir review of draft-ietf-mpls-p2mp-lsp-ping-16 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: draft-ietf-mpls-p2mp-lsp-ping.authors@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-mpls-p2mp-lsp-ping-16 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 Jul 2011 11:49:42 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These 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 some extensions to P2P LSP Ping to support P2MP. The security considerations reference those in RFC 4379 with one addition. This seems OK to me. From bew@cisco.com Tue Jul 5 11:22:29 2011 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 2059521F88CD; Tue, 5 Jul 2011 11:22:29 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljD1EP0KCcpa; Tue, 5 Jul 2011 11:22:28 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 5B55321F88AA; Tue, 5 Jul 2011 11:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=4689; q=dns/txt; s=iport; t=1309890148; x=1311099748; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=EVhYiK47WDQSXfPEmC0P+EvddWTXGCt0SSdrCizlW74=; b=QQx2LMVvSiXvW0bDopz+0JXurKPzTqESfZqVjcbB869kBVwt3bldN9mq PutqHqdrgA8+sfB0tgZViy6tqw2mCav7EMf2vjCTgyP5J9VKcizEXxXS7 Phtg4sxZ3igY5E2q2LPO2R7NfCt9zPUlii6G13WYA7HCspz4w+pJwo3cb 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHNVE06rRDoG/2dsb2JhbABNBqgJd4h6pDmdeIM7gnsEhz+Kd5BW X-IronPort-AV: E=Sophos;i="4.65,481,1304294400"; d="scan'208";a="361592580" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-5.cisco.com with ESMTP; 05 Jul 2011 18:22:27 +0000 Received: from stealth-10-32-244-212.cisco.com (stealth-10-32-244-212.cisco.com [10.32.244.212]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p65IMRac001967; Tue, 5 Jul 2011 18:22:27 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: <4E0F0B53.2080809@gmail.com> Date: Tue, 5 Jul 2011 11:22:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7CDA80AB-6144-4449-86AB-5F659AD97243@cisco.com> References: <571B7ACD-26B9-4A46-9791-0EA76134A585@cisco.com> <4E0EE3D8.9040500@piuha.net> <4E0F0B53.2080809@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-6man-flow-ecmp.all@tools.ietf.org, Jari Arkko , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-6man-flow-ecmp-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: Tue, 05 Jul 2011 18:22:29 -0000 Hi Brian C, On Jul 2, 2011, at 5:13 AM, Brian E Carpenter wrote: >> If the attacker can provide all of the inputs, and it knows the = tunnel >> endpoint flow label calculation, then there doesn't seem to be any = unpredictability.=20 >=20 > That's correct, and means that if you are concerned about this risk, > there needs to be an obfuscation step in the hash algorithm. Right, but obfuscation is kind of a loaded word. Adding an input to the = hash algorithm that the attacker is unlikely to guess will mitigate the = risk, and this is probably what you meant. Brian Weis=20 >=20 >> (The I-D says to see [I-D.ietf-6man-flow-3697bis] for further = discussion=20 >> of this threat. I can't seem to find it, but if it's there simply = pointing=20 >> to that discussion would be fine too.) >=20 > I think it would be better to include any additional wording in = 3697bis > - can we look at this when we get the security review of that draft? > I think Brian W is correct that it needs to be added. >=20 > Regards > Brian Carpenter >=20 > On 2011-07-02 21:24, Jari Arkko wrote: >> Thanks for your review, Brian. I do agree that the issue that you >> mention should be explained better. Authors, please suggest some = text. >>=20 >> Jari >>=20 >> Brian Weis kirjoitti: >>> 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 >>> Intermediate systems in a routing system perform load balancing of >>> packets between a pair of nodes based on values in the packet. This >>> I-D defines a safe method by which the IPv6 flow label can be one of >>> those values. A necessary condition is that flow labels that have a >>> uniform distribution, and the method is restricting to use by IPv6 >>> tunnel endpoints that are more trusted to apply this method to = packets >>> they encapsulate. >>>=20 >>> The Security Considerations section describes a single availability >>> attack, which is an attacker able to "selectively overload a >>> particular path". I assume that this can happen if the hash >>> calculation of the intermediate systems will send too many packets >>> down one path and overload it rather than properly load balancing >>> across the paths. The values used by the intermediate system come = from >>> packet headers, and the calculation is deterministic. If the flow >>> label computed by the tunnel endpoint is included in the = calculation, >>> and it is also deterministic, then it seems that an attacker knowing >>> the method used by the tunnel endpoint to create flow labels can >>> engage in this attack. That is, the attacker crafting packets that >>> will result in the tunnel end point computing one or more flow = labels >>> that cause the intermediate system to include in its hash = calculation, >>> which results in it routing over the same path. This may be feasible >>> for an informed attacker controlling a suitable size botnet. So = making >>> the tunnel endpoint flow label calculation unpredictable would be >>> important to stop this attack. >>> The I-D recommends computing the flow label according to >>> [I-D.ietf-6man-flow-3697bis], and also states in Section 3 that the >>> result "will be hard for a malicious third party to predict". If so, >>> then this attack seems mitigated when the recommendation is taken. = But >>> it would be helpful if the Security Considerations could also = mention >>> the need for unpredictability, and perhaps also mention how the >>> unpredictability is added. As far as I can tell, the recommendation = in >>> [I-D.ietf-6man-flow-3697bis] is to build the flow label from values = in >>> the packet being encapsulated, which the attacker itself may have >>> generated. If the attacker can provide all of the inputs, and it = knows >>> the tunnel endpoint flow label calculation, then there doesn't seem = to >>> be any unpredictability. (The I-D says to see >>> [I-D.ietf-6man-flow-3697bis] for further discussion of this threat. = I >>> can't seem to find it, but if it's there simply pointing to that >>> discussion would be fine too.) >>>=20 >>> Other than clarifying how that attack is mitigated I do not see the >>> need for any changes. >>> Brian >>>=20 >>=20 >>=20 >>=20 --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From brian.e.carpenter@gmail.com Tue Jul 5 12:25:59 2011 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 ECED921F8A14; Tue, 5 Jul 2011 12:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.576 X-Spam-Level: X-Spam-Status: No, score=-103.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2ZDiEJkvNgD; Tue, 5 Jul 2011 12:25:59 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E28B21F8A13; Tue, 5 Jul 2011 12:25:59 -0700 (PDT) Received: by iwn39 with SMTP id 39so6766638iwn.31 for ; Tue, 05 Jul 2011 12:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VaoWdqde2z5pnpPUNUaytqghleKTPywOdWR4PY2fx74=; b=btm2D33yFwhuM+pZhNLpvnJ8sHv/42smyc7IrjZYzDNdSRrWnsTspmqLlB62wvUNeM vC6gdb0bcSrYu6hPUEcJHFEb2lshftHaG1VAz2aKrmSKMa9BmVXniRQGk5iyrjr+hmPI grPOcftmdggqvIsoXtQXUDpKvmo5sDgm/tGVM= Received: by 10.42.155.70 with SMTP id t6mr7127690icw.405.1309893958633; Tue, 05 Jul 2011 12:25:58 -0700 (PDT) Received: from [10.255.25.118] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id j7sm7903241icq.14.2011.07.05.12.25.56 (version=SSLv3 cipher=OTHER); Tue, 05 Jul 2011 12:25:57 -0700 (PDT) Message-ID: <4E13653F.5090707@gmail.com> Date: Wed, 06 Jul 2011 07:25:51 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Weis References: <571B7ACD-26B9-4A46-9791-0EA76134A585@cisco.com> <4E0EE3D8.9040500@piuha.net> <4E0F0B53.2080809@gmail.com> <7CDA80AB-6144-4449-86AB-5F659AD97243@cisco.com> In-Reply-To: <7CDA80AB-6144-4449-86AB-5F659AD97243@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-flow-ecmp.all@tools.ietf.org, Jari Arkko , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-6man-flow-ecmp-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: Tue, 05 Jul 2011 19:26:00 -0000 On 2011-07-06 06:22, Brian Weis wrote: > Hi Brian C, > > On Jul 2, 2011, at 5:13 AM, Brian E Carpenter wrote: > >>> If the attacker can provide all of the inputs, and it knows the tunnel >>> endpoint flow label calculation, then there doesn't seem to be any unpredictability. >> That's correct, and means that if you are concerned about this risk, >> there needs to be an obfuscation step in the hash algorithm. > > Right, but obfuscation is kind of a loaded word. Adding an input to the hash algorithm that the attacker is unlikely to guess will mitigate the risk, and this is probably what you meant. Yes, I agree and that really belongs in the 3697bis draft, whose Last Call is running a bit behind this one. I will come up with some wording before the I-D cutoff. Brian > Brian Weis > >>> (The I-D says to see [I-D.ietf-6man-flow-3697bis] for further discussion >>> of this threat. I can't seem to find it, but if it's there simply pointing >>> to that discussion would be fine too.) >> I think it would be better to include any additional wording in 3697bis >> - can we look at this when we get the security review of that draft? >> I think Brian W is correct that it needs to be added. >> >> Regards >> Brian Carpenter >> >> On 2011-07-02 21:24, Jari Arkko wrote: >>> Thanks for your review, Brian. I do agree that the issue that you >>> mention should be explained better. Authors, please suggest some text. >>> >>> Jari >>> >>> Brian Weis kirjoitti: >>>> 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. >>>> >>>> Intermediate systems in a routing system perform load balancing of >>>> packets between a pair of nodes based on values in the packet. This >>>> I-D defines a safe method by which the IPv6 flow label can be one of >>>> those values. A necessary condition is that flow labels that have a >>>> uniform distribution, and the method is restricting to use by IPv6 >>>> tunnel endpoints that are more trusted to apply this method to packets >>>> they encapsulate. >>>> >>>> The Security Considerations section describes a single availability >>>> attack, which is an attacker able to "selectively overload a >>>> particular path". I assume that this can happen if the hash >>>> calculation of the intermediate systems will send too many packets >>>> down one path and overload it rather than properly load balancing >>>> across the paths. The values used by the intermediate system come from >>>> packet headers, and the calculation is deterministic. If the flow >>>> label computed by the tunnel endpoint is included in the calculation, >>>> and it is also deterministic, then it seems that an attacker knowing >>>> the method used by the tunnel endpoint to create flow labels can >>>> engage in this attack. That is, the attacker crafting packets that >>>> will result in the tunnel end point computing one or more flow labels >>>> that cause the intermediate system to include in its hash calculation, >>>> which results in it routing over the same path. This may be feasible >>>> for an informed attacker controlling a suitable size botnet. So making >>>> the tunnel endpoint flow label calculation unpredictable would be >>>> important to stop this attack. >>>> The I-D recommends computing the flow label according to >>>> [I-D.ietf-6man-flow-3697bis], and also states in Section 3 that the >>>> result "will be hard for a malicious third party to predict". If so, >>>> then this attack seems mitigated when the recommendation is taken. But >>>> it would be helpful if the Security Considerations could also mention >>>> the need for unpredictability, and perhaps also mention how the >>>> unpredictability is added. As far as I can tell, the recommendation in >>>> [I-D.ietf-6man-flow-3697bis] is to build the flow label from values in >>>> the packet being encapsulated, which the attacker itself may have >>>> generated. If the attacker can provide all of the inputs, and it knows >>>> the tunnel endpoint flow label calculation, then there doesn't seem to >>>> be any unpredictability. (The I-D says to see >>>> [I-D.ietf-6man-flow-3697bis] for further discussion of this threat. I >>>> can't seem to find it, but if it's there simply pointing to that >>>> discussion would be fine too.) >>>> >>>> Other than clarifying how that attack is mitigated I do not see the >>>> need for any changes. >>>> Brian >>>> >>> >>> > > From bew@cisco.com Tue Jul 5 12:44:36 2011 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 CB04221F87E6; Tue, 5 Jul 2011 12:44:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2pJTbz2829E; Tue, 5 Jul 2011 12:44:36 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 1742521F8667; Tue, 5 Jul 2011 12:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=5249; q=dns/txt; s=iport; t=1309895076; x=1311104676; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=hh1uVqK38HpiIml9CdpZ1SjGxJqvn0MdmMBTLZpbZiw=; b=cvRlP1IF/OT3fOUW1eQNRRWXzJDzkpL4XpJnLCDyzlKbYGyPCUrrUpFU 5jhmL/xF5qV2ixEbYs18Jrj3oeZSnu8vHOwjuk0bkT92GYd+7PvtKv4CZ W6X2v+Aezel3362pbapHRHqdZ00vX1wjvOsvTzHLLBKuWPy4MI+leIdgZ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFhpE06rRDoH/2dsb2JhbABNBqgId4h6pHKeC4M7gnsEhz+Kd5BW X-IronPort-AV: E=Sophos;i="4.65,481,1304294400"; d="scan'208";a="361654106" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-5.cisco.com with ESMTP; 05 Jul 2011 19:44:35 +0000 Received: from dhcp-128-107-147-1.cisco.com (dhcp-128-107-147-1.cisco.com [128.107.147.1]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p65JiZpA014015; Tue, 5 Jul 2011 19:44:35 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: <4E13653F.5090707@gmail.com> Date: Tue, 5 Jul 2011 12:44:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <62E378D1-A373-4715-BF51-68DD8E464ED4@cisco.com> References: <571B7ACD-26B9-4A46-9791-0EA76134A585@cisco.com> <4E0EE3D8.9040500@piuha.net> <4E0F0B53.2080809@gmail.com> <7CDA80AB-6144-4449-86AB-5F659AD97243@cisco.com> <4E13653F.5090707@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-6man-flow-ecmp.all@tools.ietf.org, Jari Arkko , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-6man-flow-ecmp-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: Tue, 05 Jul 2011 19:44:36 -0000 On Jul 5, 2011, at 12:25 PM, Brian E Carpenter wrote: > On 2011-07-06 06:22, Brian Weis wrote: >> Hi Brian C, >>=20 >> On Jul 2, 2011, at 5:13 AM, Brian E Carpenter wrote: >>=20 >>>> If the attacker can provide all of the inputs, and it knows the = tunnel >>>> endpoint flow label calculation, then there doesn't seem to be any = unpredictability.=20 >>> That's correct, and means that if you are concerned about this risk, >>> there needs to be an obfuscation step in the hash algorithm. >>=20 >> Right, but obfuscation is kind of a loaded word. Adding an input to = the hash algorithm that the attacker is unlikely to guess will mitigate = the risk, and this is probably what you meant. >=20 > Yes, I agree and that really belongs in the 3697bis draft, whose Last = Call is > running a bit behind this one. I will come up with some wording before = the > I-D cutoff. That's fine with me. Thanks, Brian Weis >=20 > Brian >=20 >> Brian Weis=20 >>=20 >>>> (The I-D says to see [I-D.ietf-6man-flow-3697bis] for further = discussion=20 >>>> of this threat. I can't seem to find it, but if it's there simply = pointing=20 >>>> to that discussion would be fine too.) >>> I think it would be better to include any additional wording in = 3697bis >>> - can we look at this when we get the security review of that draft? >>> I think Brian W is correct that it needs to be added. >>>=20 >>> Regards >>> Brian Carpenter >>>=20 >>> On 2011-07-02 21:24, Jari Arkko wrote: >>>> Thanks for your review, Brian. I do agree that the issue that you >>>> mention should be explained better. Authors, please suggest some = text. >>>>=20 >>>> Jari >>>>=20 >>>> Brian Weis kirjoitti: >>>>> 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 >>>>> Intermediate systems in a routing system perform load balancing of >>>>> packets between a pair of nodes based on values in the packet. = This >>>>> I-D defines a safe method by which the IPv6 flow label can be one = of >>>>> those values. A necessary condition is that flow labels that have = a >>>>> uniform distribution, and the method is restricting to use by IPv6 >>>>> tunnel endpoints that are more trusted to apply this method to = packets >>>>> they encapsulate. >>>>>=20 >>>>> The Security Considerations section describes a single = availability >>>>> attack, which is an attacker able to "selectively overload a >>>>> particular path". I assume that this can happen if the hash >>>>> calculation of the intermediate systems will send too many packets >>>>> down one path and overload it rather than properly load balancing >>>>> across the paths. The values used by the intermediate system come = from >>>>> packet headers, and the calculation is deterministic. If the flow >>>>> label computed by the tunnel endpoint is included in the = calculation, >>>>> and it is also deterministic, then it seems that an attacker = knowing >>>>> the method used by the tunnel endpoint to create flow labels can >>>>> engage in this attack. That is, the attacker crafting packets that >>>>> will result in the tunnel end point computing one or more flow = labels >>>>> that cause the intermediate system to include in its hash = calculation, >>>>> which results in it routing over the same path. This may be = feasible >>>>> for an informed attacker controlling a suitable size botnet. So = making >>>>> the tunnel endpoint flow label calculation unpredictable would be >>>>> important to stop this attack. >>>>> The I-D recommends computing the flow label according to >>>>> [I-D.ietf-6man-flow-3697bis], and also states in Section 3 that = the >>>>> result "will be hard for a malicious third party to predict". If = so, >>>>> then this attack seems mitigated when the recommendation is taken. = But >>>>> it would be helpful if the Security Considerations could also = mention >>>>> the need for unpredictability, and perhaps also mention how the >>>>> unpredictability is added. As far as I can tell, the = recommendation in >>>>> [I-D.ietf-6man-flow-3697bis] is to build the flow label from = values in >>>>> the packet being encapsulated, which the attacker itself may have >>>>> generated. If the attacker can provide all of the inputs, and it = knows >>>>> the tunnel endpoint flow label calculation, then there doesn't = seem to >>>>> be any unpredictability. (The I-D says to see >>>>> [I-D.ietf-6man-flow-3697bis] for further discussion of this = threat. I >>>>> can't seem to find it, but if it's there simply pointing to that >>>>> discussion would be fine too.) >>>>>=20 >>>>> Other than clarifying how that attack is mitigated I do not see = the >>>>> need for any changes. >>>>> Brian >>>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From weiler+secdir@watson.org Sat Jul 9 06:14:50 2011 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 D2AB021F874D for ; Sat, 9 Jul 2011 06:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9iyFU-ADqjc for ; Sat, 9 Jul 2011 06:14:50 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2295521F86B4 for ; Sat, 9 Jul 2011 06:14:49 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p69DEmoV082918 for ; Sat, 9 Jul 2011 09:14:48 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p69DEmEi082914 for ; Sat, 9 Jul 2011 09:14:48 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 9 Jul 2011 09:14:48 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Sat, 09 Jul 2011 09:14:48 -0400 (EDT) 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: Sat, 09 Jul 2011 13:14:50 -0000 We have two nearly-full telechat agendas, and about half of us have docs on one or both of them. Please check the lists below carefully. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Scott Kelly is next in the rotation. For telechat 2011-07-14 Reviewer LC end Draft Richard Barnes T 2011-07-13 draft-ietf-6man-flow-3697bis-05 Uri Blumenthal T 2011-07-13 draft-ietf-6man-node-req-bis-11 Dave Cridland T 2011-07-13 draft-ietf-intarea-router-alert-considerations-06 Donald Eastlake T 2011-07-14 draft-ietf-mpls-tp-cc-cv-rdi-05 Shawn Emery T 2011-07-11 draft-ietf-mpls-tp-identifiers-06 Phillip Hallam-Baker T 2011-06-14 draft-ietf-dime-local-keytran-11 Julien Laganier T 2011-06-15 draft-ietf-ipfix-configuration-model-09 Matt Lepinski TR2011-03-08 draft-ietf-dime-nat-control-08 David McGrew T 2011-07-08 draft-iesg-rfc1150bis-01 Catherine Meadows T 2011-06-30 draft-ietf-appsawg-rfc3536bis-05 Tim Polk T 2011-06-30 draft-ietf-codec-requirements-04 Vincent Roca T 2011-07-04 draft-ietf-mboned-ssmping-08 Nico Williams T 2011-07-04 draft-ietf-6man-flow-update-07 Larry Zhu T 2011-07-05 draft-ietf-mpls-tp-linear-protection-07 Glen Zorn T 2011-07-05 draft-ietf-mptcp-congestion-05 For telechat 2011-08-11 Reviewer LC end Draft Derek Atkins T 2011-07-04 draft-ietf-roll-of0-15 Alan DeKok T 2011-07-11 draft-ietf-mpls-mldp-recurs-fec-03 Phillip Hallam-Baker T 2011-07-20 draft-ietf-decade-survey-04 Dan Harkins T 2011-07-19 draft-ietf-mboned-mtrace-v2-08 Sam Hartman T 2011-07-19 draft-ietf-msec-gdoi-update-09 Paul Hoffman T 2011-07-20 draft-ietf-opsawg-oam-overview-05 Love Hornquist-Astrand T 2011-07-15 draft-ietf-softwire-dslite-radius-ext-02 Matt Lepinski T 2011-07-13 draft-burgin-ipsec-suiteb-profile-00 Sam Weiler T 2011-07-20 draft-gutmann-cms-hmac-enc-05 Last calls and special requests: Reviewer LC end Draft Rob Austein 2011-07-18 draft-shiomoto-ccamp-switch-programming-05 Tobias Gondrom 2011-08-04 draft-doria-genart-experience-04 Steve Hanna 2011-07-20 draft-ietf-dime-priority-avps-04 Jeffrey Hutzelman 2011-07-22 draft-ietf-p2psip-base-16 Charlie Kaufman 2011-07-19 draft-ietf-dane-use-cases-04 Catherine Meadows R2011-04-13 draft-ietf-speechsc-mrcpv2-24 Russ Mundy 2011-06-30 draft-ietf-karp-design-guide-02 Magnus Nystrom 2011-07-13 draft-polk-local-emergency-rph-namespace-01 Tim Polk 2011-05-11 draft-ietf-vrrp-unified-mib-09 Joe Salowey 2011-05-30 draft-ietf-mpls-lsp-ping-enhanced-dsmap-10 Ondrej Sury 2011-06-30 draft-ietf-sidr-rescerts-provisioning-10 Tina TSOU 2011-04-23 draft-shin-augmented-pake-08 Carl Wallace 2011-07-21 draft-forte-lost-extensions-06 Glen Zorn 2011-06-28 draft-li-pwe3-ms-pw-pon-03 From rbarnes@bbn.com Mon Jul 11 06:17:36 2011 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 1329921F8B64; Mon, 11 Jul 2011 06:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+hqyy0DUOD8; Mon, 11 Jul 2011 06:17:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 661D421F8B3D; Mon, 11 Jul 2011 06:17:35 -0700 (PDT) Received: from [192.1.255.156] (port=57724 helo=col-dhcp-192-1-255-156.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QgGMY-000Odn-QN; Mon, 11 Jul 2011 09:17:27 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jul 2011 09:17:24 -0400 Message-Id: <173612BD-2825-4A21-98C7-CA8BD5639368@bbn.com> To: IETF Discussion , The IESG , secdir@ietf.org, draft-ietf-6man-flow-3697bis@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [secdir] secdir review of draft-ietf-6man-flow-3697bis 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, 11 Jul 2011 13:17:36 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes how end hosts and intermediate nodes should = populate and handle the IPv6 flow label field. The document spends a = fair bit of time discussing security considerations related to the flow = label and its relation to IPsec in particular. Overall, the document = does a thorough job of discussing security considerations, and I don't = think there's anything they've clearly missed. =20 The only request I would have would be for the authors to add a little = more discussion around the "theft of service" threat. It would be = helpful to detail the assumptions/circumstances under which this threat = aries -- namely that networks provide resources based on flow label and = flow label values are set by end hosts. Given the risks that this = document discusses, it might be worth considering a recommendation that = networks SHOULD NOT make resource allocation decisions based on flow = labels without some external means of assurance. Or some similar = warning against making resource decisions on a completely unsecured = field. Also, purely from a terminology perspective, I found the phrase = "unintended service" confusing and less accurate than the "better = service" phrase used in RFC 3697. It might be better to spell this out:=20= " ... an adversary may be able to obtain a class of service that the = network did not intend to provide ... " --Richard From new-work-bounces@ietf.org Tue Jul 5 09:36:39 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C06E11E8173; Tue, 5 Jul 2011 09:36:39 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id CA84E11E8166; Tue, 5 Jul 2011 09:36:37 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110705163637.CA84E11E8166@ietfa.amsl.com> Date: Tue, 5 Jul 2011 09:36:37 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: multipart/mixed; boundary="===============8500198180060452512==" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 11 Jul 2011 08:02:12 -0700 Subject: [secdir] [new-work] WG Review: Home Networks (homenet) 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: Tue, 05 Jul 2011 16:36:39 -0000 --===============8500198180060452512== Content-Type: text/plain; charset="utf-8" A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, July 12, 2011. Home Networks (homenet) ----------------------------------- Current Status: Proposed Working Group Last Edit: Thursday, June 30th, 2011 Chairs: TBD Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Routing Area Technical Advisor: TBD Security Area Technical Advisor: TBD Mailing Lists: General Discussion: fun@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/fun Archive: http://www.ietf.org/mail-archive/web/fun Description of Working Group: This working group focuses on the evolving networking technology within and among relatively small Òresidential homeÓ networks. For example, an obvious trend in home networking is the proliferation of networking technology in an increasingly broad range and number of devices. This evolution in scale and diversity sets some requirements on IETF protocols. Some of the relevant trends include: o Multiple segments: While less complex L3-toplogies involving as few subnets as possible are preferred in home networks for a variety of reasons including simpler management and service discovery, the introduction of more than one subnet into a home network is enough to add complexity that needs to be addressed, and multiple dedicated segments are necessary for some cases. For instance, a common feature in modern home routers in the ability to support both guest and private network segments. Also, link layer networking technology is poised to become more heterogeneous, as networks begin to employ both traditional Ethernet technology and link layers designed for low-powered sensor networks. Finally, similar needs for segmentation may occur in other cases, such as separating building control or corporate extensions from the Internet access network. Different segments may be associated with subnets that have different routing and security policies. o Service providers are deploying IPv6, and support for IPv6 is increasingly available in home gateway devices. While IPv6 resembles IPv4 in many ways, it changes address allocation principles and allows direct IP addressability and routing to devices in the home from the Internet. This is a promising area in IPv6 that has proved challenging in IPv4 with the proliferation of NAT. o End-to-end communication is both an opportunity and a concern as it enables new applications but also exposes nodes in the internal networks to receipt of unwanted traffic from the Internet. Firewalls that restrict incoming connections may be used to prevent exposure, however, this reduces the efficacy of end-to-end connectivity that IPv6 has the potential to restore. Home networks need to provide the tools to handle these situations in a manner accessible to all users of home networks. Manual configuration is rarely, if at all, possible, as the necessary skills and in some cases even suitable management interfaces are missing. The purpose of this working group is to focus on this evolution, in particular as it addresses the introduction of IPv6, by developing an architecture addressing this full scope of requirements: o prefix configuration for routers o managing routing o name resolution o service discovery o network security The task of the group is to produce an architecture document that outlines how to construct home networks involving multiple routers and subnets. This document is expected to apply the IPv6 addressing architecture, prefix delegation, global and ULA addresses, source address selection rules and other existing components of the IPv6 architecture. The architecture document should drive what protocols changes, if any, are necessary. Specific protocol work described below is expected to be within the scope of the working group once the architecture work is complete. However, the group is required to review its charter and milestones with the IESG and IETF community before submitting documents that make protocol changes. It is expected that the group has to discuss some of the below solutions, however, in order to complete the architecture work. The group will apply existing protocols to handle the five requirements above. For prefix configuration, existing protocols are likely sufficient, and at worst may need some small enhancements, such as new options. For automatic routing, it is expected that existing routing protocols can be used as is, however, a new mechanism may be needed in order to turn a selected protocol on by default. For name resolution and service discovery, extensions to existing multicast-based name resolution protocols are needed to enable them to work across subnets. For network security, the group shall document the concept of "advanced security" as a further development of "simple security" from RFC 6092. The main goal of this work is to enable a security policy that adapts to IPv6 threats as they emerge, taking into account not only traffic from the Internet at large, but within and leaving the home network itself. It is expected that the working group will define a set of protocol specifications to accomplish the five requirements from above. However, it is not in the scope of the working group to define entirely new routing protocols or address allocation protocols. As noted, additional options or other small extensions may be necessary to use the existing protocols in these new configuration tasks. The working group shall also not make any changes to IPv6 protocols or addressing architecture. Prefix configuration, routing, and security related work shall not cause any changes that are not backwards compatible to existing IPv6 hosts. There may be host visible changes in the work on naming and discovery protocols, however. In its design, the working group shall also consider security aspects and the impact on manageability. The main focus of the working group is home networks, but the group's results may also find applications in other small networks. The working group will liaise with the relevant IETF working groups. In particular, the group should work closely with the V6OPS working group, review any use or extension of DHCP with the DHC working group, and work with additional DNS requirements with the DNSEXT and DNSOP working groups. If it turns out that additional options are needed for a routing protocol, they will be developed in the appropriate Routing Area working group, with the HOMENET working group providing the architecture and requirements for such enhancements. The working group will also liase with external standards bodies where it is expected that there are normative dependencies between the specifications of the two bodies. It is expected that in the architecture definition stage liaising with the Broadband Forum, DLNA, and UPnP Forum is necessary. Milestones: Jul 2011 Formation of the working group Sep 2011 First WG draft on the architecture Dec 2011 Submission of the architecture draft to the IESG as Informational RFC Dec 2011 Charter re-evaluation based on the architecture work Dec 2011 First WG draft on prefix configuration Dec 2011 First WG draft on routing Jan 2012 First WG draft on name resolution Feb 2012 First WG draft on service discovery Feb 2012 First WG draft on perimeter security Feb 2012 Start of routing related work in the relevant routing area working group, if needed Mar 2012 Submission of the prefix configuration draft to the IESG as Standards Track RFC Apr 2012 Submission of the routing draft to the IESG as Informational RFC Sep 2012 Submission of the name resolution draft to the IESG as Standards Track RFC Nov 2012 Submission of the service discovery draft to the IESG as Standards Track RFC Dec 2012 Submission of the perimeter security draft to the IESG as Informational RFC --===============8500198180060452512== 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 --===============8500198180060452512==-- From new-work-bounces@ietf.org Tue Jul 5 09:46:10 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0324F11E81B7; Tue, 5 Jul 2011 09:46:10 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 2FA4D21F85CD; Tue, 5 Jul 2011 09:46:09 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110705164609.2FA4D21F85CD@ietfa.amsl.com> Date: Tue, 5 Jul 2011 09:46:09 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 11 Jul 2011 08:02:12 -0700 Subject: [secdir] [new-work] WG Review: Recharter of Protocol Independent Multicast (pim) 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: Tue, 05 Jul 2011 16:46:10 -0000 A modified charter has been submitted for the Protocol Independent Multicast (pim) working group in the Routing Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, July 12, 2011. Protocol Independent Multicast (pim) ----------------------------------- Current Status: Active Working Group Last updated: 2011-07-01 Chairs: Mike McBride Stig Venaas Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Adrian Farrel Mailing Lists: General Discussion: pim@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/pim/ Archive: http://www.ietf.org/mail-archive/web/pim/ Description of Working Group The Protocol Independent Multicast (PIM) Working Group has completed the standardization of PIM with RFC 4601. The WG has determined there is additional work to be accomplished and is chartered to standardize extensions to RFC 4601 - Protocol Independent Multicast Version 2 - Sparse Mode. These PIM extensions will involve reliability, resiliency, scalability, management, and security. If L2VPN or L3VPN WGs determine that support for multicast in L2VPNs and/or L3VPNs requires extensions to PIM, then such extensions will be developed within the PIM WG. Additional work on the PIM-BIDIR and BSR drafts may also be necessary by the WG as these drafts progress through Standards Track. The working group has produced MIB modules for PIM in RFC 5060 and RFC 5240. The working group currently has no plans to do further work on management for PIM. If proposals are brought forward to update or extend the existing MIB modules or to develop YANG modules, the working group will be rechartered. The PIM WG will further enhance RFC4601 as an even more scalable, efficient and robust multicast routing protocol, which is capable of supporting thousands of groups, different types of multicast applications, and all major underlying layer-2 subnetwork technologies. We will accomplish these enhancements by submitting drafts, to the IESG, involving reliable pim, pim join attributes and pim authentication. The working group primarily works on extensions to PIM, but may take on work related to IGMP/MLD. There is a significant number of errata that need to be addressed in order to advance RFC4601 to Draft Standard. The PIM WG will correct the errata, as necessary, and update RFC4601. The working group will initiate a new re-chartering effort if it is determined that a Version 3 of PIM is required. Goals and Milestones: Done Hold the first Working Group meeting and discuss the charter and the state of progress on the chartered items. Done Update the PIM-DM version 2 Internet-draft. Go to WG last call. Submision to IESG for considerations as proposed standard. Done Resubmit the latest PIM-SM version 2 specification to IESG for consideration as a proposed standard RFC Done Submit PIM-SM Applicability Statements Done Submit PIMv2 MIB to IESG for consideration as proposed standard. Done Submit updated PIM-SM and PIM-DM internet-drafts, clarifying any inconsistencies or ambiguities in the previous drafts. Done Submit PIM-SM version 2 and PIM-DM version 2 specifications to IESG for consideration as Draft Standards. Done Submit PIMv2 MIB to IESG for consideration as draft standard. Done Ratify new WG charter and milestones Done Submit the BSR spec as a Proposed Standard to the IESG Done Submit the BSR MIB as a Proposed Standard to the IESG Done Submit a generic TLV PIM Join Attribute PS draft to the IESG Done Submit RPF Vector (use of PIM Join Attribute) as PS to the IESG Done Submit a way to authenticate PIM link local messages as PS to the IESG Done Submit an Informational PIM last hop threats document to the IESG Aug 2011 First WG version of udated RFC 4601 Aug 2011 Submit a more reliable PIM solution (refresh reduction) to the IESG Nov 2011 Submit a population count extension to PIM to the IESG Dec 2011 Submit update of RFC 4601 to IESG for advancement to Draft Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From catherine.meadows@nrl.navy.mil Mon Jul 11 12:52:49 2011 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 F063C11E80C6; Mon, 11 Jul 2011 12:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVe+OapATInn; Mon, 11 Jul 2011 12:52:48 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by ietfa.amsl.com (Postfix) with ESMTP id B7F6511E80AB; Mon, 11 Jul 2011 12:52:47 -0700 (PDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id p6BJqjCH005558; Mon, 11 Jul 2011 15:52:46 -0400 (EDT) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id p6BJqhti002009; Mon, 11 Jul 2011 15:52:43 -0400 (EDT) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011071115524331621 ; Mon, 11 Jul 2011 15:52:43 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary=Apple-Mail-8--752622389 Date: Mon, 11 Jul 2011 16:02:22 -0400 Message-Id: To: secdir@ietf.org, iesg@ietf.org, draft-ietf-appsawg-rfc3536bis.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] Secdir review of draft-ietf-appsawg-rfc3536bis-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 19:52:49 -0000 --Apple-Mail-8--752622389 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft provides definitions for a set of terms commonly used in = internationalization in the IETF, that is terms having to do with the = representation of text strings that appear in protocols in different languages, writing systems, and = alphabets. In the security considerations sections the authors point = out that since this draft consists of definitions of terminology having to do with the representation of text strings, it = has only an indirect connection with security in some authentication = methods may rely on the comparison of text strings. However, I don't see anything in the definition of terms = here that would negatively impact the ability to discuss or specify such = security methods, so I don't see any security issues here. One nit, having nothing to do with security: I found the phrase "Internet users must be able to be enter text in typical input methods and displayed in any human language." in the introduction somewhat hard to parse. Does it mean that 1) users = should be able to use any of a set of typical input methods and 2) it should be possible to display the results in any human language, = or that users should be able to enter text from any human language using typical input methods? 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-8--752622389 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 draft provides definitions = for a set of terms commonly used in internationalization in the IETF, = that is terms having to do with the representation of text strings = that
appear in protocols in different languages, writing systems, = and alphabets.  In the security considerations sections the authors = point out that since this draft consists of definitions
of = terminology having to do with the representation of text strings, it has = only an indirect connection with security in some authentication methods = may rely on the comparison of
text strings.  However, I = don't see anything in the definition of terms here that would negatively = impact the ability to discuss or specify such security methods, so I = don't see any
security issues here.

One = nit, having nothing to do with security:  I found the = phrase

"Internet users must be
   able = to be enter text in typical input methods and displayed in = any
   human language."

in = the introduction somewhat hard to parse.  Does it mean that 1) = users should be able to use any of a set of typical input methods = and
2) it should be possible to display the results in any = human language, or that users should be able to enter text from any = human
language using typical input = methods?


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-8--752622389-- From brian.e.carpenter@gmail.com Mon Jul 11 13:54:43 2011 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 0E58C11E8130; Mon, 11 Jul 2011 13:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQdm6d5wT-aR; Mon, 11 Jul 2011 13:54:42 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C96C711E8117; Mon, 11 Jul 2011 13:54:39 -0700 (PDT) Received: by vxi40 with SMTP id 40so4437237vxi.31 for ; Mon, 11 Jul 2011 13:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=993dpZ3mqA6vmypVYVwgRZbr4FNcOi3L+YMEMEsqr7U=; b=DIbZh6g7340vyuYsgzArTkDqmdgAysrIkHOXuGR+PY6gX2kvyQLrj7h+O1hfjJog55 Gd2O8neIb/UNYQ//AT/wC1ZnxEU6mh7Ccu+6NTQUSDY9PGSASQgQl1z6gOjkedKtd/PV aGjaxX92tm2l6F/JcnZ0nK/sj79UARgAQ9kew= Received: by 10.52.99.131 with SMTP id eq3mr789562vdb.51.1310417679283; Mon, 11 Jul 2011 13:54:39 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id dq5sm8294674vbb.16.2011.07.11.13.54.35 (version=SSLv3 cipher=OTHER); Mon, 11 Jul 2011 13:54:38 -0700 (PDT) Message-ID: <4E1B6309.4050008@gmail.com> Date: Tue, 12 Jul 2011 08:54:33 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Richard L. Barnes" References: <173612BD-2825-4A21-98C7-CA8BD5639368@bbn.com> In-Reply-To: <173612BD-2825-4A21-98C7-CA8BD5639368@bbn.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org, draft-ietf-6man-flow-3697bis@tools.ietf.org, IETF Discussion , The IESG Subject: Re: [secdir] secdir review of draft-ietf-6man-flow-3697bis 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, 11 Jul 2011 20:54:43 -0000 Richard, Thanks for the review. On 2011-07-12 01:17, Richard L. Barnes 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 how end hosts and intermediate nodes > should populate and handle the IPv6 flow label field. The > document spends a fair bit of time discussing security > considerations related to the flow label and its relation to > IPsec in particular. Overall, the document does a thorough > job of discussing security considerations, and I don't think > there's anything they've clearly missed. > > The only request I would have would be for the authors to add > a little more discussion around the "theft of service" > threat. It would be helpful to detail the > assumptions/circumstances under which this threat aries -- > namely that networks provide resources based on flow label > and flow label values are set by end hosts. The difficulty about doing this is that (as the WG wanted) we have dropped almost all of the discussion of flow state establishment methods, which is really where these risks arise. To be frank I think that anything we could add would be hand-waving. > Given the risks > that this document discusses, it might be worth considering a > recommendation that networks SHOULD NOT make resource > allocation decisions based on flow labels without some > external means of assurance. Or some similar warning against > making resource decisions on a completely unsecured field. Yes, that makes sense when *not* in the stateless load distribution scenario. > > Also, purely from a terminology perspective, I found the > phrase "unintended service" confusing and less accurate than > the "better service" phrase used in RFC 3697. It might be > better to spell this out: " ... an adversary may be able to > obtain a class of service that the network did not intend to > provide ... " Agreed. However - the I-D cutoff is upon us, so although I will post an update in the next few minutes, I'm afraid these changes will not be made before the IESG telechat. Regards Brian Carpenter From turners@ieca.com Mon Jul 11 14:01:49 2011 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 E1FBC11E81F3 for ; Mon, 11 Jul 2011 14:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.384 X-Spam-Level: X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JW8hfqkzJOQV for ; Mon, 11 Jul 2011 14:01:49 -0700 (PDT) Received: from nm4-vm0.bullet.mail.sp2.yahoo.com (nm4-vm0.bullet.mail.sp2.yahoo.com [98.139.91.190]) by ietfa.amsl.com (Postfix) with SMTP id 2FC2711E816B for ; Mon, 11 Jul 2011 14:01:49 -0700 (PDT) Received: from [98.139.91.61] by nm4.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jul 2011 21:01:46 -0000 Received: from [98.139.91.33] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jul 2011 21:01:46 -0000 Received: from [127.0.0.1] by omp1033.mail.sp2.yahoo.com with NNFMP; 11 Jul 2011 21:01:46 -0000 X-Yahoo-Newman-Id: 724481.10743.bm@omp1033.mail.sp2.yahoo.com Received: (qmail 60283 invoked from network); 11 Jul 2011 21:01:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1310418106; bh=TdUGvhetdTTYAa7588ebYh0mKrSfTmsJE5edGtO6q+Q=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=wG2UNJJ8RBoePUxKAI/dib20iJY0LLcGO6oSsZUdm4mA8c08T49Zt8IM4pvI5PA4jwicEY94eT2+tE5EOhQOqq43Z+GSumpXgv2uxBA2eyMPAmTrOTNdOIYPo3r+RcWFbYR8JayRnNm791zq54L0RfY4zARr2P/05kk7p0v64pE= Received: from thunderfish.westell.com (turners@96.231.118.23 with plain) by smtp115.biz.mail.sp1.yahoo.com with SMTP; 11 Jul 2011 14:01:46 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: xniHbAkVM1kqxffnysbLqDXJgb.EY489eg0ppKJJbg8bgMz n80fu0BiGYjVbRwcdCjJzOTagah2hgicqAZs4PrD95ym0nlAo0KuXH99XU8a ZoHAYpQ6rGcNYQiwosLSXacSe6NKB8wvybGZF7wemdQ2qY2kphKpGcj8rc5Q mXiJsZU5KzyH5FsmGmax.FV2Z4uDeK6ezlSyI5CmtZYUsdUurszASQ4JIvuW N_A7j0SUsnXJNoO1wnovitgVPFSZONWmh.zbQKNROWOx7ZjDfBAQSWDJzRti ulfBGNyVs5yNJAKmkDmVDzIE3xf_b6uZlwwyMFwEr0KwELDEoxULpcQDZ7WI hlVCd18SqLG3kxxEjnTBD.lh66gUEd3EPOIGoIhoka2Y- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4E1B64B8.2020607@ieca.com> Date: Mon, 11 Jul 2011 17:01:44 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Brian E Carpenter References: <173612BD-2825-4A21-98C7-CA8BD5639368@bbn.com> <4E1B6309.4050008@gmail.com> In-Reply-To: <4E1B6309.4050008@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-flow-3697bis@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-6man-flow-3697bis 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, 11 Jul 2011 21:01:50 -0000 On 7/11/11 4:54 PM, Brian E Carpenter wrote: > Richard, > > Thanks for the review. > > On 2011-07-12 01:17, Richard L. Barnes 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 how end hosts and intermediate nodes >> should populate and handle the IPv6 flow label field. The >> document spends a fair bit of time discussing security >> considerations related to the flow label and its relation to >> IPsec in particular. Overall, the document does a thorough >> job of discussing security considerations, and I don't think >> there's anything they've clearly missed. >> >> The only request I would have would be for the authors to add >> a little more discussion around the "theft of service" >> threat. It would be helpful to detail the >> assumptions/circumstances under which this threat aries -- >> namely that networks provide resources based on flow label >> and flow label values are set by end hosts. > > The difficulty about doing this is that (as the WG wanted) we > have dropped almost all of the discussion of flow state > establishment methods, which is really where these risks arise. > To be frank I think that anything we could add would be > hand-waving. > >> Given the risks >> that this document discusses, it might be worth considering a >> recommendation that networks SHOULD NOT make resource >> allocation decisions based on flow labels without some >> external means of assurance. Or some similar warning against >> making resource decisions on a completely unsecured field. > > Yes, that makes sense when *not* in the stateless load > distribution scenario. > >> >> Also, purely from a terminology perspective, I found the >> phrase "unintended service" confusing and less accurate than >> the "better service" phrase used in RFC 3697. It might be >> better to spell this out: " ... an adversary may be able to >> obtain a class of service that the network did not intend to >> provide ... " > > Agreed. > > However - the I-D cutoff is upon us, so although I will post an > update in the next few minutes, I'm afraid these changes will > not be made before the IESG telechat. Plan B, which some people hate, is to write up an RFC editor note (i.e., OLD/NEW) for Jari. spt From brian.e.carpenter@gmail.com Mon Jul 11 14:28:35 2011 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 0BCF321F8EB4; Mon, 11 Jul 2011 14:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.71 X-Spam-Level: X-Spam-Status: No, score=-103.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKHBa7s2+L1Y; Mon, 11 Jul 2011 14:28:34 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0110121F8F63; Mon, 11 Jul 2011 14:28:33 -0700 (PDT) Received: by vws12 with SMTP id 12so4499537vws.31 for ; Mon, 11 Jul 2011 14:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0vnKNnbuWJr2NIb/SM1xc5Ox2FrQh9FltesXt75A0XY=; b=lGsxsszBbygpDw7yJTJryM+97VOHDUcK+1rZqjq4LMzRephCq3krdH+QxjsuZLKY5b /wi20c73O3hmrw0WCkuDu65qtyVuUZMFhJWmqsFZbwzyNah8c8wNIvrdHB/1nNzkEslZ Q04RTKFtsa6wCpJhHXYdDpOPylh8JdGQ2g+mQ= Received: by 10.52.169.1 with SMTP id aa1mr6044249vdc.143.1310419713301; Mon, 11 Jul 2011 14:28:33 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id w16sm2168429vco.29.2011.07.11.14.28.30 (version=SSLv3 cipher=OTHER); Mon, 11 Jul 2011 14:28:32 -0700 (PDT) Message-ID: <4E1B6AFC.9050009@gmail.com> Date: Tue, 12 Jul 2011 09:28:28 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sean Turner References: <173612BD-2825-4A21-98C7-CA8BD5639368@bbn.com> <4E1B6309.4050008@gmail.com> <4E1B64B8.2020607@ieca.com> In-Reply-To: <4E1B64B8.2020607@ieca.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-flow-3697bis@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-6man-flow-3697bis 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, 11 Jul 2011 21:28:35 -0000 On 2011-07-12 09:01, Sean Turner wrote: > On 7/11/11 4:54 PM, Brian E Carpenter wrote: >> Richard, >> >> Thanks for the review. >> >> On 2011-07-12 01:17, Richard L. Barnes 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 how end hosts and intermediate nodes >>> should populate and handle the IPv6 flow label field. The >>> document spends a fair bit of time discussing security >>> considerations related to the flow label and its relation to >>> IPsec in particular. Overall, the document does a thorough >>> job of discussing security considerations, and I don't think >>> there's anything they've clearly missed. >>> >>> The only request I would have would be for the authors to add >>> a little more discussion around the "theft of service" >>> threat. It would be helpful to detail the >>> assumptions/circumstances under which this threat aries -- >>> namely that networks provide resources based on flow label >>> and flow label values are set by end hosts. >> >> The difficulty about doing this is that (as the WG wanted) we >> have dropped almost all of the discussion of flow state >> establishment methods, which is really where these risks arise. >> To be frank I think that anything we could add would be >> hand-waving. >> >>> Given the risks >>> that this document discusses, it might be worth considering a >>> recommendation that networks SHOULD NOT make resource >>> allocation decisions based on flow labels without some >>> external means of assurance. Or some similar warning against >>> making resource decisions on a completely unsecured field. >> >> Yes, that makes sense when *not* in the stateless load >> distribution scenario. >> >>> >>> Also, purely from a terminology perspective, I found the >>> phrase "unintended service" confusing and less accurate than >>> the "better service" phrase used in RFC 3697. It might be >>> better to spell this out: " ... an adversary may be able to >>> obtain a class of service that the network did not intend to >>> provide ... " >> >> Agreed. >> >> However - the I-D cutoff is upon us, so although I will post an >> update in the next few minutes, I'm afraid these changes will >> not be made before the IESG telechat. > > Plan B, which some people hate, is to write up an RFC editor note (i.e., > OLD/NEW) for Jari. We've got two DISCUSSes to handle too; I think it's going to be sufficiently complicated to need a new version. Of course, we'll do what Jari advises... Regards Brian Carpenter From vincent.roca@inrialpes.fr Tue Jul 12 01:07:11 2011 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 1A23121F8EA4; Tue, 12 Jul 2011 01:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.027 X-Spam-Level: X-Spam-Status: No, score=-10.027 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MA0+VZLXxdOu; Tue, 12 Jul 2011 01:07:10 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id 9274821F8E8B; Tue, 12 Jul 2011 01:07:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,520,1304287200"; d="scan'208";a="98392961" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 12 Jul 2011 10:07:07 +0200 From: Vincent Roca Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jul 2011 10:07:07 +0200 Message-Id: To: IESG , secdir@ietf.org, draft-ietf-mboned-ssmping.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] Secdir review of draft-ietf-mboned-ssmping-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: Tue, 12 Jul 2011 08:07:11 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. After having read the security section and several parts of the document, I have noticed several small, easy to fix, incoherencies. More precisely: ** Section 9 says: "The worst case is if the host receiving the unicast Echo = Replies also happens to be joined to the multicast group used." Yes in case of an ASM session, no in case of an SSM session (unless the server is also the SSM source, of course). This should be clarified. ** Section 9 says: "...responding to at most one Echo Request per second." It should be clarified that this is one response per second per = client. BTW, I'm also wondering if there should not be a global rate = limitation, in addition to the per-client rate limitation. ** Section 9 says: "The server SHOULD then only respond to Echo Request messages that have a valid Session ID associated with = the source IP address of the Echo Request." How should the server behave if the Session ID is not valid? This is not clarified whereas this is a critical aspect. ** Section 9 says: Rather than saying "how spoofing can be prevented", I'd rather say "how spoofing can be mitigated" since spoofing is NOT prevented with this approach. Note also that an attacker that is on the path between a client and a server may eavesdrop the traffic, learn a valid Session ID, and if he can use spoofing, he can also continue generating Echo Requests until the Session ID validity period times out... A note may be added to clarify that this is by no means a definite security mechanism. ** Section 9, 2nd paragraph: It's clear that group management is critical with ASM, and that the multicast IP address range used for multicast ping SHOULD be disjoint from those used for data sessions. There is no clear recommendation though. I suggest to add some text here. ** Section 9 says: "The main concern is bandwidth." Is it really "the main concern"? I'm not sure. Disturbing an ASM data session with Echo Response traffic (when feasible) is a serious concern, since Echo Response traffic may be misinterpreted by the receivers. ** Section 3.3: When describing the format of the "Server Response, type 83", there should be a note that a Session ID option SHOULD be included, since this is the only way for a server to communicate this option. ** Section 4, "Client behaviour": must -> MUST in: "If the Server Response contained a Session ID, then it must also include that, with the exact same value, in the Echo Requests." ** Section 5, "Server Behaviour", says: "When the server receives an Echo Request message, it may first = check that the group address and Session ID (if provided) are valid." This is a "MUST"!!! If the Session ID is used, the server has no choice but checking it during the first processing stages. ** Section 5: should -> SHOULD in: "The server should additionally include a Session ID." ** Section 3.2 "Defined options" I didn't find any information for the Session ID format. Is there any recommendation? Is a 16-bit or 32-bit field format recommended? Why? ** Section 5 says: "Note that the server may receive Echo Request messages with no = prior Init message. This may happen when the server restarts or if a client sends an Echo Request with no prior Init message. The = server may go ahead and respond if it is okay with the group used. If = the group is not okay, the server sends back a Server Response." This "may go ahead and respond" is in total contradiction with=20 the security recommendations. Using a Session ID is a "SHOULD", and it is allowed to ignore this recommendation only in rare = circumstances. A few ping requests may fail if the server is restarted, sure, but this will only be a transitory problem, so it's not a big deal.=20 I'm also wondering if the "sends back a Server Response" strategy is appropriate. With this "Response", an attacker that spoofs the IP = address of a target has a way to oblige a server to send back a UDP packet to the target. It's questionable. Regards, Vincent= From turners@ieca.com Tue Jul 12 13:56:04 2011 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 7A08211E8079 for ; Tue, 12 Jul 2011 13:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.616 X-Spam-Level: X-Spam-Status: No, score=-100.616 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQMe9WE9LIMI for ; Tue, 12 Jul 2011 13:56:04 -0700 (PDT) Received: from nm30-vm2.bullet.mail.ne1.yahoo.com (nm30-vm2.bullet.mail.ne1.yahoo.com [98.138.91.130]) by ietfa.amsl.com (Postfix) with SMTP id D359011E8078 for ; Tue, 12 Jul 2011 13:56:03 -0700 (PDT) Received: from [98.138.90.49] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 12 Jul 2011 20:56:00 -0000 Received: from [98.138.89.195] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 12 Jul 2011 20:56:00 -0000 Received: from [127.0.0.1] by omp1053.mail.ne1.yahoo.com with NNFMP; 12 Jul 2011 20:56:00 -0000 X-Yahoo-Newman-Id: 575397.91444.bm@omp1053.mail.ne1.yahoo.com Received: (qmail 50551 invoked from network); 12 Jul 2011 20:56:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1310504160; bh=urvKsp37wTZ5SMj4WJmOSpeHUxUDkv3wpyeO0che0fY=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=wtB7Ps3BYyrTMpgsPfB9YhUHuGIh7gV/7eQ/I9nSPVvw+Cpv/V7QYS/xOONLbsaqrnGb2Kq1qOMaKQZylshb0aFTJGajJy+ShDnNLwGNtaEB9hWDK2C2gjkcAxgQ2XxtetJ9rQoZRGiA5H9j/NCbV62pQjEwsnPl6WnVGvWHr9g= Received: from thunderfish.westell.com (turners@96.231.114.220 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 12 Jul 2011 13:55:59 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: tM4pj.AVM1naonsKY7yiiqsvCYNPer0rn56BpAT4JIKZ1S3 3p9PE.TJS2dgwUVq2t8ojXMO4mMkVOWvztSJrAQf46212KDaoU5x40Z07qQX x4TH5ObwEhVj3xFVGMHVv291HrGeDppD2HqstLBFYGUrZSLUixtcZuHQ5JVh 6npl8DyJrxFACMDSArCgcZ0ml9BKjdK7IzoQMyACl4vGFhEr_tPwzaQLWKBA FXb15BXQ2RDrBIeSsV.HvapQXhptf.2Rz8QhUSYKMbMGG9xA8Fpw184qCAI2 s1B.e7r7S7zX5axkXKL5.ei3xzu15Qb._CfFYD4Xk_cexd2i9ndkIsi054st CPyePNT6J75Fehq79UFcu0fnTg9kGAlnFOrTqqs0_ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4E1CB4DF.70803@ieca.com> Date: Tue, 12 Jul 2011 16:55:59 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: secdir@ietf.org References: <4E0A4728.5060506@ieca.com> In-Reply-To: <4E0A4728.5060506@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [secdir] IETF 81 Security Directorate 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: Tue, 12 Jul 2011 20:56:04 -0000 A rooms has been assigned: Tuesday, July 26 (1130-1300) we'll be in room 303AB. See you there! spt On 6/28/11 5:27 PM, Sean Turner wrote: > All, > > I've requested a room for Tuesday at 11:30 for our normal Security > Directorate Lunch. As soon as I get a room assigned, I'll let you know. > > spt > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From magnusn@gmail.com Tue Jul 12 22:31:12 2011 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 DD2D021F8BE3; Tue, 12 Jul 2011 22:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8J-jzHc0ATZ; Tue, 12 Jul 2011 22:31:12 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E02721F8BDA; Tue, 12 Jul 2011 22:31:12 -0700 (PDT) Received: by gyd5 with SMTP id 5so2666692gyd.31 for ; Tue, 12 Jul 2011 22:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=eb7CvpgOPY9pbiYcJRiFPKYNXD/onYpBlgIGNQw45eo=; b=asV/bko1irH3a0DvHq/cIJmv4eDfUI99/5QUZSJnLrmHD/lXH/aIZMYbKhIi0392iT QmULZog87CprZBu/J5CHIiTSINGqUmgPjkcYiIojnU9yFNvW83rDhGL/qKcT9sp3sAyI yy52a4TSAQbNMdbbpu8y+svGv5tcj0UrW3wtY= MIME-Version: 1.0 Received: by 10.150.188.15 with SMTP id l15mr931345ybf.209.1310535071282; Tue, 12 Jul 2011 22:31:11 -0700 (PDT) Received: by 10.150.143.6 with HTTP; Tue, 12 Jul 2011 22:31:11 -0700 (PDT) Date: Tue, 12 Jul 2011 22:31:11 -0700 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: iesg@ietf.org, secdir@ietf.org, draft-polk-local-emergency-rph-namespace@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [secdir] Secdir review of draft-polk-local-emergency-rph-namespace-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 05:31:13 -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. =A0These 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 establishes a new SIP priority header field for use in local emergency situations. As such, this could constitute an important addition to the SIP resource priority header fields and I assume the document has been appropriately reviewed by the SIP community. The one consideration I had seems already to be reasonably discussed and covered in the document - the possibility of misuse and, through this, disruption of service. One comment/question though: Section 2 states: "The 'esnet' namespace SHOULD only be used in times of an emergency, where at least one end of the signaling is within a local emergency organization" - why is this a "SHOULD" and not a "MUST"? After all, the acronym "esnet" stands for "Emergency Service NETwork". (Also, on the latter part of that sentence - is it really "within" a local emergency organization - should it not be that the initiator is a local emergency org?) -- Magnus From d3e3e3@gmail.com Wed Jul 13 08:51:50 2011 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 E179911E8132; Wed, 13 Jul 2011 08:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.477 X-Spam-Level: X-Spam-Status: No, score=-104.477 tagged_above=-999 required=5 tests=[AWL=-0.878, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mt0lDbR7gunX; Wed, 13 Jul 2011 08:51:50 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A41421F8686; Wed, 13 Jul 2011 08:51:48 -0700 (PDT) Received: by yxp4 with SMTP id 4so3058116yxp.31 for ; Wed, 13 Jul 2011 08:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=gaWsgtT9wf5BF/k3wRLBhy9VY+sv1KC34xqNVYWixgc=; b=HoX8PE+5U/SDdFlEqSdMiybMmBDemBcjFPQ3/POpcwp9mk0Uo+qmgw5gbwfzVTKlyP 0hmpPMxbWgG5sdbfV6ubtYAXjSgXQFMk/PjLiEzp8YlBnpiQEEeASh64I6YYyFXtT3Z/ cKnu33x/SFaPZtUJA+2Mj9ePjRUI4LhkY4t7I= Received: by 10.150.12.9 with SMTP id 9mr1338953ybl.328.1310572308092; Wed, 13 Jul 2011 08:51:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.144.3 with HTTP; Wed, 13 Jul 2011 08:51:28 -0700 (PDT) From: Donald Eastlake Date: Wed, 13 Jul 2011 11:51:28 -0400 Message-ID: To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mpls-tp-cc-cv-rdi.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [secdir] SECDIR review draft-ietf-mpls-tp-cc-cv-rdi-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: Wed, 13 Jul 2011 15:51:51 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. SECURITY The Security Considerations section is brief but covers most of the considerations that specifically occurred to me in reading this draft. In Section 3.5.2 there are various fields that MUST be unique. Are there security consequences if they are not? MINOR A reference to RFC 6291 should probably be included. Section 2.1: CC is not listed. P/F is not listed. Section 3.7.4.1: I believe all the figure numbers in this section are wrong= . EDITORIAL Abstract: "integrity of the continuity" seems redundant. Just "continuity" is better. Abstract: "any loss of continuity defect". So you lost a "continuity defect", did you? Slipper little guys, aren't they? Maybe you mean "any loss-of-continuity defect". Introduction: I don't get the reason for the double references like "[12][12]" and "[13][13]". Introduction: Missing commas: "the same continuity check (CC) proactive continuity verification (CV) and remote defect indication (RDI) capabilities" should be "the same continuity check (CC), proactive continuity verification (CV). and remote defect indication (RDI) capabilities". Section 2.1: This is just a personal preference of mine but I think it is best to explain a little more than you think you need to. So I would include entries for MPLS, OAM, and PDU. Figure 4, Figure 6: There should be a blank line after the Figure label. Figure 5, Figure 7, Figure 8: Figures should not be broken over page bounda= ries. Section 4, Section 6: No blank line before Section header. Section 4: Ends with a list of length 1. List constructs should not be used for lists of length one. Overall: As in many such documents, I believe that acronyms are overused and the document would be improved by more frequently spelling things out. For example, p2p occurs only twice in the document, the first time when it is also spelled out and only one other use. I believe such rarely used acronyms should generally be spelled out for all of their tiny number of uses. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From hallam@gmail.com Wed Jul 13 13:05:40 2011 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 7DC2021F8533; Wed, 13 Jul 2011 13:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrBnQZsuxaIB; Wed, 13 Jul 2011 13:05:36 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id ECD9C21F852B; Wed, 13 Jul 2011 13:05:35 -0700 (PDT) Received: by gwb20 with SMTP id 20so3029609gwb.31 for ; Wed, 13 Jul 2011 13:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=VRm4S1sPOVgMdZ5CSs6/YR3h51e7K7h2lHWN210Ef4M=; b=lPKyfsHFR2g/iuVh35pnLw/yv5KZG2mbkRVn06HGHhWBsUBXKKnXukcydhcWPoxX81 dT20kS83kWAhfyOharMeteLlqGEpdt1OOaJXkzErTqDXc/mOaQQJnMKI9KW1CyJ5zY3l zu9sDx4EB9Kbeeh78n2YLF7jm1fG9e4a6XHwI= MIME-Version: 1.0 Received: by 10.101.145.12 with SMTP id x12mr1502508ann.168.1310587535418; Wed, 13 Jul 2011 13:05:35 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Wed, 13 Jul 2011 13:05:33 -0700 (PDT) Date: Wed, 13 Jul 2011 16:05:33 -0400 Message-ID: From: Phillip Hallam-Baker To: Glen Zorn , sunseawq@huawei.com, violeta.cakulev@alcatel-lucent.com, iesg@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary=0016e68fd02b7ee3be04a7f8f082 Subject: [secdir] SECDIR Review of draft-ietf-dime-local-keytran-11.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: Wed, 13 Jul 2011 20:05:40 -0000 --0016e68fd02b7ee3be04a7f8f082 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. SECURITY There is no substantive security considerations, only a redirect to the previous drafts. This is somewhat problematic given that this is a document defining new formats for key transport. Minor 3.1.4. Key-Lifetime AVP The Key-Lifetime AVP (AVP Code ) is of type Unsigned32 and represents the period of time (in seconds) for which the contents of the Keying-Material AVP (Section 3.1.3) is valid. If the key lifetime is really expected to be 2^32, i.e. 136 years then we should probably expect quite a bit more mechanism here. The delta encoding avoids millennium bug type problems (we.. maybe, it probably just means that code will start to fail in 2032 or so when people start specifying key lifetimes that cause signed 32 bit time to wrap.) but it means that the start of the period is not fixed in time. I think that at a minimum we need to have a security consideration pointing out that there is an issue here. What happens if these messages are proxied or cached in some fashion (OK it may not be in the protocol now, but can we guarantee it never will be?) Its probably not worth fixing since the protocols themselves are full of the same issue but it should be called out as an SC. -- Website: http://hallambaker.com/ --0016e68fd02b7ee3be04a7f8f082 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. Document editors and WG chairs should treat these comments just
li= ke any other last call comments.

SECURITY
There is no substantive security considerations, only a redirect to = the previous drafts.

This is somewhat problematic given that this is a docum= ent defining new formats for key transport.


Minor
3.1.4.  Key-Lifetime AVP
The Key-Lifetime AVP (AVP Code <AC4>) is of type Unsigned32 a= nd represents the period of time = (in seconds) for which the contents of the Keying-Material AVP (Section 3.1.3) is valid.

If the key lifetime is really expected to be 2^32, i.e.= 136 years then we should probably expect quite a bit more mechanism here.<= /div>

The delta encoding avoids=A0millennium=A0bug type = problems (we.. maybe, it probably just means that code will start to fail i= n 2032 or so when people start specifying key lifetimes that cause signed 3= 2 bit time to wrap.) but it means that the start of the period is not fixed= in time.

I think that at a minimum we need to have a security co= nsideration pointing out that there is an issue here. What happens if these= messages are proxied or cached in some fashion (OK it may not be in the pr= otocol now, but can we guarantee it never will be?)

Its probably not worth fixing since the protocols thems= elves are full of the same issue but it should be called out as an SC.


--0016e68fd02b7ee3be04a7f8f082-- From hallam@gmail.com Wed Jul 13 13:21:53 2011 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 63F5C11E80C3; Wed, 13 Jul 2011 13:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7hrKB4lZ-Pp; Wed, 13 Jul 2011 13:21:49 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B6D7811E80E4; Wed, 13 Jul 2011 13:21:48 -0700 (PDT) Received: by gyd5 with SMTP id 5so3029151gyd.31 for ; Wed, 13 Jul 2011 13:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=TfJHlL6/slPIOT7x5LBLNXRJa8DLNMbbwSO5g+Dti2g=; b=MsgwNClRplfE7tpjvcgtWVTrkNBSr4W4ljZetQ+yp/BzhF7YnVgJRkoCNqWAKuo/6V AoPXDfVnxyqtcP/WNUjhQGbJJ2Jh3Cf8ImV2m26sdLtpb1ys7VWzsrTn0wJji/cVHGsI kS3N76u6Hdu81YaBRGcwWPAESSC06wSepILk8= MIME-Version: 1.0 Received: by 10.101.179.7 with SMTP id g7mr1496690anp.102.1310588507510; Wed, 13 Jul 2011 13:21:47 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Wed, 13 Jul 2011 13:21:47 -0700 (PDT) Date: Wed, 13 Jul 2011 16:21:47 -0400 Message-ID: From: Phillip Hallam-Baker To: iesg@ietf.org, secdir@ietf.org, ralimi@google.com, Akbar.Rahman@InterDigital.com, yry@cs.yale.edu Content-Type: multipart/alternative; boundary=001636c926646fd7d204a7f92ad7 Subject: [secdir] draft-ietf-decade-survey-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: Wed, 13 Jul 2011 20:21:53 -0000 --001636c926646fd7d204a7f92ad7 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. SECURITY This is a survey of existing systems and as such does not require a security considerations as there is nothing to build. However, the draft does analyze the security of the existing schemes and as such seems to be looking at this from the point of view of how the systems implement existing security schemes appropriate for file stores. I don't think this is sufficient or particularly useful. I can see outsourced storage being used in various ways: 1) As a filestore replacement 2) As an emergency backup. 3) As a latency reducer Lets leave 3 to one side for a moment. Support for ACLs and such is only really relevant for 1. Local storage is cheap though and my main interest is actually 2 more than 1. A system with no security is fine with me as I can layer whatever security I need on with cryptography. The security problem as I see it then is to do with how the customer and outsourcer interact and issues of the form Customer: Those aren't my bits you gave me! Outsourcer: Oh yes they are! Lawyer1: Prove it! Lawyer 2: Prove it! See where this is headed? Case 3 has an even more tenuous connection between the provider, consumer and storage provider. Do we even have a commitment to support storage of anyone's bits? What are the liabilities if corruption ensues? -- Website: http://hallambaker.com/ --001636c926646fd7d204a7f92ad7 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. Document editors and WG chairs should treat these comments just
li= ke any other last call comments.

SECURITY

This is a survey= of existing systems and as such does not require a security considerations= as there is nothing to build.

However, th= e draft does analyze the security of the existing schemes and as such seems= to be looking at this from the point of view of how the systems implement = existing security schemes appropriate for file stores. I don't think th= is is sufficient or particularly useful.


I can see outsourced storage being = used in various ways:

1) As a fil= estore replacement
2) As an emergency backup.
3) As a latency reducer

Lets leave 3 to one side for a mome= nt.

Support for= ACLs and such is only really relevant for 1. Local storage is cheap though= and my main interest is actually 2 more than 1. A system with no security = is fine with me as I can layer whatever security I need on with cryptograph= y.


The security problem as I see it th= en is to do with how the customer and outsourcer interact and issues of the= form

Customer: T= hose aren't my bits you gave me!
Outsourcer: Oh yes they are!
Lawyer1: Prove it!
Lawyer 2: Prove it!

See where this is headed?


Case 3 has an even more tenuous con= nection between the provider, consumer and storage provider. Do we even hav= e a commitment to support storage of anyone's bits? What are the liabil= ities if corruption ensues?

--001636c926646fd7d204a7f92ad7-- From shawn.emery@oracle.com Thu Jul 14 01:07:58 2011 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 ED2E921F8B48; Thu, 14 Jul 2011 01:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.034 X-Spam-Level: X-Spam-Status: No, score=-3.034 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDg2fsjfpgKq; Thu, 14 Jul 2011 01:07:58 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 6864721F8B47; Thu, 14 Jul 2011 01:07:58 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p6E87t6c016567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Jul 2011 08:07:57 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p6E87sIh012399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jul 2011 08:07:54 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p6E87lci016589; Thu, 14 Jul 2011 03:07:47 -0500 Received: from [10.159.208.14] (/10.159.208.14) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Jul 2011 01:07:47 -0700 Message-ID: <4E1EA3BF.1060604@oracle.com> Date: Thu, 14 Jul 2011 02:07:27 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.17) Gecko/20110618 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4E1EA3DD.00F0:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: draft-ietf-mpls-tp-identifiers.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-mpls-tp-identifiers-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 Jul 2011 08:07:59 -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 standards track draft describes identifiers used in Transport Profile of MultiProtocol Label Switching (MPLS-TP). The security considerations section does exist and states that this draft does not introduce any new security concerns, because it is just an informational model. The section continues that it is the responsibility of the protocol, that consumes the identifier set, to outline the various security issues. I agree with this assertion. General comments: None. Editorial comments: None. Shawn. -- From dharkins@lounge.org Thu Jul 14 12:39:23 2011 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 C63D321F87A2; Thu, 14 Jul 2011 12:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS9sljaEwCDo; Thu, 14 Jul 2011 12:39:23 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 57D0821F8748; Thu, 14 Jul 2011 12:39:23 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id A2CA4A888108; Thu, 14 Jul 2011 12:39:22 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 14 Jul 2011 12:39:22 -0700 (PDT) Message-ID: Date: Thu, 14 Jul 2011 12:39:22 -0700 (PDT) From: "Dan Harkins" To: draft-ietf-mboned-mtrace-v2.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [secdir] secdir review of draft-ietf-mboned-mtrace-v2 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 Jul 2011 19:39:23 -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 draft specifies version 2 of mtrace, a multicast traceroute facility. It provides a way to diagnose some issues with multicast like packet loss and isolation of configuration problems. Each router on the reverse path towards a source adds quite a bit of information to a mtrace2 response and the draft discusses how to diagnose problems using this information. mtrace2 seems like a useful tool and can discover quite a bit about a network. The security considerations deal with the fact that some of that information might be restricted and, in that case, recommends not forwarding mtrace2 into the network and replying appropriately-- administratively prohibited. That seems appropriate. I see no issues with this draft. regards, Dan. From gwz@net-zen.net Fri Jul 15 00:15:37 2011 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 5ED3021F8562 for ; Fri, 15 Jul 2011 00:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZL5n-KO6veor for ; Fri, 15 Jul 2011 00:15:32 -0700 (PDT) Received: from smtpauth18.prod.mesa1.secureserver.net (smtpauth18.prod.mesa1.secureserver.net [64.202.165.31]) by ietfa.amsl.com (Postfix) with SMTP id 77D4B21F855B for ; Fri, 15 Jul 2011 00:15:31 -0700 (PDT) Received: (qmail 26497 invoked from network); 15 Jul 2011 07:15:30 -0000 Received: from unknown (110.168.113.93) by smtpauth18.prod.mesa1.secureserver.net (64.202.165.31) with ESMTP; 15 Jul 2011 07:15:29 -0000 Message-ID: <4E1FE90C.8050001@net-zen.net> Date: Fri, 15 Jul 2011 14:15:24 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: multipart/mixed; boundary="------------030506040702030700000406" Cc: violeta.cakulev@alcatel-lucent.com, sunseawq@huawei.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR Review of draft-ietf-dime-local-keytran-11.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: Fri, 15 Jul 2011 07:15:37 -0000 This is a multi-part message in MIME format. --------------030506040702030700000406 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 7/14/2011 3:05 AM, Phillip Hallam-Baker wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. Document editors and WG chairs should treat these comments just > like any other last call comments. > > SECURITY > > There is no substantive security considerations, only a redirect to the > previous drafts. > > This is somewhat problematic given that this is a document defining new > formats for key transport. If it is problematic then it would be quite helpful to say what exactly the problem is. Has the nature of cryptographic keys or Diameter changed fundamentally since the publication of RFC 4072? If not, what is the problem? > > > Minor > > 3.1.4. Key-Lifetime AVP > > The Key-Lifetime AVP (AVP Code ) is of type Unsigned32 and > represents the period of time (in seconds) for which the contents of the > Keying-Material AVP (Section 3.1.3) is valid. > > If the key lifetime is really expected to be 2^32, i.e. 136 years They are most certainly not. > then > we should probably expect quite a bit more mechanism here. > > The delta encoding avoids millennium bug type problems (we.. maybe, it > probably just means that code will start to fail in 2032 or so when > people start specifying key lifetimes that cause signed 32 bit time to > wrap.) but it means that the start of the period is not fixed in time. > > I think that at a minimum we need to have a security consideration > pointing out that there is an issue here. What happens if these messages > are proxied or cached in some fashion (OK it may not be in the protocol > now, but can we guarantee it never will be?) > > Its probably not worth fixing since the protocols themselves are full of > the same issue but it should be called out as an SC. > > > > -- > Website: http://hallambaker.com/ > --------------030506040702030700000406 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------030506040702030700000406-- From julien.meuric@orange-ftgroup.com Wed Jul 13 08:04:22 2011 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 812B521F86F4 for ; Wed, 13 Jul 2011 08:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+b4Zo9vIX1k for ; Wed, 13 Jul 2011 08:04:22 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 014F421F86E5 for ; Wed, 13 Jul 2011 08:04:22 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DDE9BFC400A; Wed, 13 Jul 2011 17:04:20 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id B4D64FC4009; Wed, 13 Jul 2011 17:04:20 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jul 2011 17:04:20 +0200 Received: from [10.193.71.150] ([10.193.71.150]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jul 2011 17:04:19 +0200 Message-ID: <4E1DB3F3.8080103@orange-ftgroup.com> Date: Wed, 13 Jul 2011 17:04:19 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2011 15:04:19.0921 (UTC) FILETIME=[245D6410:01CC416E] X-Mailman-Approved-At: Fri, 15 Jul 2011 09:47:35 -0700 Cc: Adrian Farrel , 'JP Vasseur' Subject: [secdir] Issue with PCEP 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 Jul 2011 15:04:22 -0000 Dear Security Directorate, In the PCE WG, an issue had been reported by several implementers of PCEP, the "Path Computation Element communication Protocol" specified in RFC 5440 (cf. the thread on http://www.ietf.org/mail-archive/web/pce/current/msg02426.html or http://tools.ietf.org/agenda/80/slides/pce-0.pdf). This issue is related to the fact that the TCP source port of a PCEP session is fixed. To summarize, some operating systems (including Linux) are not that flexible when it comes to assigning a fixed source port. A reasonable solution to this issue is to remove that restriction on the source port of a PCEP session. It is backward compatible with current RFC 5440 and has been agreed with the Tranport Area ADs. From a security perspective, do you issue any blocking issue in moving forward with this solution? Thank you, Julien, PCE co-chair From new-work-bounces@ietf.org Thu Jul 14 14:50:32 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8740821F86EC; Thu, 14 Jul 2011 14:50:32 -0700 (PDT) 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 182B521F86EC for ; Thu, 14 Jul 2011 14:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.74 X-Spam-Level: X-Spam-Status: No, score=-8.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2jo8+6JsPZM for ; Thu, 14 Jul 2011 14:50:30 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 848CD21F86EB for ; Thu, 14 Jul 2011 14:50:30 -0700 (PDT) Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1QhTnf-0007pF-6m; Thu, 14 Jul 2011 17:50:27 -0400 From: Ian Jacobs Date: Thu, 14 Jul 2011 16:50:26 -0500 To: new-work@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 15 Jul 2011 09:47:35 -0700 Subject: [secdir] [new-work] Proposed W3C Charters: Web Application Security WG, Web Security IG (until 2011-08-19) 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 Jul 2011 21:50:32 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Security Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal consists of two new charters: Web Application Security Working Group http://www.w3.org/2011/07/appsecwg-charter.html Web Security Interest Group http://www.w3.org/2011/07/security-ig-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2011-08-19 on the proposed charters. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Sandro Hawke, Team Contact . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/Security/Activity [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From mlepinski@bbn.com Fri Jul 15 13:09:03 2011 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 3110521F8520; Fri, 15 Jul 2011 13:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1u-kHXL-pc2L; Fri, 15 Jul 2011 13:09:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9085821F8514; Fri, 15 Jul 2011 13:09:02 -0700 (PDT) Received: from [128.89.253.98] (port=1180) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qhogx-0008nF-9D; Fri, 15 Jul 2011 16:08:55 -0400 Message-ID: <4E209E78.9040804@bbn.com> Date: Fri, 15 Jul 2011 16:09:28 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: secdir@ietf.org, iesg@ietf.org, draft-burgin-ipsec-suiteb-profile.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Secdir review of draft-burgin-ipsec-suiteb-profile-00 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 Jul 2011 20:09:03 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This informational document defines a profile of behavior that IPsec implementations must adhere in order to be Suite B compliant. The authors claim that this profile does not introduce any new security concerns that are not already covered in existing RFCs on IPsec, IKE, and their use with ECDSA (i.e., RFCs 4303, 4754, 5759, 5996). After reviewing this document, I would agree with this assessment. --------------------- The following are specific comments based on my review of the document: In Section 3, there is a table that includes the heading "IANA assigned DH group #", which is a bit unclear. I would recommend inserting text below the table that indicates the specific IANA registry to which the table refers. In this case, it is the IANA registry of IKEv2 Diffie-Hellman Group Transform IDs (Transform Type 4) ... see http://www.iana.org/assignments/ikev2-parameters In the second paragraph of Section 5, in the context of implementations that are configured with a minimum level of security of 128 bits, the draft has the following text: "Suite-B-GCM-128 and Suite-B-GMAC-128, if offered, must appear in the IKEv2 and IPsec SA payloads before any offerings of Suite-B-GCM-256 and Suite-B-GMAC-256". This appears to be the only lower-case "must" in the document, and lower-case "must" in this type of specification can be confusing to implementers. There seems to be no security or interoperability reason why one would place the 128 suites first. Indeed, the reason for this requirement seems to be to prevent systems with a minimum security level of 128 bits from agreeing on a 256 suite (which I would suppose is for efficiency reasons???). Therefore, I would suggest that the authors replace the lower-case "must" with a capital "SHOULD". Alternatively, if the authors believe that the use of normative language here is inappropriate, then I would recommend rephrasing the sentence so as to avoid the use of the word "must". Since Suite B compliant IPsec implementations use Elliptic Curve Diffe-Hellman for key exchange within IKE, the authors should consider adding a reference to RFC 5903. The IANA considerations section is currently listed as "TBD". I would recommend the authors include a sentence indicating that this document makes no requests of IANA (or else remove the section completely). From hallam@gmail.com Sat Jul 16 18:41:04 2011 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 78E2F21F8541; Sat, 16 Jul 2011 18:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.504 X-Spam-Level: X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKA7Uj3kjZUs; Sat, 16 Jul 2011 18:41:03 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 936C121F84F3; Sat, 16 Jul 2011 18:41:03 -0700 (PDT) Received: by gyd5 with SMTP id 5so1080338gyd.31 for ; Sat, 16 Jul 2011 18:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GSAGFhcs5rWxGr1e/TAlMbRPGHNPUgWNrjAg57igeUU=; b=kXDRWH9kFY3a4jUzmRuYfP2Vu4EFgEY7WDFZ2Ui3+ByWXZ9xCliZ7sr/tFU9Z+yrn1 ZDYTb6RYM3r+DG4UZB+mIXMrEA7dU3vWg0fAsD2ZAP05RMMfHoTaMu1gbhxJ0sKXNtjS CiQsfQ866sNm2d1IatXGZ41p90ikvrc0ihshs= MIME-Version: 1.0 Received: by 10.101.175.36 with SMTP id c36mr4458682anp.93.1310866862372; Sat, 16 Jul 2011 18:41:02 -0700 (PDT) Received: by 10.100.134.9 with HTTP; Sat, 16 Jul 2011 18:41:02 -0700 (PDT) In-Reply-To: <4E1FE90C.8050001@net-zen.net> References: <4E1FE90C.8050001@net-zen.net> Date: Sat, 16 Jul 2011 21:41:02 -0400 Message-ID: From: Phillip Hallam-Baker To: Glen Zorn Content-Type: multipart/alternative; boundary=001636c5be69adf7f304a839f972 Cc: violeta.cakulev@alcatel-lucent.com, sunseawq@huawei.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR Review of draft-ietf-dime-local-keytran-11.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, 17 Jul 2011 01:41:04 -0000 --001636c5be69adf7f304a839f972 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 15, 2011 at 3:15 AM, Glen Zorn wrote: > Minor > > > > 3.1.4. Key-Lifetime AVP > > > > The Key-Lifetime AVP (AVP Code ) is of type Unsigned32 and > > represents the period of time (in seconds) for which the contents of the > > Keying-Material AVP (Section 3.1.3) is valid. > > > > If the key lifetime is really expected to be 2^32, i.e. 136 years > > They are most certainly not. Then maybe stating which parties might be expected to set limits and what might be expected? What happens if someone specifies a bizarrely long expiry on a credential expected to expire in hours or days? Does that allow for an attack? -- Website: http://hallambaker.com/ --001636c5be69adf7f304a839f972 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jul 15, 2011 at 3:15 AM, Glen Zorn <gwz@net-zen.net> wrote:

> Minor
>
> 3.1.4. =A0Key-Lifetime AVP
>
> The Key-Lifetime AVP (AVP Code <AC4>) is of type Unsigned32 and<= br> > represents the period of time (in seconds) for which the contents of t= he
> Keying-Material AVP (Section 3.1.3) is valid.
>
> If the key lifetime is really expected to be 2^32, i.e. 136 years

They are most certainly not.

Then may= be stating which parties might be expected to set limits and what might be = expected?

What happens if someone specifies a biza= rrely long expiry on a credential expected to expire in hours or days? Does= that allow for an attack?



--
Website: http://hallambaker.com/

--001636c5be69adf7f304a839f972-- From gwz@net-zen.net Sun Jul 17 03:49:46 2011 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 AFDBD21F876F for ; Sun, 17 Jul 2011 03:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBytUTKWMXDl for ; Sun, 17 Jul 2011 03:49:46 -0700 (PDT) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by ietfa.amsl.com (Postfix) with SMTP id 1AFE321F8762 for ; Sun, 17 Jul 2011 03:49:46 -0700 (PDT) Received: (qmail 7738 invoked from network); 17 Jul 2011 10:49:45 -0000 Received: from unknown (124.120.11.158) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 17 Jul 2011 10:49:44 -0000 Message-ID: <4E22BE3C.40308@net-zen.net> Date: Sun, 17 Jul 2011 17:49:32 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4E1FE90C.8050001@net-zen.net> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: multipart/mixed; boundary="------------080009060008050205040806" Cc: violeta.cakulev@alcatel-lucent.com, sunseawq@huawei.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR Review of draft-ietf-dime-local-keytran-11.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, 17 Jul 2011 10:49:46 -0000 This is a multi-part message in MIME format. --------------080009060008050205040806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 7/17/2011 8:41 AM, Phillip Hallam-Baker wrote: > On Fri, Jul 15, 2011 at 3:15 AM, Glen Zorn > wrote: > > > Minor > > > > 3.1.4. Key-Lifetime AVP > > > > The Key-Lifetime AVP (AVP Code ) is of type Unsigned32 and > > represents the period of time (in seconds) for which the contents > of the > > Keying-Material AVP (Section 3.1.3) is valid. > > > > If the key lifetime is really expected to be 2^32, i.e. 136 years > > They are most certainly not. > > > Then maybe stating which parties might be expected to set limits and > what might be expected? Suggestions? I'm inclined to believe that this sort of thing would be better discussed in the documents defining the usage, derivation, etc. of the keys themselves but I'm flexible. > > What happens if someone specifies a bizarrely long expiry on a > credential expected to expire in hours or days? Does that allow for an > attack? None I can think off-hand. You? > > > > -- > Website: http://hallambaker.com/ > --------------080009060008050205040806 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------080009060008050205040806-- From paul.hoffman@vpnc.org Mon Jul 18 07:57:14 2011 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 C999721F8C7B for ; Mon, 18 Jul 2011 07:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.648 X-Spam-Level: X-Spam-Status: No, score=-102.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCbTXT6TZmYU for ; Mon, 18 Jul 2011 07:57:14 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1899521F8C78 for ; Mon, 18 Jul 2011 07:57:13 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6IEuxPb066388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Jul 2011 07:57:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jul 2011 07:57:11 -0700 Message-Id: <4CB7AC0B-8A39-49C5-9F88-EF54FA376148@vpnc.org> To: secdir Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-opsawg-oam-overview@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-opsawg-oam-overview 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 Jul 2011 14:57:14 -0000 Greetings. I am the Secdir reviewer for draft-ietf-opsawg-oam-overview. = I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. This draft is a comprehensive list of the protocols used for operations, = administration, and maintenance of many IETF and non-IETF protocols = (basically: monitoring link status). The descriptions go into detail = about how each OAM mechanism is used in combination with the protocol it = monitors. The security considerations section reads, in its entirety: There are no security implications imposed by this document. That is probably sufficient, assuming that every OAM mechanism listed = does not expose any traffic to the administrator. However, it seems = likely that some of the mechanisms might also allow link maintenance, = such as turning off some links and starting up others. If that is the = case, then this document absolutely needs a discussion of authentication = and authorization; if it is not the case, then the NOOP for security = considerations is reasonable. --Paul Hoffman From bew@cisco.com Mon Jul 18 14:11:02 2011 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 DE91B21F86BE for ; Mon, 18 Jul 2011 14:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.266 X-Spam-Level: X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=-2.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnG8Ct3vTHli for ; Mon, 18 Jul 2011 14:10:59 -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 0DD3221F871E for ; Mon, 18 Jul 2011 14:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=1767; q=dns/txt; s=iport; t=1311023459; x=1312233059; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=XwnClC1S9BdiftPDItkXj9+xWpDyDfqJCSfb8KNWa3Y=; b=ChVHiW91T/Tx3mpY9hB66f0kLKx7gcjSWYtQ2KY8f18fofTGV4li3Xbn tg7p/uSwGjoe6GBLtbf+QxepinhFSF6dlvPvOHk0ACNIx5u3ZnvfF7SPT yOedbTNdTHLtuRudbQcrt2lmT3sjmRIzeci8/k6A8vPfpNQxMyqUv32kn s=; X-IronPort-AV: E=Sophos;i="4.67,223,1309737600"; d="scan'208";a="4111136" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-9.cisco.com with ESMTP; 18 Jul 2011 21:10:58 +0000 Received: from dhcp-128-107-147-1.cisco.com (dhcp-128-107-147-1.cisco.com [128.107.147.1]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6ILAv46000909; Mon, 18 Jul 2011 21:10:57 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: <4E1DB3F3.8080103@orange-ftgroup.com> Date: Mon, 18 Jul 2011 14:10:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <18246681-469A-4EF9-A3CB-C6DBC092473F@cisco.com> References: <4E1DB3F3.8080103@orange-ftgroup.com> To: Julien Meuric X-Mailer: Apple Mail (2.1084) Cc: Adrian Farrel , 'JP Vasseur' , secdir@ietf.org Subject: Re: [secdir] Issue with PCEP 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 Jul 2011 21:11:03 -0000 Hi Julien, It's not clear to me that there would be any security issue with = relaxing this restriction. A PCE application should be concerned with = accepting only PCE sessions from authorized peers, and should apply = integrity protection to the segments to ensure that only segments from = those peers are accepted, but restricting the source port number for the = TCP segments received from authorized peers doesn't seem particularly = valuable to me. Hope that helps, Brian On Jul 13, 2011, at 8:04 AM, Julien Meuric wrote: > Dear Security Directorate, >=20 > In the PCE WG, an issue had been reported by several implementers of = PCEP, the "Path Computation Element communication Protocol" specified in = RFC 5440 (cf. the thread on = http://www.ietf.org/mail-archive/web/pce/current/msg02426.html or = http://tools.ietf.org/agenda/80/slides/pce-0.pdf). >=20 > This issue is related to the fact that the TCP source port of a PCEP = session is fixed. To summarize, some operating systems (including Linux) = are not that flexible when it comes to assigning a fixed source port. >=20 > A reasonable solution to this issue is to remove that restriction on = the source port of a PCEP session. It is backward compatible with = current RFC 5440 and has been agreed with the Tranport Area ADs. >=20 > =46rom a security perspective, do you issue any blocking issue in = moving forward with this solution? >=20 > Thank you, >=20 > Julien, PCE co-chair >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From paul.hoffman@vpnc.org Mon Jul 18 16:28:29 2011 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 0408F21F893C for ; Mon, 18 Jul 2011 16:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.645 X-Spam-Level: X-Spam-Status: No, score=-102.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0dh7enM0vFb for ; Mon, 18 Jul 2011 16:28:28 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 43C1321F88DC for ; Mon, 18 Jul 2011 16:28:28 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6INS8Mt087532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Jul 2011 16:28:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <74470498B659FA4687F0B0018C19A89C01223E660FDD@IL-MB01.marvell.com> Date: Mon, 18 Jul 2011 16:28:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CB7AC0B-8A39-49C5-9F88-EF54FA376148@vpnc.org> <74470498B659FA4687F0B0018C19A89C01223E660FDD@IL-MB01.marvell.com> To: Tal Mizrahi X-Mailer: Apple Mail (2.1084) Cc: "draft-ietf-opsawg-oam-overview@tools.ietf.org" , secdir , "nurit.sprecher@nsn.com" , "opsawg-chairs@tools.ietf.org" , "elisa.bellagamba@ericsson.com" , "yaacov.weingarten@nsn.com" Subject: Re: [secdir] Secdir review of draft-ietf-opsawg-oam-overview 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 Jul 2011 23:28:29 -0000 On Jul 18, 2011, at 4:17 PM, Tal Mizrahi wrote: > I understand your point. > I think we can add a general description (1-2 paragraphs) of the = security threats in OAM protocols, and list the security mechanisms = defined in the protocols discussed in this document. > I don't think we want to go into a detailed security threat analysis = of EACH of the OAM protocols described in the document, since it is not = really the scope of this document. A short list in the Security Considerations section saying briefly what = each OAM protocol currently has for security (even if it is "well, um, = none") should be fine for a "catalog" document such as this. --Paul Hoffman From talmi@marvell.com Mon Jul 18 16:17:16 2011 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 81CE721F875E for ; Mon, 18 Jul 2011 16:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8YhUTK816In for ; Mon, 18 Jul 2011 16:17:16 -0700 (PDT) Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by ietfa.amsl.com (Postfix) with ESMTP id 9F86121F8733 for ; Mon, 18 Jul 2011 16:17:15 -0700 (PDT) From: Tal Mizrahi To: Paul Hoffman , secdir Date: Tue, 19 Jul 2011 02:17:11 +0300 Thread-Topic: Secdir review of draft-ietf-opsawg-oam-overview Thread-Index: AcxFWwXkhLpuFNgGSQy0mXeB/f3hOwARG8rw Message-ID: <74470498B659FA4687F0B0018C19A89C01223E660FDD@IL-MB01.marvell.com> References: <4CB7AC0B-8A39-49C5-9F88-EF54FA376148@vpnc.org> In-Reply-To: <4CB7AC0B-8A39-49C5-9F88-EF54FA376148@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 19 Jul 2011 06:14:39 -0700 Cc: "draft-ietf-opsawg-oam-overview@tools.ietf.org" , "opsawg-chairs@tools.ietf.org" , "elisa.bellagamba@ericsson.com" , "nurit.sprecher@nsn.com" , "yaacov.weingarten@nsn.com" Subject: Re: [secdir] Secdir review of draft-ietf-opsawg-oam-overview 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 Jul 2011 23:17:16 -0000 Hi Paul, I understand your point. I think we can add a general description (1-2 paragraphs) of the security t= hreats in OAM protocols, and list the security mechanisms defined in the pr= otocols discussed in this document. I don't think we want to go into a detailed security threat analysis of EAC= H of the OAM protocols described in the document, since it is not really th= e scope of this document. Please let me know if my suggestion makes sense. Thanks, Tal. -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 Sent: Monday, July 18, 2011 7:57 AM To: secdir Cc: draft-ietf-opsawg-oam-overview@tools.ietf.org Subject: Secdir review of draft-ietf-opsawg-oam-overview Greetings. I am the Secdir reviewer for draft-ietf-opsawg-oam-overview. I h= ave reviewed this document as part of the security directorate's ongoing ef= fort to review all IETF documents being processed by the IESG. These comme= nts were written primarily for the benefit of the security area directors. = Document editors and WG chairs should treat these comments just like any o= ther last call comments. This draft is a comprehensive list of the protocols used for operations, ad= ministration, and maintenance of many IETF and non-IETF protocols (basicall= y: monitoring link status). The descriptions go into detail about how each = OAM mechanism is used in combination with the protocol it monitors. The security considerations section reads, in its entirety: There are no security implications imposed by this document. That is probably sufficient, assuming that every OAM mechanism listed does = not expose any traffic to the administrator. However, it seems likely that = some of the mechanisms might also allow link maintenance, such as turning o= ff some links and starting up others. If that is the case, then this docume= nt absolutely needs a discussion of authentication and authorization; if it= is not the case, then the NOOP for security considerations is reasonable. --Paul Hoffman From julien.meuric@orange-ftgroup.com Tue Jul 19 01:43:20 2011 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 4CE3821F8784 for ; Tue, 19 Jul 2011 01:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.209 X-Spam-Level: X-Spam-Status: No, score=-102.209 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySZ9+zTH7DN5 for ; Tue, 19 Jul 2011 01:43:19 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7164B21F8782 for ; Tue, 19 Jul 2011 01:43:19 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0DFF28B8008; Tue, 19 Jul 2011 10:44:06 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 03D5B8B8002; Tue, 19 Jul 2011 10:44:06 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Jul 2011 10:43:17 +0200 Received: from [10.193.71.247] ([10.193.71.247]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Jul 2011 10:43:17 +0200 Message-ID: <4E2543A5.4010805@orange-ftgroup.com> Date: Tue, 19 Jul 2011 10:43:17 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Brian Weis References: <4E1DB3F3.8080103@orange-ftgroup.com> <18246681-469A-4EF9-A3CB-C6DBC092473F@cisco.com> In-Reply-To: <18246681-469A-4EF9-A3CB-C6DBC092473F@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Jul 2011 08:43:17.0866 (UTC) FILETIME=[E7FF24A0:01CC45EF] X-Mailman-Approved-At: Tue, 19 Jul 2011 06:14:39 -0700 Cc: Adrian Farrel , 'JP Vasseur' , secdir@ietf.org Subject: Re: [secdir] Issue with PCEP 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, 19 Jul 2011 08:43:20 -0000 Hi Brian. At this stage, we do not look for a deeper security analysis. Your answer is actually helpful, so thank you for your valuable feedback. Cheers, Julien Le 18/07/2011 23:10, Brian Weis a écrit : > Hi Julien, > > It's not clear to me that there would be any security issue with relaxing this restriction. A PCE application should be concerned with accepting only PCE sessions from authorized peers, and should apply integrity protection to the segments to ensure that only segments from those peers are accepted, but restricting the source port number for the TCP segments received from authorized peers doesn't seem particularly valuable to me. > > Hope that helps, > Brian > > On Jul 13, 2011, at 8:04 AM, Julien Meuric wrote: > >> Dear Security Directorate, >> >> In the PCE WG, an issue had been reported by several implementers of PCEP, the "Path Computation Element communication Protocol" specified in RFC 5440 (cf. the thread on http://www.ietf.org/mail-archive/web/pce/current/msg02426.html or http://tools.ietf.org/agenda/80/slides/pce-0.pdf). >> >> This issue is related to the fact that the TCP source port of a PCEP session is fixed. To summarize, some operating systems (including Linux) are not that flexible when it comes to assigning a fixed source port. >> >> A reasonable solution to this issue is to remove that restriction on the source port of a PCEP session. It is backward compatible with current RFC 5440 and has been agreed with the Tranport Area ADs. >> >> From a security perspective, do you issue any blocking issue in moving forward with this solution? >> >> Thank you, >> >> Julien, PCE co-chair >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir > From shanna@juniper.net Wed Jul 20 19:37:08 2011 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 5328F21F8B06; Wed, 20 Jul 2011 19:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQbtDk+FeD00; Wed, 20 Jul 2011 19:37:07 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 704F821F8B05; Wed, 20 Jul 2011 19:37:07 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTieQxaRWZvGw0gkGdNJG2xijf/9dLUd9@postini.com; Wed, 20 Jul 2011 19:37:07 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 20 Jul 2011 19:36:02 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 20 Jul 2011 22:36:02 -0400 From: Stephen Hanna To: "ietf@ietf.org" , "secdir@ietf.org" , "draft-ietf-dime-priority-avps.all@tools.ietf.org" Date: Wed, 20 Jul 2011 22:36:01 -0400 Thread-Topic: Secdir review of draft-ietf-dime-priority-avps-04 Thread-Index: AcxHTu34hXvg7biARZewSRVBSgbUbw== 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 Subject: [secdir] Secdir review of draft-ietf-dime-priority-avps-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: Thu, 21 Jul 2011 02:37:08 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This standards track document defines Diameter AVPs that can be used to convey a variety of priority parameters. While the Security Considerations section of this document properly requires that implementers review the Security Considerations section in the Diameter protocol specification and consider the issues described there, it does not include any analysis of the specific security issues related to priority systems. The authors should review other Security Considerations sections relating to priority systems (e.g. the one in RFC 4412) and add text that describes the special security issues that arise with priority systems and the countermeasures that may be employed. Thanks, Steve From turners@ieca.com Sun Jul 24 10:04:09 2011 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 C8CC221F8A64 for ; Sun, 24 Jul 2011 10:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.469 X-Spam-Level: X-Spam-Status: No, score=-101.469 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_05=-1.11, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Xt44UMm3+9o for ; Sun, 24 Jul 2011 10:04:09 -0700 (PDT) Received: from nm2.access.bullet.mail.mud.yahoo.com (nm2.access.bullet.mail.mud.yahoo.com [66.94.237.203]) by ietfa.amsl.com (Postfix) with SMTP id 463E321F8A57 for ; Sun, 24 Jul 2011 10:04:09 -0700 (PDT) Received: from [66.94.237.197] by nm2.access.bullet.mail.mud.yahoo.com with NNFMP; 24 Jul 2011 17:04:09 -0000 Received: from [98.139.221.60] by tm8.access.bullet.mail.mud.yahoo.com with NNFMP; 24 Jul 2011 17:04:09 -0000 Received: from [127.0.0.1] by smtp101.biz.mail.bf1.yahoo.com with NNFMP; 24 Jul 2011 17:04:08 -0000 X-Yahoo-Newman-Id: 950545.79271.bm@smtp101.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: WJgpLKEVM1kHk77r9x30L97tAruuIJWB0jno1H_Yal3aOCN qx6ZNWW4skssJFAcflJ7tvgv3HDt3lS6gbr19FwzU7jEbpwCM1T.iYXRmWlB Kgt2iZM4yiw.f.UjfifHgn7zs0zHRmU4oguk36PX5G.0BJclySnI9C12qLNv makA.kVYhSyTGmO3L2oWg5cqQ_gvirvpai8ojrfr7kJt5qs7DxxrOEK1zra. elQfT9yn9Eebed48jWhNJek1cDD6Bs0NeewZgLJm2.OD2Vo1y3KW24D_pNly UZPAzMrF5rKSChoS0q5239krdHExBdw79W_ZSM_7W0b04QCUp32gxI4vv5ee lcgxeFRF68EAQdj44.Tp0uEsWduaTcJALKJgHQLaAtsMOAOmJ10Q2WXJxPgO Rt.HZBIsx0M_OLGTDVnJWxI5i7REQFReEjgDhrbOwsbRZqTRcfAZyJBOtFeo oYA-- X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from dhcp-1598.meeting.ietf.org (turners@198.180.150.230 with plain) by smtp101.biz.mail.bf1.yahoo.com with SMTP; 24 Jul 2011 10:04:08 -0700 PDT Message-ID: <4E2C5087.20201@ieca.com> Date: Sun, 24 Jul 2011 13:04:07 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] tcpcrypt presentation at TSVArea 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, 24 Jul 2011 17:04:09 -0000 Stephen and I are booked during the Thursday morning session and are hoping that somebody could attend TSVAREA meeting (in 205 ABC) to follow along on the discussion about: http://datatracker.ietf.org/doc/draft-bittau-tcp-crypt/ It was described as BTNS for TCP ;) I sent something to SAAG about this draft back in May, and got a couple of comments on it. spt From turners@ieca.com Sun Jul 24 12:29:55 2011 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 BF7C721F8AD1 for ; Sun, 24 Jul 2011 12:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.198 X-Spam-Level: X-Spam-Status: No, score=-102.198 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAziGpX5PiLd for ; Sun, 24 Jul 2011 12:29:55 -0700 (PDT) Received: from nm4.bullet.mail.sp2.yahoo.com (nm4.bullet.mail.sp2.yahoo.com [98.139.91.74]) by ietfa.amsl.com (Postfix) with SMTP id 1E57E21F8891 for ; Sun, 24 Jul 2011 12:29:55 -0700 (PDT) Received: from [98.139.91.62] by nm4.bullet.mail.sp2.yahoo.com with NNFMP; 24 Jul 2011 19:29:55 -0000 Received: from [98.139.91.29] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 24 Jul 2011 19:29:55 -0000 Received: from [127.0.0.1] by omp1029.mail.sp2.yahoo.com with NNFMP; 24 Jul 2011 19:29:55 -0000 X-Yahoo-Newman-Id: 50024.42645.bm@omp1029.mail.sp2.yahoo.com Received: (qmail 91784 invoked from network); 24 Jul 2011 19:29:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311535795; bh=is1URr5z9/KjOZOEVKWlzY63MaQKMSJjmSqkw1RZaSo=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Forwarded-Message-Id:Content-Type:Content-Transfer-Encoding; b=pGTjvPQlAtz/5Ev8ORgIhIv5Q0b5Q/1Y4EN+sk/xonK2pXDdXBQTFTavLcxcb2mBT15RL/q5FA3TkXIGD5ao4sTojvq43ofjO9fQQaup7ajGAKWlwu1mwa7+U7t9cI8NeRwQnrRzQB+j8jQaV7tyuC2UgnBb4jnwjCltUvXvj3s= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: nRGDWn4VM1lzc2W1J2rwDXLELGUCE5wOIY9POYj_cBI4m0U ezPfimzQ22plT69LU2O2IwNXFNJRbF0WhgMsdkZ0Zkxq7srO.O6NFu6lnbGV P9xFZZnk5m4ADuePg49L9Vn0T8HJDg.9F7qDsiitNhAQ68af28eFFw4_eeT1 NnpJUaJ_Wql_MX.LWcgLJVRUmjl33Wezr.nx8DGk69jB2Fp9dpPXEdjither 6aeBvZZZA1WNogsk8SV_V6s8jVc.1oI_1Vd0.cgBuaxFpW3N44C41pj5HXPL rst6wAJSR0d68RF4B9JFWGnt.bANVmANyHv9yp6F2wSwYliYPp6ICOH3_C3. xg338yz5TXabhq4nFbRJlhUpByLvL_nldD8bpAALf X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from dhcp-1598.meeting.ietf.org (turners@198.180.150.230 with plain) by smtp114.biz.mail.sp1.yahoo.com with SMTP; 24 Jul 2011 12:29:54 -0700 PDT Message-ID: <4E2C72B1.3000306@ieca.com> Date: Sun, 24 Jul 2011 15:29:53 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: secdir@ietf.org References: <20110724192756.94B4B21F8A91@ietfa.amsl.com> In-Reply-To: <20110724192756.94B4B21F8A91@ietfa.amsl.com> X-Forwarded-Message-Id: <20110724192756.94B4B21F8A91@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Fwd: [81all] IETF 81 - Information 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, 24 Jul 2011 19:29:55 -0000 FYI - in case you want to grab something quickly.... -------- Original Message -------- Subject: [81all] IETF 81 - Information Date: Sun, 24 Jul 2011 12:27:56 -0700 (PDT) From: IETF Secretariat To: 81all@ietf.org The Quebec City Convention Centre (QCCC) will offer a cash and carry lunch option at the venue in Hall 2000. The lunch will currently be offered only on Monday and Tuesday. We do have an option to continue into the week if it is highly used. The menu and prices are located on the main IETF 81 web page at http://www.ietf.org/meeting/81/index.html under "Venue and Area Information", click on "Cash & Carry Lunch". The terminal room, located in Room 2000 D, will have 24 hour access. Please note that in order to enter the QCCC you will need to present your IETF badge to enter the building, especially during the hours of 20:00 - 08:00. Also a reminder that we have a meeting wiki available here for all attendees: http://www.ietf.org/registration/MeetingWiki/wiki/ietf81. No login is required to view information but to add content you need to login with your username (email address used when registering) and password (initially your 10-digit confirmation code). We hope that you will contribute recommendations as the week progresses. _______________________________________________ 81all mailing list 81all@ietf.org https://www.ietf.org/mailman/listinfo/81all From jhutz@cmu.edu Mon Jul 25 09:15:47 2011 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 E6BD421F8C21 for ; Mon, 25 Jul 2011 09:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34uHIVh+q3b8 for ; Mon, 25 Jul 2011 09:15:47 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 94DFB21F8E8F for ; Mon, 25 Jul 2011 08:30:35 -0700 (PDT) Received: from [66.233.146.161] (66-233-146-161.pit.clearwire-wmx.net [66.233.146.161] (may be forged)) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p6PFUUH1003364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jul 2011 11:30:32 -0400 (EDT) From: Jeffrey Hutzelman To: Sean Turner In-Reply-To: <28322_1311527061_p6OH4KWU007759_4E2C5087.20201@ieca.com> References: <28322_1311527061_p6OH4KWU007759_4E2C5087.20201@ieca.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 25 Jul 2011 11:30:28 -0400 Message-ID: <1311607828.2993.22.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: secdir@ietf.org Subject: Re: [secdir] tcpcrypt presentation at TSVArea 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, 25 Jul 2011 16:15:48 -0000 On Sun, 2011-07-24 at 13:04 -0400, Sean Turner wrote: > Stephen and I are booked during the Thursday morning session and are > hoping that somebody could attend TSVAREA meeting (in 205 ABC) to follow > along on the discussion about: > > http://datatracker.ietf.org/doc/draft-bittau-tcp-crypt/ > > It was described as BTNS for TCP ;) I sent something to SAAG about this > draft back in May, and got a couple of comments on it. BTNS for TCP sounds like useful thing, but in what way does TLS with anonymous DH not fill that need? From stephen.farrell@cs.tcd.ie Mon Jul 25 12:18:44 2011 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 8DB9521F8748 for ; Mon, 25 Jul 2011 12:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGLQbchuw1Xm for ; Mon, 25 Jul 2011 12:18:43 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id C4C2621F8726 for ; Mon, 25 Jul 2011 12:18:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E447E171DD1 for ; Mon, 25 Jul 2011 20:18:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1311621513; bh=2KU0O5En0pabIRZUOt8GOmJa VUJpQnGV19l9ABWleBk=; b=6E+boaI24ApA3/sLrq/wAqRw822SlNmqErSytiGW VfFfr186pj+INT5vuus3B5sTcUpir9roGTPgzSYSUNXURsY6VOSG7MFvL3eDqBbz Xsi89ugjcHxTgiA/QW/EWaI+OQ1w5Q5glDEPHlX0qclh1xBs6d7fQ6r4X18VG/aO 6GL/bqccglLWAT5ibQR+qNZ6TM42HGr0y/Q6zdtbbVsLSF0AzF++QYmkD58NVyNA 8KcbFBR/rS/wvTv9W2dtWpzLeH9bgVQt9kC2YuZrplPhIZXAp2DzIYG1btFpLSt/ JGORnrNzzeUkZsqKCbCGJh4K+aVHJEGBGjppl0oAHtkBBQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id VeGUgJDl0JRI for ; Mon, 25 Jul 2011 20:18:33 +0100 (IST) Received: from [130.129.39.94] (unknown [130.129.39.94]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 8D722171C98 for ; Mon, 25 Jul 2011 20:18:33 +0100 (IST) Message-ID: <4E2DC173.3000203@cs.tcd.ie> Date: Mon, 25 Jul 2011 20:18:11 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "secdir@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] decade would like some security help 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, 25 Jul 2011 19:18:44 -0000 I'll try remember to bring this up at the secdir lunch tomorrow, but the decade wg would like a bit of help. Rich Woundy (WG co-chair) said: " The immediate issue is that we need a security expert to help us re-frame the security considerations in the decade problem statement, per direction from our AD. In general, we could use a security expert to understand the decade architecture and proposed protocols, and make recommendations as to enable authorized access to a shared datastore to support P2P swarms. " If someone's interested let Sean and I know, Ta, S. From turners@ieca.com Mon Jul 25 12:51:08 2011 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 49F4611E80A8 for ; Mon, 25 Jul 2011 12:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.906 X-Spam-Level: X-Spam-Status: No, score=-100.906 tagged_above=-999 required=5 tests=[AWL=-0.908, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7zwRp4W7EQT for ; Mon, 25 Jul 2011 12:51:06 -0700 (PDT) Received: from nm15.bullet.mail.sp2.yahoo.com (nm15.bullet.mail.sp2.yahoo.com [98.139.91.85]) by ietfa.amsl.com (Postfix) with SMTP id 03BF211E80A2 for ; Mon, 25 Jul 2011 12:51:06 -0700 (PDT) Received: from [98.139.91.67] by nm15.bullet.mail.sp2.yahoo.com with NNFMP; 25 Jul 2011 19:51:01 -0000 Received: from [98.139.91.13] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 25 Jul 2011 19:51:01 -0000 Received: from [127.0.0.1] by omp1013.mail.sp2.yahoo.com with NNFMP; 25 Jul 2011 19:51:01 -0000 X-Yahoo-Newman-Id: 712921.7622.bm@omp1013.mail.sp2.yahoo.com Received: (qmail 11316 invoked from network); 25 Jul 2011 19:51:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311623461; bh=oGhUfwo1QqtY9bQ99/rhDcj+w/yMExll9p8Ak+LQ96M=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=RT6ZmkUSAXwEZIJjhgOmooQqEhPck6VU1hO+93Lw8nwU2++mPJTWb0nEKyqVHrVOSdnP4gi3ywazhiWDX2/0FrYRgkh7paykIIL4Y0iiF59dc2yRncYoPP1a4JrYJBOKcBsuPG+MQoTZMokCZRyXAHaqDX3GHgREXrF8D9Dh+UQ= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: SPTVd.wVM1noNScWfwaRxDoeTl9G7Todf3OK9FHmnTjtaGZ vnOwl5EuQ1MCwqWBR97hqHwSyCLiQrQ9OjidF3_4IwpzZQGZ5mWXKKMv5IiS HPYFYjGY0LiWvdUi5tI5H6skeqUtz_9zoRWGXG7HDhtjqFva5IVdXnKO7ELi GWOoqVbzu4IyZJzCaWM59ZOleRkGJhnVcAxLxRPy5897fCvYJ2XVY22e3Iq2 Cc_4y1ChsJ2Mb3Ud7Q7LDT_StSQAQT37TTutw2OcW88vSxWxnNqXAB8YHw4H KalfL8I58TUxBHw5SzjbrAnap7rMGpAccTl1bEj8aXB9vdKlrIlxWyp1tLzr sTtjeEZCb1.5jB7t6n_FDDppBoGhUHzaf X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from dhcp-1598.meeting.ietf.org (turners@130.129.21.152 with plain) by smtp115.biz.mail.sp1.yahoo.com with SMTP; 25 Jul 2011 12:51:01 -0700 PDT Message-ID: <4E2DC924.6060008@ieca.com> Date: Mon, 25 Jul 2011 15:51:00 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] WG summaries 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, 25 Jul 2011 19:51:08 -0000 Please send WG summaries to the SAAG list. spt From shanna@juniper.net Tue Jul 26 03:54:48 2011 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 6824B21F8C30; Tue, 26 Jul 2011 03:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wABRONZsfShg; Tue, 26 Jul 2011 03:54:47 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id D70A621F8B67; Tue, 26 Jul 2011 03:54:44 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTi6c7oRZbl2ZFIIlj9fHyMnaOi758ARl@postini.com; Tue, 26 Jul 2011 03:54:47 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 26 Jul 2011 03:52:47 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 26 Jul 2011 06:52:46 -0400 From: Stephen Hanna To: "carlberg@g11.org.uk" Date: Tue, 26 Jul 2011 06:52:45 -0400 Thread-Topic: secdir review of draft-ietf-dime-priority-avps-04 Thread-Index: AcxLgJ6J3gNB8HReTRmZ8+GTygdEGAAALbkA Message-ID: References: <20110726104135.13472eudbij0eaqs@portland.eukhosting.net> In-Reply-To: <20110726104135.13472eudbij0eaqs@portland.eukhosting.net> 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 Cc: "lionel.morand@orange-ftgroup.com" , "draft-ietf-dime-priority-avps.all@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-dime-priority-avps-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 10:54:48 -0000 Thanks for your response, Ken. Removing the last sentence that you quoted would make things worse. Readers of this draft should definitely familiarize themselves with the security considerations related to priority. We should make that easier, not harder. The fact that those considerations also apply to other RFCs does not remove the fact that they apply to this one also. You cannot publish a document whose security considerations section says (as this one effectively does today), "There are lots of security considerations related to this document. To understand them, please dig through all the referenced documents and figure it out yourself." Doing that digging and analysis is the job of the document editors. In order to ease the burden on you, I think a reasonable compromise would be for YOU to review the documents referenced and decide which have the most relevant security considerations. Then you could list those explicitly in the last paragraph of the Security Considerations. Thanks, steve > -----Original Message----- > From: carlberg@g11.org.uk [mailto:carlberg@g11.org.uk] > Sent: Tuesday, July 26, 2011 6:42 AM > To: Stephen Hanna > Cc: ietf@ietf.org; secdir@ietf.org; draft-ietf-dime-priority- > avps.all@tools.ietf.org; lionel.morand@orange-ftgroup.com > Subject: re: secdir review of draft-ietf-dime-priority-avps-04 >=20 > Hi Steve, >=20 > Thanks for the review. >=20 > >=20 > > This standards track document defines Diameter AVPs that can be > > used to convey a variety of priority parameters. While the Security > > Considerations section of this document properly requires that > > implementers review the Security Considerations section in the > > Diameter protocol specification and consider the issues described > > there, it does not include any analysis of the specific security > > issues related to priority systems. The authors should review other > > Security Considerations sections relating to priority systems > > (e.g. the one in RFC 4412) and add text that describes the > > special security issues that arise with priority systems and > > the countermeasures that may be employed. >=20 > You raise an interesting issue and we actually had a discussion about > this on the DIME list > >=20 > And just for the sake of completeness, here is the security > considerations text of the dime-priority-avps draft in question: >=20 > This document describes the extension of Diameter for conveying > Quality > of Service information. The security considerations of the > Diameter > protocol itself have been discussed in [I-D.ietf-dime-rfc3588bis]. > Use > of the AVPs defined in this document MUST take into consideration > the > security issues and requirements of the Diameter base protocol. >=20 > The authors also recommend that readers should familiarize > themselves > with the security considerations of the various protocols listed in > the Normative References listed below. >=20 > In a nutshell, the authors and the chair disagreed with the need for > extending the security considerations to include an analysis with > other protocols (eg, rfc-4412) because these protocols operate outside > of the DIAMETER protocol. The dime-priority-avps draft is an > extension of I-D.ietf-dime-rfc3588bis, and thus is subject to the same > security considerations to the bis draft. And its also important to > keep in mind that the dime-priority-avps draft does not inject > prioritization into the exchange of DIAMETER messages. It simply > defines AVPs that correlate to some priority fields of other protocols. >=20 > If it was the last sentence (above) in the dime-priority-avps security > considerations that has triggered your comment about further analysis, > then I'd prefer just removing that text. >=20 > cheers, >=20 > -ken >=20 From carlberg@g11.org.uk Tue Jul 26 03:41:45 2011 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 CC2CD21F875E; Tue, 26 Jul 2011 03:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlhIR3z7fwro; Tue, 26 Jul 2011 03:41:45 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0A221F874A; Tue, 26 Jul 2011 03:41:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=g11.org.uk; h=Message-ID:Date:From:To:Cc:Subject:MIME-Version:Content-Type:Content-Disposition:Content-Transfer-Encoding:User-Agent:X-Source:X-Source-Args:X-Source-Dir; b=M7WYrH+4la6mylmpqk131Wwp8hkzO1RBhy6oHNKkVc7sTkUqsZwMBU3BiCnqnhokwyF+5L9OTxAy6fwixh6iT1a6vBDxPedyQqFZHOeBmw4fuuW2NuHbYrIQpK/r7zrd; Received: from localhost ([127.0.0.1]:38387) by portland.eukhosting.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Qlf4x-0003sR-Cj; Tue, 26 Jul 2011 10:41:35 +0000 Received: from 130.129.67.210 ([130.129.67.210]) by portland.eukhosting.net (Horde Framework) with HTTP; Tue, 26 Jul 2011 10:41:35 +0000 Message-ID: <20110726104135.13472eudbij0eaqs@portland.eukhosting.net> Date: Tue, 26 Jul 2011 10:41:35 +0000 From: carlberg@g11.org.uk To: shanna@juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Tue, 26 Jul 2011 04:29:07 -0700 Cc: lionel.morand@orange-ftgroup.com, draft-ietf-dime-priority-avps.all@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dime-priority-avps-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 10:41:45 -0000 Hi Steve, Thanks for the review. > This standards track document defines Diameter AVPs that can be > used to convey a variety of priority parameters. While the Security > Considerations section of this document properly requires that > implementers review the Security Considerations section in the > Diameter protocol specification and consider the issues described > there, it does not include any analysis of the specific security > issues related to priority systems. The authors should review other > Security Considerations sections relating to priority systems > (e.g. the one in RFC 4412) and add text that describes the > special security issues that arise with priority systems and > the countermeasures that may be employed. You raise an interesting issue and we actually had a discussion about this on the DIME list And just for the sake of completeness, here is the security considerations text of the dime-priority-avps draft in question: This document describes the extension of Diameter for conveying Quality of Service information. The security considerations of the Diameter protocol itself have been discussed in [I-D.ietf-dime-rfc3588bis]. Use of the AVPs defined in this document MUST take into consideration the security issues and requirements of the Diameter base protocol. The authors also recommend that readers should familiarize themselves with the security considerations of the various protocols listed in the Normative References listed below. In a nutshell, the authors and the chair disagreed with the need for extending the security considerations to include an analysis with other protocols (eg, rfc-4412) because these protocols operate outside of the DIAMETER protocol. The dime-priority-avps draft is an extension of I-D.ietf-dime-rfc3588bis, and thus is subject to the same security considerations to the bis draft. And its also important to keep in mind that the dime-priority-avps draft does not inject prioritization into the exchange of DIAMETER messages. It simply defines AVPs that correlate to some priority fields of other protocols. If it was the last sentence (above) in the dime-priority-avps security considerations that has triggered your comment about further analysis, then I'd prefer just removing that text. cheers, -ken From carlberg@g11.org.uk Tue Jul 26 04:23:56 2011 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 04D0F21F8C61; Tue, 26 Jul 2011 04:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZVgQDhQb-PX; Tue, 26 Jul 2011 04:23:55 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1A16A21F8B91; Tue, 26 Jul 2011 04:23:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=g11.org.uk; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To:MIME-Version:Content-Type:Content-Disposition:Content-Transfer-Encoding:User-Agent:X-Source:X-Source-Args:X-Source-Dir; b=DQhuqeEDff2sTZfYU5reNpvf+h8QGlQlnABqEBvRIpKxMB/NcthwVHpuE0y0BwlwstCyMaEIuJafVm3FC8uP1X19iWdhuKzo7nqSojPajH6rtuVkizh8mtFZtusRo0RO; Received: from localhost ([127.0.0.1]:24388) by portland.eukhosting.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Qlfjm-0001ct-KH; Tue, 26 Jul 2011 11:23:46 +0000 Received: from 130.129.67.210 ([130.129.67.210]) by portland.eukhosting.net (Horde Framework) with HTTP; Tue, 26 Jul 2011 11:23:46 +0000 Message-ID: <20110726112346.35893ibie0kwerqc@portland.eukhosting.net> Date: Tue, 26 Jul 2011 11:23:46 +0000 From: carlberg@g11.org.uk To: Stephen Hanna References: <20110726104135.13472eudbij0eaqs@portland.eukhosting.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Tue, 26 Jul 2011 04:29:07 -0700 Cc: "lionel.morand@orange-ftgroup.com" , "draft-ietf-dime-priority-avps.all@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-dime-priority-avps-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 11:23:56 -0000 Steve, Quoting Stephen Hanna : > Thanks for your response, Ken. > > Removing the last sentence that you quoted would make things worse. > Readers of this draft should definitely familiarize themselves with > the security considerations related to priority. We should make that > easier, not harder. The fact that those considerations also apply to > other RFCs does not remove the fact that they apply to this one also. but those considerations do not directly apply to DIAMETER. > You cannot publish a document whose security considerations section > says (as this one effectively does today), "There are lots of security > considerations related to this document. To understand them, please > dig through all the referenced documents and figure it out yourself." > Doing that digging and analysis is the job of the document editors. agreed, speaking in the general sense. But again, the security considerations of these other protocols do not apply to the operation of Diameter. > In order to ease the burden on you, I think a reasonable compromise > would be for YOU to review the documents referenced and decide which > have the most relevant security considerations. Then you could list > those explicitly in the last paragraph of the Security Considerations. I'm concerned about the implications of your recommendation. If we extend this position to other work in the IETF, then efforts like defining MIBs would mean that each MIB draft would need to perform a security considerations analysis of each protocol that an objects refers to in the context of SNMP. And one can extend the argument that each protocol operating on top of TCP (and/or UDP) and IP would need to perform an analysis on how TCP/UDP and IP may affect the upper layer protocol. We don't do that today. cheers, -ken From turners@ieca.com Tue Jul 26 04:37:16 2011 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 C272321F8C74 for ; Tue, 26 Jul 2011 04:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.508 X-Spam-Level: X-Spam-Status: No, score=-100.508 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SI5PWgE-Xtrz for ; Tue, 26 Jul 2011 04:37:16 -0700 (PDT) Received: from nm27.bullet.mail.ne1.yahoo.com (nm27.bullet.mail.ne1.yahoo.com [98.138.90.90]) by ietfa.amsl.com (Postfix) with SMTP id 2BE6121F8C6A for ; Tue, 26 Jul 2011 04:37:16 -0700 (PDT) Received: from [98.138.90.51] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 26 Jul 2011 11:37:13 -0000 Received: from [98.138.89.173] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 26 Jul 2011 11:37:13 -0000 Received: from [127.0.0.1] by omp1029.mail.ne1.yahoo.com with NNFMP; 26 Jul 2011 11:37:13 -0000 X-Yahoo-Newman-Id: 203468.18040.bm@omp1029.mail.ne1.yahoo.com Received: (qmail 84347 invoked from network); 26 Jul 2011 11:37:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311680232; bh=1VfOAQd2qYjVzi2n6PTQGTdK4h23uZkC8luzSq84hVw=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=HjaZXcmZ8x9bst4XcArX40jwNcw4JY2sKHGUueNW+EHWDkHoQS/1/fQaiYSkICi4ihdabyaLzWmM2mxso1ZZ4dCFB6S7JTeYVEwULhKq/kT5vCSJMlE9fua2faFJdxuA1d+W9wemKWpcp6lLKnltbT+WGx2LZJ8r8orN5NsTcbU= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: oBKGsPwVM1l.a_7u1cZMy8shfy83Rmh9hboFJCwPaRnaHeN .BY8UdMMovEIuSL0QqfiqHByfwZRabW1IA4jQoZ.OgxL7tReIUrMYhPj1uzO kNdtg1sZBkEHj9HtuAGj4eMZomX8.uXm61cnfj_HtH3ILjMPKspGwn3C5meI 09qM_sUodrtYkcvll5vnsLzd8Gnw7OwByNRyF8WhqONpwJqHDhkBPRiPxCZQ Lb2.fGqPMt7Obog9gqOqJLlkrYAHh69GcnY9LXSpEg95SHA7kCALtII5.pWH Tn5j3Hj4dYk0qidcubrDKY1r74YYbMmYPypglEXkoIQvjl6_R4OnS3X8Du6n qYq1EPROR2fPZRD.HFTZgQTJhsbMuk3L5vHt8soP3ZJNoVNpE X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from dhcp-1598.meeting.ietf.org (turners@130.129.21.152 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 26 Jul 2011 04:37:12 -0700 PDT Message-ID: <4E2EA6E8.9010001@ieca.com> Date: Tue, 26 Jul 2011 07:37:12 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: secdir@ietf.org References: <4E0A4728.5060506@ieca.com> <4E1CB4DF.70803@ieca.com> In-Reply-To: <4E1CB4DF.70803@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [secdir] IETF 81 Security Directorate 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: Tue, 26 Jul 2011 11:37:16 -0000 Just a reminder .... On 7/12/11 4:55 PM, Sean Turner wrote: > Tuesday, July 26 (1130-1300) we'll be in room 303AB. From shanna@juniper.net Tue Jul 26 08:38:11 2011 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 BC22311E8119; Tue, 26 Jul 2011 08:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQI0Aw571ayk; Tue, 26 Jul 2011 08:38:10 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 91D0D11E80C1; Tue, 26 Jul 2011 08:38:06 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTi7fWAplrDKZcwv+XK39HNvdC/SXbGVU@postini.com; Tue, 26 Jul 2011 08:38:10 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 26 Jul 2011 08:34:29 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 26 Jul 2011 11:34:28 -0400 From: Stephen Hanna To: "carlberg@g11.org.uk" Date: Tue, 26 Jul 2011 11:34:27 -0400 Thread-Topic: secdir review of draft-ietf-dime-priority-avps-04 Thread-Index: AcxLhoMMZuNcnDQsSYq5r0pigpKbWQAApa0w Message-ID: References: <20110726104135.13472eudbij0eaqs@portland.eukhosting.net> <20110726112346.35893ibie0kwerqc@portland.eukhosting.net> In-Reply-To: <20110726112346.35893ibie0kwerqc@portland.eukhosting.net> 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 Cc: "lionel.morand@orange-ftgroup.com" , "draft-ietf-dime-priority-avps.all@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-dime-priority-avps-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 15:38:11 -0000 Every RFC author has an obligation to explain in the Security Consideration= s section what security issues are likely to arise when this specification is used and how those issues may be addressed. You can refer to other RFCs if you like but you cannot ignore the issues or just give a hand wave. Let me give a specific example. If a user is able to ensure that their phon= e calls always get the highest SIP-Resource-Priority, their calls will always go through, even during a disaster. This will benefit the user so they have an incentive to do it. However, it may damage the collective if calls from emergency responders are overridden. For this reason, protection against active MITM attacks SHOULD be employed when using Priority AVPs. If you can find an extant RFC that covers the relevant Security Considerati= ons for your document, you can point to it and say that readers should review i= t because the security considerations for this draft are contained there. But you must perform a serious security analysis for your document if you want it to be accepted as an RFC. If the answer is that there are no security considerations, that's fine. You can say that. But in this case, that's clearly not the case. You raised the concern that documents may need to highlight security issues with underlying protocols upon which they depend. That is true. If you're depending on a protocol that has a serious security problem that's relevant to your document, you should explain that problem or point to a document that does so. If the problem is not relevant to your document, no problem. One need not consider every possible security issue, just the ones that are most relevant to your document. In your case, there are real security issues particular to conveying priority AVPs over Diameter. You should explain what those considerations are or point to documents that do so. As for MIBs, take a look at some recent ones and you will see that they do contain good Security Considerations sections. For example, see RFC 5834 and RFC 6240. If you'd like to learn more about how to write a good Security Considerations section, read RFC 3552. Or ask a security expert to help you. If you can't be bothered to think about security, you might as well withdraw your draft from consideration. Thanks, Steve > -----Original Message----- > From: carlberg@g11.org.uk [mailto:carlberg@g11.org.uk] > Sent: Tuesday, July 26, 2011 7:24 AM > To: Stephen Hanna > Cc: ietf@ietf.org; secdir@ietf.org; draft-ietf-dime-priority- > avps.all@tools.ietf.org; lionel.morand@orange-ftgroup.com > Subject: RE: secdir review of draft-ietf-dime-priority-avps-04 >=20 > Steve, >=20 >=20 > Quoting Stephen Hanna : >=20 > > Thanks for your response, Ken. > > > > Removing the last sentence that you quoted would make things worse. > > Readers of this draft should definitely familiarize themselves with > > the security considerations related to priority. We should make that > > easier, not harder. The fact that those considerations also apply to > > other RFCs does not remove the fact that they apply to this one also. >=20 > but those considerations do not directly apply to DIAMETER. >=20 > > You cannot publish a document whose security considerations section > > says (as this one effectively does today), "There are lots of > security > > considerations related to this document. To understand them, please > > dig through all the referenced documents and figure it out yourself." > > Doing that digging and analysis is the job of the document editors. >=20 > agreed, speaking in the general sense. But again, the security > considerations of these other protocols do not apply to the operation > of Diameter. >=20 > > In order to ease the burden on you, I think a reasonable compromise > > would be for YOU to review the documents referenced and decide which > > have the most relevant security considerations. Then you could list > > those explicitly in the last paragraph of the Security > Considerations. >=20 > I'm concerned about the implications of your recommendation. If we > extend this position to other work in the IETF, then efforts like > defining MIBs would mean that each MIB draft would need to perform a > security considerations analysis of each protocol that an objects > refers to in the context of SNMP. And one can extend the argument > that each protocol operating on top of TCP (and/or UDP) and IP would > need to perform an analysis on how TCP/UDP and IP may affect the upper > layer protocol. We don't do that today. >=20 > cheers, >=20 > -ken >=20 From kent@bbn.com Tue Jul 26 09:40:52 2011 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 34A0A21F84C7 for ; Tue, 26 Jul 2011 09:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 665w6k7QVTWb for ; Tue, 26 Jul 2011 09:40:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id AF26421F8489 for ; Tue, 26 Jul 2011 09:40:51 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:54796 helo=[130.129.18.170]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qlkgd-000Fjs-7N; Tue, 26 Jul 2011 12:40:51 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4E2DC924.6060008@ieca.com> References: <4E2DC924.6060008@ieca.com> Date: Tue, 26 Jul 2011 12:40:44 -0400 To: secdir@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [secdir] PKIX Summary 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, 26 Jul 2011 16:40:52 -0000 PKIX met once, for 2 hours, on Monday, 7/25. About 41 people attended. The principle discussions centered on the CAA proposal. CAA is a DNS-based mechanism intended to help public trust anchor operators detect when a CA issues a cert for a web site that should be issued by a different CA. There was a lively discussion about many aspects of CAA, dealing with topics such as how to identify the CA that should be issuing a cert for the web site, whether the DNS records used for this are to be consumed by relying parties, and how to explain the motivation for this effort. The author (P. Hallam-Baker) agreed to revise the I-D to address the points raised during these discussions. The meeting finished with two presentations on docs that are being considered for adoption by the WG. Thye first presentation was a proposal to extend CMC to accommodate scenarios in which a CA/RA generates the key pair for a client. This may be desired to offer better randomization for key generation, and to enable key escrow, e.g., in corporate environments. The second presentation described a proposal for a new, simple cert enrollment protocol, based on the "simple" CMC messages, augmented to provide a few additional capabilities that are considered critical. The protocol is EST: certificate Enrollment over Secure Transport. From weiler@watson.org Tue Jul 26 09:48:17 2011 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 9F10C21F8AEC for ; Tue, 26 Jul 2011 09:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siLBVM7GF3QU for ; Tue, 26 Jul 2011 09:48:17 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 08B8121F8AE9 for ; Tue, 26 Jul 2011 09:48:16 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p6QGmGud094892 for ; Tue, 26 Jul 2011 12:48:16 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p6QGmFh8094888 for ; Tue, 26 Jul 2011 12:48:16 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 26 Jul 2011 12:48:15 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 26 Jul 2011 12:48:16 -0400 (EDT) Subject: [secdir] secdir wiki link 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: Tue, 26 Jul 2011 16:48:17 -0000 For those who might have missed it in the weekely emails, here's a link to the wiki with suggested review boilerplate, instructions, and other useless stuff: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From paul.hoffman@vpnc.org Tue Jul 26 10:52:10 2011 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 6ADC121F8A67 for ; Tue, 26 Jul 2011 10:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EY9nMD9IINA4 for ; Tue, 26 Jul 2011 10:52:10 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6B221F8A66 for ; Tue, 26 Jul 2011 10:52:09 -0700 (PDT) Received: from dhcp-25eb.meeting.ietf.org ([130.129.37.235]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6QHppsW017777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Jul 2011 10:51:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 26 Jul 2011 13:52:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <015D04EA-0BC6-4780-AD50-90EA96E06F42@vpnc.org> References: To: secdir-secretary@mit.edu X-Mailer: Apple Mail (2.1084) Cc: secdir@ietf.org Subject: Re: [secdir] secdir wiki link 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, 26 Jul 2011 17:52:10 -0000 On Jul 26, 2011, at 12:48 PM, Samuel Weiler wrote: > For those who might have missed it in the weekely emails, here's a = link to the wiki with suggested review boilerplate, instructions, and = other useless stuff: >=20 > http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Maybe if you put it at the top of the messages we could... oh, wait. :-) --Paul Hoffman From jhutz@cmu.edu Tue Jul 26 11:10:37 2011 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 7AF4C5E800B for ; Tue, 26 Jul 2011 11:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH7kTvU3V+D2 for ; Tue, 26 Jul 2011 11:10:36 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id C01795E8002 for ; Tue, 26 Jul 2011 11:10:36 -0700 (PDT) Received: from [66.233.146.161] (66-233-146-161.pit.clearwire-wmx.net [66.233.146.161] (may be forged)) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p6QIAXLu017228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 14:10:34 -0400 (EDT) From: Jeffrey Hutzelman To: Paul Hoffman In-Reply-To: <21082_1311702732_p6QHqBfB018758_015D04EA-0BC6-4780-AD50-90EA96E06F42@vpnc.org> References: <21082_1311702732_p6QHqBfB018758_015D04EA-0BC6-4780-AD50-90EA96E06F42@vpnc.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 26 Jul 2011 14:10:31 -0400 Message-ID: <1311703831.2993.51.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: secdir@ietf.org, secdir-secretary@mit.edu Subject: Re: [secdir] secdir wiki link 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, 26 Jul 2011 18:10:37 -0000 On Tue, 2011-07-26 at 13:52 -0400, Paul Hoffman wrote: > On Jul 26, 2011, at 12:48 PM, Samuel Weiler wrote: > > > For those who might have missed it in the weekely emails, here's a link to the wiki with suggested review boilerplate, instructions, and other useless stuff: > > > > http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > > Maybe if you put it at the top of the messages we could... oh, wait. :-) If that doesn't work, it could get added to the footer that goes on every message to this list, along with other things no one ever reads. :-) From weiler@watson.org Tue Jul 26 11:16:45 2011 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 42E6021F8A67 for ; Tue, 26 Jul 2011 11:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtIF4ostjTHm for ; Tue, 26 Jul 2011 11:16:44 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id B16F021F861A for ; Tue, 26 Jul 2011 11:16:44 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p6QIGgVU023400; Tue, 26 Jul 2011 14:16:42 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p6QIGfEg023395; Tue, 26 Jul 2011 14:16:42 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 26 Jul 2011 14:16:41 -0400 (EDT) From: Samuel Weiler To: Jeffrey Hutzelman In-Reply-To: <1311703831.2993.51.camel@destiny.pc.cs.cmu.edu> Message-ID: References: <21082_1311702732_p6QHqBfB018758_015D04EA-0BC6-4780-AD50-90EA96E06F42@vpnc.org> <1311703831.2993.51.camel@destiny.pc.cs.cmu.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 26 Jul 2011 14:16:42 -0400 (EDT) Cc: secdir@ietf.org Subject: Re: [secdir] secdir wiki link 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: Tue, 26 Jul 2011 18:16:45 -0000 On Tue, 26 Jul 2011, Jeffrey Hutzelman wrote: > If that doesn't work, it could get added to the footer that goes on > every message to this list, along with other things no one ever > reads. :-) Done. :-) From lionel.morand@orange-ftgroup.com Tue Jul 26 08:00:12 2011 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 42AD721F8B72; Tue, 26 Jul 2011 08:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7APw9jzvZTr5; Tue, 26 Jul 2011 08:00:11 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4B91121F855C; Tue, 26 Jul 2011 08:00:11 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C77688C0001; Tue, 26 Jul 2011 17:00:58 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id AC1F78B8009; Tue, 26 Jul 2011 17:00:58 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 17:00:09 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 17:00:08 +0200 Message-ID: In-reply-to: <20110726112346.35893ibie0kwerqc@portland.eukhosting.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: secdir review of draft-ietf-dime-priority-avps-04 Thread-index: AcxLho+V4YXq04I3QKSV0cnCnlyypgAGa8Kw References: <20110726104135.13472eudbij0eaqs@portland.eukhosting.net> <20110726112346.35893ibie0kwerqc@portland.eukhosting.net> From: To: , X-OriginalArrivalTime: 26 Jul 2011 15:00:09.0713 (UTC) FILETIME=[B6996E10:01CC4BA4] X-Mailman-Approved-At: Tue, 26 Jul 2011 11:17:52 -0700 Cc: draft-ietf-dime-priority-avps.all@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dime-priority-avps-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 15:00:12 -0000 Hi Steve, It should be maybe clarified (if required) that this document does not = create a new protocol/solution. It only defines extensions to an = existing protocol (Diameter QoS Application), completing a standard list = of AVPs in order to support a set of parameters already defined in other = specifications. So, to be able to use this set of AVPs, you will have first to comply = with the Diameter base protocol (RFC3588(bis)), the Diameter QoS = application (RFC5866), the RFC 5624 defining the list of AVP, and all = the different specifications defining these priority parameters. This = document does not introduce new security issue. It just relies on = existing solutions. I understand therefore the concerns from Ken. Regards, Lionel -----Message d'origine----- De=A0: carlberg@g11.org.uk [mailto:carlberg@g11.org.uk]=20 Envoy=E9=A0: mardi 26 juillet 2011 13:24 =C0=A0: Stephen Hanna Cc=A0: ietf@ietf.org; secdir@ietf.org; = draft-ietf-dime-priority-avps.all@tools.ietf.org; MORAND Lionel = RD-CORE-ISS Objet=A0: RE: secdir review of draft-ietf-dime-priority-avps-04 Steve, Quoting Stephen Hanna : > Thanks for your response, Ken. > > Removing the last sentence that you quoted would make things worse. > Readers of this draft should definitely familiarize themselves with > the security considerations related to priority. We should make that > easier, not harder. The fact that those considerations also apply to > other RFCs does not remove the fact that they apply to this one also. but those considerations do not directly apply to DIAMETER. > You cannot publish a document whose security considerations section > says (as this one effectively does today), "There are lots of security > considerations related to this document. To understand them, please > dig through all the referenced documents and figure it out yourself." > Doing that digging and analysis is the job of the document editors. agreed, speaking in the general sense. But again, the security =20 considerations of these other protocols do not apply to the operation =20 of Diameter. > In order to ease the burden on you, I think a reasonable compromise > would be for YOU to review the documents referenced and decide which > have the most relevant security considerations. Then you could list > those explicitly in the last paragraph of the Security Considerations. I'm concerned about the implications of your recommendation. If we =20 extend this position to other work in the IETF, then efforts like =20 defining MIBs would mean that each MIB draft would need to perform a =20 security considerations analysis of each protocol that an objects =20 refers to in the context of SNMP. And one can extend the argument =20 that each protocol operating on top of TCP (and/or UDP) and IP would =20 need to perform an analysis on how TCP/UDP and IP may affect the upper =20 layer protocol. We don't do that today. cheers, -ken From lionel.morand@orange-ftgroup.com Tue Jul 26 11:26:12 2011 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 94EFD21F873D; Tue, 26 Jul 2011 11:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Gqk1aHxmlkJ; Tue, 26 Jul 2011 11:26:11 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 625A721F86BE; Tue, 26 Jul 2011 11:26:11 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 55C598B8007; Tue, 26 Jul 2011 20:26:59 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 49BF48B8003; Tue, 26 Jul 2011 20:26:59 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 20:26:10 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 20:26:08 +0200 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: secdir review of draft-ietf-dime-priority-avps-04 Thread-index: AcxLhoMMZuNcnDQsSYq5r0pigpKbWQAApa0wAA115aA= References: <20110726104135.13472eudbij0eaqs@portland.eukhosting.net> <20110726112346.35893ibie0kwerqc@portland.eukhosting.net> From: To: , X-OriginalArrivalTime: 26 Jul 2011 18:26:10.0449 (UTC) FILETIME=[7E2C1010:01CC4BC1] X-Mailman-Approved-At: Wed, 27 Jul 2011 08:21:51 -0700 Cc: draft-ietf-dime-priority-avps.all@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dime-priority-avps-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 18:26:12 -0000 Hi Stephen, The example given below illustrates also what I'm thinking. And please = forgive me if I miss something below. IMHO, what you are saying about the SIP-Resource-Priority is true for = any other QoS parameters carried over the Diameter QoS application. It = is therefore why I'm assuming that the security considerations = (http://tools.ietf.org/html/rfc5866#section-11) provided in the RFC 5866 = is valid for any QoS related AVP, including the new set of AVPs defined = in this document. Would it make sense to refer to this section (instead of a copy/paste)? = Would it solve the current issue? Regards, Lionel -----Message d'origine----- De=A0: Stephen Hanna [mailto:shanna@juniper.net]=20 Envoy=E9=A0: mardi 26 juillet 2011 17:34 =C0=A0: carlberg@g11.org.uk Cc=A0: ietf@ietf.org; secdir@ietf.org; = draft-ietf-dime-priority-avps.all@tools.ietf.org; MORAND Lionel = RD-CORE-ISS Objet=A0: RE: secdir review of draft-ietf-dime-priority-avps-04 Every RFC author has an obligation to explain in the Security = Considerations section what security issues are likely to arise when this specification = is used and how those issues may be addressed. You can refer to other RFCs = if you like but you cannot ignore the issues or just give a hand wave. Let me give a specific example. If a user is able to ensure that their = phone calls always get the highest SIP-Resource-Priority, their calls will = always go through, even during a disaster. This will benefit the user so they = have an incentive to do it. However, it may damage the collective if calls = from emergency responders are overridden. For this reason, protection against active MITM attacks SHOULD be employed when using Priority AVPs. If you can find an extant RFC that covers the relevant Security = Considerations for your document, you can point to it and say that readers should = review it because the security considerations for this draft are contained there. = But you must perform a serious security analysis for your document if you = want it to be accepted as an RFC. If the answer is that there are no security considerations, that's fine. You can say that. But in this case, that's clearly not the case. You raised the concern that documents may need to highlight security = issues with underlying protocols upon which they depend. That is true. If = you're depending on a protocol that has a serious security problem that's = relevant to your document, you should explain that problem or point to a document that does so. If the problem is not relevant to your document, no = problem. One need not consider every possible security issue, just the ones that are most relevant to your document. In your case, there are real = security issues particular to conveying priority AVPs over Diameter. You should explain what those considerations are or point to documents that do so. As for MIBs, take a look at some recent ones and you will see that they do contain good Security Considerations sections. For example, see RFC 5834 and RFC 6240. If you'd like to learn more about how to write a good Security Considerations section, read RFC 3552. Or ask a security expert to help you. If you can't be bothered to think about security, you might as well withdraw your draft from consideration. Thanks, Steve > -----Original Message----- > From: carlberg@g11.org.uk [mailto:carlberg@g11.org.uk] > Sent: Tuesday, July 26, 2011 7:24 AM > To: Stephen Hanna > Cc: ietf@ietf.org; secdir@ietf.org; draft-ietf-dime-priority- > avps.all@tools.ietf.org; lionel.morand@orange-ftgroup.com > Subject: RE: secdir review of draft-ietf-dime-priority-avps-04 >=20 > Steve, >=20 >=20 > Quoting Stephen Hanna : >=20 > > Thanks for your response, Ken. > > > > Removing the last sentence that you quoted would make things worse. > > Readers of this draft should definitely familiarize themselves with > > the security considerations related to priority. We should make that > > easier, not harder. The fact that those considerations also apply to > > other RFCs does not remove the fact that they apply to this one = also. >=20 > but those considerations do not directly apply to DIAMETER. >=20 > > You cannot publish a document whose security considerations section > > says (as this one effectively does today), "There are lots of > security > > considerations related to this document. To understand them, please > > dig through all the referenced documents and figure it out = yourself." > > Doing that digging and analysis is the job of the document editors. >=20 > agreed, speaking in the general sense. But again, the security > considerations of these other protocols do not apply to the operation > of Diameter. >=20 > > In order to ease the burden on you, I think a reasonable compromise > > would be for YOU to review the documents referenced and decide which > > have the most relevant security considerations. Then you could list > > those explicitly in the last paragraph of the Security > Considerations. >=20 > I'm concerned about the implications of your recommendation. If we > extend this position to other work in the IETF, then efforts like > defining MIBs would mean that each MIB draft would need to perform a > security considerations analysis of each protocol that an objects > refers to in the context of SNMP. And one can extend the argument > that each protocol operating on top of TCP (and/or UDP) and IP would > need to perform an analysis on how TCP/UDP and IP may affect the upper > layer protocol. We don't do that today. >=20 > cheers, >=20 > -ken >=20 From bew@cisco.com Wed Jul 27 14:49:19 2011 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 1521611E817B for ; Wed, 27 Jul 2011 14:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.199 X-Spam-Level: X-Spam-Status: No, score=-104.199 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1Z3hTxNqTyn for ; Wed, 27 Jul 2011 14:49:18 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D415B11E816F for ; Wed, 27 Jul 2011 14:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=707; q=dns/txt; s=iport; t=1311803355; x=1313012955; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=KBqTSIQfWN5mwxeRwplRUBtBpHWi4shbdu5l6xR03PA=; b=aIXH6kRPtc4KN9bFIKWQVJxaIwg99V8T1OO7rfQZrlvNSummArSiUPnu k4JYrW1+SfI1PD/OP0r58JdYt7CKkwRz7uHtkt4Yu4qd4SIzj0MHDv9W4 t51OWBoo07zx8wj+x9GYTFXapJyH2vzhPmFDGclXScx/YyL0qF7ymY3C0 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUFADqHME6rRDoG/2dsb2JhbAA0AQEBAQIBAQEBEQErOgsFDAw3GxQYOQUZJ5ggjwR3iHwEozaeWYM9giRfBIdXix6QK1c X-IronPort-AV: E=Sophos;i="4.67,279,1309737600"; d="scan'208";a="7154298" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-4.cisco.com with ESMTP; 27 Jul 2011 21:49:10 +0000 Received: from sjc-vpn7-1566.cisco.com (sjc-vpn7-1566.cisco.com [10.21.150.30]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6RLn9Z4001096; Wed, 27 Jul 2011 21:49:09 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: Date: Wed, 27 Jul 2011 14:49:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <20676AA6-EED9-4DDC-BF2D-0EE51EE0A2B5@cisco.com> References: To: secdir-secretary@mit.edu X-Mailer: Apple Mail (2.1084) Cc: secdir@ietf.org Subject: Re: [secdir] secdir wiki link 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, 27 Jul 2011 21:49:19 -0000 Thanks, Sam ... now I can go back to just looking for my name in the = weekly emails and ignoring the rest of the contents. :-) Brian On Jul 26, 2011, at 9:48 AM, Samuel Weiler wrote: > For those who might have missed it in the weekely emails, here's a = link to the wiki with suggested review boilerplate, instructions, and = other useless stuff: >=20 > http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From turners@ieca.com Fri Jul 29 10:51:00 2011 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 81F7021F8AD1 for ; Fri, 29 Jul 2011 10:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.282 X-Spam-Level: X-Spam-Status: No, score=-101.282 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_20=-0.74, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOPanF3LsFmX for ; Fri, 29 Jul 2011 10:51:00 -0700 (PDT) Received: from nm8.access.bullet.mail.mud.yahoo.com (nm8.access.bullet.mail.mud.yahoo.com [66.94.237.209]) by ietfa.amsl.com (Postfix) with SMTP id 08E5921F8A7A for ; Fri, 29 Jul 2011 10:50:59 -0700 (PDT) Received: from [66.94.237.192] by nm8.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Jul 2011 17:50:59 -0000 Received: from [98.139.221.63] by tm3.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Jul 2011 17:50:59 -0000 Received: from [127.0.0.1] by smtp104.biz.mail.bf1.yahoo.com with NNFMP; 29 Jul 2011 17:50:59 -0000 X-Yahoo-Newman-Id: 561049.3895.bm@smtp104.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: zTdiUzAVM1kejVSjgEpRBzXL3nXzSxJbvssWEo2yfajoVwk O6YEsY8Fw6inOrhQw2nX_dE2_zd0KACFTXbDJ5v4uQsMUYwX_yXqsWFDghxY 1PCmA3ATMqjTBBMUtwpz467dj231xbzCKI2oHY7Hn4oQqTrec4.claIIRiBF R8EClWEogzUiIQsRvuf0sOR.3bznQUo0I4TV9yMHIp.0CKj.LnD066APsIou U5ULP3PtrmDnHi18s32rwOBdrRIETowLjcsLQsz9Yd73YXjn31Ll5Ck0nTfo 3ve3kfTDzBdDDcUkqYUY.5RbUiaRwQHIxNPTLCH7R.cgovcs_Nh97Y9YidmF MfQ4_6bNxGVDnrQI- X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from dhcp-1598.meeting.ietf.org (turners@130.129.21.152 with plain) by smtp104.biz.mail.bf1.yahoo.com with SMTP; 29 Jul 2011 10:50:59 -0700 PDT Message-ID: <4E32F302.3000508@ieca.com> Date: Fri, 29 Jul 2011 13:50:58 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] winner winner chicken dinner 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, 29 Jul 2011 17:51:00 -0000 Thanks go to Alexey for volunteering to take on the 300+ page iSCSI draft. spt From d3e3e3@gmail.com Sat Jul 30 15:23:38 2011 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 3263221F8560 for ; Sat, 30 Jul 2011 15:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.349 X-Spam-Level: X-Spam-Status: No, score=-104.349 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7i0v-KJE0NTt for ; Sat, 30 Jul 2011 15:23:37 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE8B21F8556 for ; Sat, 30 Jul 2011 15:23:37 -0700 (PDT) Received: by gwb20 with SMTP id 20so3774191gwb.31 for ; Sat, 30 Jul 2011 15:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=NPW94b0QnnDxZMlOqab1///yT/TkuOprOYrWNp85VXM=; b=HQMAC076g2dHTcBossNh+nOihsLL3X+H0+aN/2ljcaE/ACp7P9kjQUqxuP2zowUerw tAvK+5YVMY1quDCrCYzUk0C6HzxtMh6dRfL8cggkkVBIAB/aTCXuiqrwOtfNbSvTctb3 D4v0pJTMgK16bp97M7F4hzhHkFsSEonHG1UUQ= Received: by 10.151.21.13 with SMTP id y13mr625234ybi.239.1312064619119; Sat, 30 Jul 2011 15:23:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.50.5 with HTTP; Sat, 30 Jul 2011 15:23:19 -0700 (PDT) In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD52215D5B08@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD52215D5B08@EUSAACMS0703.eamcs.ericsson.se> From: Donald Eastlake Date: Sat, 30 Jul 2011 18:23:19 -0400 Message-ID: To: David Allan I Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: George Swallow , John E Drake , "sboutros@cisco.com" , Suresh Krishnan , "msiva@cisco.com" , Annamaria Fulignoli , secdir@ietf.org, "dward@juniper.net" , Martin Vigoureux , Dan Romascanu , Jia He , Ross Callon , Robert Rennison , Stewart Bryant Subject: Re: [secdir] Draft cc-cv-rdi 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, 30 Jul 2011 22:23:38 -0000 I am satisfied with the response to my SecDir comments. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Thu, Jul 28, 2011 at 11:51 AM, David Allan I wrote: > Hello > > Attached is a revised version of the draft, plus a spreadsheet documentin= g > the LC comments and associated changes. > > Dol you mind scanning the draft to ensure your comments have been address= ed. > > I've cc'd the WG chairs, authors and commenters, but do not have email fo= r > Joe Jaeggli=85 does someone mind forwarding? > > Thanks > Dave >