From mbj@tail-f.com Wed Nov 30 12:48: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 6036B1F0C4E; Wed, 30 Nov 2011 12:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPsnwHepjZqs; Wed, 30 Nov 2011 12:48:02 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id BDD331F0C3B; Wed, 30 Nov 2011 12:48:01 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id E368012008D2; Wed, 30 Nov 2011 21:48:00 +0100 (CET) Date: Wed, 30 Nov 2011 21:47:59 +0100 (CET) Message-Id: <20111130.214759.42107896.mbj@tail-f.com> To: carl@redhoundsoftware.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 01 Dec 2011 08:15:46 -0800 Cc: secdir@ietf.org, iesg@ietf.org, draft-ietf-netconf-access-control.all@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-netconf-access-control-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 20:48:02 -0000 Hi, Thank you for your review. Comments inline. Carl Wallace wrote: > I found the frequent references to "recovery sessions" and "non-recovery > sessions" unnecessary and somewhat confusing. Couldn't this concept be > described once and omitted from the various lists of steps? We did think about this, but although it is currently a bit redundant, we felt spelling it out expclitly made the "elements of procedure" descriptions more clear. > There are > probably some inconsistencies in the RFC 2119 language around the > "recovery session" concept. For example, section 3.4.4 provides a > bulleted list of steps that MUST be followed. Included in this list is an > exception for recovery sessions. Section 3.3.1 says a "server MAY support > a "recovery session" mechanism". Should 3.3.1 be a MUST? No, "MAY" is correct. The server MUST follow the procedure in 3.4.4, which says that if the session is a recovery session then . If the server doesn't support recovery sessions, then the current session is clearly not a recovery session, and won't happen. > Section 3.1.1 references both "recovery session" and the ability to > disable the entire access control model "during operation, in order to > debug operational problems". What does the latter bullet that mentions > debugging refer to in the model? Is this bullet just a second reference > to recovery session? The access control model can be disabled but setting the leaf /nacm/enable-nacm to false (see the leaf enable-nacm in the YANG module). > In section 3.2.4, copy operations may be partially performed while "nodes > to which the client does not have read access are silently omitted". Why > is this OK? It seems inconsistent with section 3.1.3, which says "If the > user is authorized to perform the requested access operation on the > requested data, then processing continues", implying that processing does > not continue otherwise. The same silent skipping of items appears > elsewhere as well, including edit config. At a minimum, some rationale > describing why these silent omissions are acceptable should be > provided. There are two reasons for this. One is consistency with , and the other is if you just have access to a single leaf, you should still be allowed to perform "copy-config running to startup", making your change persistent. /martin From weiler+secdir@watson.org Sat Dec 3 20:26: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 1B2001F0C3F for ; Sat, 3 Dec 2011 20:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQkMBek1ML6V for ; Sat, 3 Dec 2011 20:26:36 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA241F0C3B for ; Sat, 3 Dec 2011 20:26:36 -0800 (PST) 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 pB44QZ3M074272 for ; Sat, 3 Dec 2011 23:26:35 -0500 (EST) (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 pB44QYtN074263 for ; Sat, 3 Dec 2011 23:26:35 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 3 Dec 2011 23:26:34 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org In-Reply-To: Message-ID: References: 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, 03 Dec 2011 23:26:35 -0500 (EST) 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: Sun, 04 Dec 2011 04:26:37 -0000 On Tue, 8 Nov 2011, Samuel Weiler wrote: > In the last batch of assignments there were many last-minute requests for > reviews of docs on the 3 November IESG agenda. Many of those weren't > reviewed. Since it's my fault for not giving you more warning, I'm not > sending nasty-grams, but I may be assigning those folks some new docs next > week. As above, all of the "new" assignments this week are out-of-order. New assignments have been made to: Love Hornquist-Astrand, Jeffrey Hutzelman, Warren Kumari, Julien Laganier, David McGrew, Magnus Nystrom, Hilarie Orman, Radia Perlman, Tim Polk, and Eric Rescorla. A couple of the documents originally scheduled for the December 1st telechat were deferred. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Derek Atkins is (still) next in the rotation. I have one name left on the out-of-order assignment list: Larry Zhu. For telechat 2011-12-15 Reviewer LC end Draft Scott Kelly TR2011-12-12 draft-ietf-geopriv-policy-uri-04 Russ Mundy T 2011-11-30 draft-ietf-ppsp-problem-statement-07 Sandy Murphy T 2011-11-10 draft-ietf-v6ops-happy-eyeballs-05 For telechat 2012-01-05 Love Hornquist-Astrand T 2011-12-29 draft-daboo-webdav-sync-06 Jeffrey Hutzelman T 2011-12-26 draft-gregorio-uritemplate-07 Tim Polk T 2011-12-28 draft-kucherawy-dkim-atps-11 Eric Rescorla T 2011-12-29 draft-ohye-canonical-link-relation-04 Last calls and special requests: Alan DeKok 2011-12-05 draft-ietf-6man-exthdr-05 Phillip Hallam-Baker 2011-12-07 draft-gerhards-syslog-plain-tcp-11 Warren Kumari 2011-12-12 draft-ietf-idr-fsm-subcode-02 Julien Laganier 2011-12-15 draft-ietf-marf-redaction-03 David McGrew 2011-12-12 draft-ietf-mpls-tp-mib-management-overview-05 Magnus Nystrom 2011-12-12 draft-ietf-ospf-multi-instance-06 Hilarie Orman 2011-12-13 draft-ietf-sidr-rpki-rtr-20 Radia Perlman 2011-12-15 draft-ietf-sieve-include-13 Tina TSOU 2011-04-23 draft-shin-augmented-pake-08 Nico Williams 2011-11-17 draft-ietf-simple-msrp-cema-03 From mlepinski@bbn.com Sun Dec 4 20:04: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 7B0471F0C3B; Sun, 4 Dec 2011 20:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxJTgEkdME1f; Sun, 4 Dec 2011 20:04:58 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 983121F0C36; Sun, 4 Dec 2011 20:04:58 -0800 (PST) Received: from [128.89.255.220] (port=1781) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RXPnJ-000JYK-2K; Sun, 04 Dec 2011 23:04:45 -0500 Message-ID: <4EDC431D.1090805@bbn.com> Date: Sun, 04 Dec 2011 23:05:49 -0500 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-lisp.all@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [secdir] SECDIR review of draft-ietf-lisp-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: Mon, 05 Dec 2011 04:04:59 -0000 I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the secur= ity area directors. Document editors and WG chairs should treat these com= ments just like any other last call comments. This document is the core LISP specification. It specifies the basic oper= ation of LIST ITRs (Ingress Tunnel Router) and ETRs (Egress Tunnel Router= s) as well as the syntax for LISP mapping messages which the ITR uses to = determine to which ETR it should tunnel a packet in order to reach a give= n endpoint. This document describes a basic mode of operation where LISP = mapping messages are sent over the standard Internet routing topology. After reading this document, I believe that "poisoning" of the mapping ca= che (i.e., placing false entries in the mapping cache) is not adequately = addressed in the security considerations of this document. I accept that = the use of a nonce and return-routability checks to reduce the ability of= an off-path adversary to get false mapping data into the mapping cache. = However, I believe there are still significant residual vulnerabilities t= hat are not adequately addressed in the security considerations. For instance consider the following scenarios in which an adversary can g= et "false" mappings accepted into an ITR's mapping cache. (My apologies i= f I misunderstood the specification in one of the following scenarios) -- The adversary is on the path for a mapping reply from an ETR to an ITR= =2E The adversary alters the mapping response, leaving the nonce unchange= d, but placing its own IP address as the "locator" in the record being re= turned. -- The adversary is on the path for a mapping request from an ITR to an E= TR. Instead of forwarding the mapping response, the adversary fabricates = a reply to the mapping request with its own IP address as the "locator" i= n the record being returned. -- The adversary believes that it is likely on the path from a particular= ETR X to some EID Y. The adversary sends a LISP encapsulated data packet= with Y as the source of the inner data packet, and the adversary itself = as the source of the outer LISP encapsulating header. In such a case, the= ETR may "glean" the mapping that the adversary is the TR responsible for= EID Y. It will then "verify" (See Section 6.2) this mapping by sending a= map-request to EID Y. If the adversary is correct and is indeed on the p= ath of this map-request, then the adversary poisons the mapping cache as = in the previous case. Note that all of the above vulnerabilities require that the adversary be = on the path of some LISP packet. The security considerations of the docum= ent states that attacks by on-path adversaries aren't an issue because on= -path adversaries can already do lots of bad things in the current intern= et routing architecture. However, I believe that "poisoning" the mapping = cache is new capability that provides additional capabilities to an on-pa= th adversary that do not exist in today's non-LISP Internet. In particula= r, Internet routing is transient in the sense that if an adversary is on = the path of particular packet between A and B, it is likely that there wi= ll be many future packets between A and B for which the adversary is not = on the path. However, if the adversary can get a "false" mapping entry ac= cepted into a mapping cache with a long TTL, then the adversary can ensur= e that he is on the path between all future packets until the TTL expires= =2E The benefit that an adversary derives from "poisoning" a mapping cache is= that by being on the path between an ITR and some EID, he can put himsel= f on the path for all traffic to a prefix that contains the EID. (That is= , by being on the path to 10.0.98.116, an adversary can become on an on-p= ath attacker for all traffic to 10.0/16). This vulnerability is related t= o the discussion in 6.1.5.1, (Note to authors, please place a reference t= o Section 6.1.5.1 in your security considerations section.) however, as l= ong as this vulnerability exists, it gives an on-path adversary additiona= l capability beyond what such an adversary could accomplish on a non-LISP= Internet. Finally, I believe that the capabilities on an "on-path" attacker are esp= ecially cause for concern when mapping requests and responses are routing= using an alternative topology. (My apologies if I have misunderstood dra= ft-ietf-lisp-alt). In particular, it seems that if an adversary is "on th= e path" that a mapping request for EID Y from ITR X follows in the altern= ative topology, then he can poison the cache of ITR Y and become an on-pa= th attacker for all future traffic from ITR X to EID Y ... even though th= e adversary was never on the path to EID Y in the standard topology. (And= again, the adversary isn't just putting himself on the path to EID Y, he= 's putting himself on the path to all traffic in some prefix containing E= ID Y.) This final case is particularly troubling to me because I am conce= rned about the case where it is easier for an adversary to insert himself= into an Alternative topology path (by attacking the routing protocol) th= an it is for him to insert himself into a standard topology path. For ins= tance, the SIDR working group has recently completed work (RFC editor's q= ueue) that can provide protection against a certain class of mis-originat= ion attacks on BGP using a Resource Public Key Infrastructure. If this te= chnology were employed to protect certain autonomous systems in the stand= ard topology, the use of LISP-ALT would seem to defeat such protection by= allowing the adversary to perform the mis-origination attack in the alte= rnative topology to by-pass the protection implemented in the standard to= pology. One last note to the authors, in the first paragraph of the security cons= iderations where off-path adversaries are discussed, it would be helpful = to reference the specific section where you discuss return-routability me= chanisms for data-plane-triggered mappings. (It wasn't clear to me the fi= rst time I read that, what exactly you were referring to and so a referen= ce back to earlier text would be helpful.) Thanks - Matt Lepinski From radiaperlman@gmail.com Sun Dec 4 21:22:34 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 2236A21F8B2D; Sun, 4 Dec 2011 21:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DRUGS_ERECTILE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcRn2OOfh0id; Sun, 4 Dec 2011 21:22:33 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C405B21F8B2A; Sun, 4 Dec 2011 21:22:32 -0800 (PST) Received: by bkcjc3 with SMTP id jc3so354359bkc.31 for ; Sun, 04 Dec 2011 21:22:31 -0800 (PST) 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=aamozG+6sbimIHaNtvXRF06OKESh+safhTvxRGpZQhw=; b=PvYOLQve9He3I1d7eLvlF3HbyD86KMJDVIPmVaM2dDEBKrPsUehKSQptP1Oqb0jdUe RfczXiVH7drAcZH0G99OsA4rgPCWM89Dxwg/ZzUUxf43f1GYIFQqchsYUd6l57O8Otqx PofDTvoK9DhG1Zi7tRIyflLtaFu0rEcyNpbGo= MIME-Version: 1.0 Received: by 10.204.148.76 with SMTP id o12mr3535694bkv.114.1323062551756; Sun, 04 Dec 2011 21:22:31 -0800 (PST) Received: by 10.205.141.142 with HTTP; Sun, 4 Dec 2011 21:22:31 -0800 (PST) Date: Sun, 4 Dec 2011 21:22:31 -0800 Message-ID: From: Radia Perlman To: The IESG , secdir@ietf.org, draft-ietf-sieve-include.all@tools.ietf.org Content-Type: multipart/alternative; boundary=0015175cab7c69be9a04b35181b5 Subject: [secdir] Secdir review of draft-ietf-sieve-include-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 05:22:34 -0000 --0015175cab7c69be9a04b35181b5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Summary: No problems found with this document Summary of document: This document specifies an extension to an existing file format. That file format is defined in RFC5228 and specifies a format for incoming mail filtering and sorting rules (e.g. if subject field contains =93Viagra=94 delete the message). This extension defines an =91inc= lude=92 command, which allows someone to hierarchically organize mail filtering rules into separate files. The goal (among others) is so that there can be some common filters that lots of users might want to use, users can reference them with =91include=92 commands rather than copying their bodies into their own filtering rules, and the common filters can then be updated by a central authority and changes will automatically be reflected in each user=92s rules. This extension only introduces one interesting new security concern, and it is covered well in the security considerations. That concern is that a user might be able to trick the mail sorting utility into opening files that the user would not have permission to open. Depending on the OS, this might or might not be easy for the mail sorting utility to avoid, but the security considerations points out several variations, like making sure that file names really are file names (and not something that could escape itself into a shell script) and checking the access rules on the files to make sure that there is no privilege elevation. Radia --0015175cab7c69be9a04b35181b5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Summary: No problems found with this document
=A0
Summary of document: This document specifies an extension to an existi= ng file format. That file format is defined in RFC5228 and specifies a form= at for incoming mail filtering and sorting rules (e.g. if subject field con= tains =93Viagra=94 delete the message). This extension defines an =91includ= e=92 command, which allows someone to hierarchically organize mail filterin= g rules into separate files. The goal (among others) is so that there can b= e some common filters that lots of users might want to use, users can refer= ence them with =91include=92 commands rather than copying their bodies into= their own filtering rules, and the common filters can then be updated by a= central authority and changes will automatically be reflected in each user= =92s rules.
This extension only introduces one interesting new security concern, a= nd it is covered well in the security considerations. That concern is that = a user might be able to trick the mail sorting utility into opening files t= hat the user would not have permission to open. Depending on the OS, this m= ight or might not be easy for the mail sorting utility to avoid, but the se= curity considerations points out several variations, like making sure that = file names really are file names (and not something that could escape itsel= f into a shell script) and checking the access rules on the files to make s= ure that there is no privilege elevation.
=A0
Radia
--0015175cab7c69be9a04b35181b5-- From thomas.r.henderson@boeing.com Sun Dec 4 22:44:51 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 CBD7521F87D6; Sun, 4 Dec 2011 22:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A84gEChPLM7s; Sun, 4 Dec 2011 22:44:51 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id DA40A21F86F6; Sun, 4 Dec 2011 22:44:50 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id pB56ifRQ020016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Dec 2011 00:44:42 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id pB56iVga003055; Sun, 4 Dec 2011 22:44:31 -0800 (PST) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id pB56iU0J003045 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sun, 4 Dec 2011 22:44:31 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Sun, 4 Dec 2011 22:44:30 -0800 From: "Henderson, Thomas R" To: "'Tom Yu'" , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-tcpm-rfc3782-bis.all@tools.ietf.org" Date: Sun, 4 Dec 2011 22:44:29 -0800 Thread-Topic: secdir review of draft-ietf-tcpm-rfc3782-bis-03 Thread-Index: AcyprZN5UFdB6tUKRbaAmNES1AHeOQJa3ARQ Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CF2319BF7@XCH-NW-10V.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [secdir] secdir review of draft-ietf-tcpm-rfc3782-bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 06:44:51 -0000 Tom, thank you for providing helpful comments. I've posted a version -04 d= ocument just now with the revisions. Responses inline below. > -----Original Message----- > From: Tom Yu [mailto:tlyu@mit.edu] > Sent: Tuesday, November 22, 2011 11:00 PM > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-tcpm-rfc3782- > bis.all@tools.ietf.org > Subject: secdir review of draft-ietf-tcpm-rfc3782-bis-03 >=20 > The Security Considerations section of this document says: >=20 > [RFC5681] discusses general security considerations concerning TCP > congestion control. This document describes a specific algorithm > that conforms with the congestion control requirements of [RFC5681], > and so those considerations apply to this algorithm, too. There are > no known additional security concerns for this specific algorithm. >=20 > I believe this assessment is accurate. >=20 > Editorial: >=20 > I found it really confusing where Section 4 appears to directly copy > text from RFC 3782 with no fixups of section references and step > numbers. For example, 4.1 refers to a Step 1B of Section 3. There is > no Step 1B in this document, and the relevant section is actually > Section 3.2. Also, Section 4.2 refers to a Step 1A of Section 3, when > it probably means Step 2 of Section 3.2 of RFC 5681. These references have been fixed, thanks. >=20 > In Appendix B, first paragraph: >=20 > In [RFC3782], the cwnd after Full ACK reception will be set to > (1) min (ssthresh, FlightSize + SMSS) or (2) ssthresh. However, > there is a risk in the first logic which results in performance > degradation. With the first logic, if FlightSize is zero, the > result will be 1 SMSS. This means TCP can transmit only 1 segment > at this moment, which can cause delay in ACK transmission at > receiver > due to delayed ACK algorithm. >=20 > The phrase "first logic" sounds awkward, and should probably be "first > option", to align with the wording in Section 3.2. Improved as you suggested. >=20 > In Appendix B, end of second paragraph: >=20 > Even if window size is not small, > loss of ACK packets or receive buffer shortage during fast recovery > can also increase the possibility to fall into this situation. >=20 > should probably end with "...can also increase the possibility of > falling into this situation." Improved as you suggested. >=20 > In the third paragraph of Appendix B: >=20 > The proposed fix in this document ensures that sender TCP transmits > at least two segments on Full ACK reception. >=20 > I initially couldn't determine exactly what changes in this document > achieve the purported fix, but I'm not an expert at TCP. The text in > step 3 of Section 3.2 of this document is substantially the same when > describing the Full ACK behavior, and the prescribed options for > resetting the value of cwnd looked the same as in RFC 3782 until I > carefully compared them side by side. Perhaps more clearly > identifying the change, using text like: >=20 > The proposed fix in this document, which sets cwnd to at least > 2*SMSS if the implementation uses option 1 in the Full ACK > behavior, ensures that sender TCP transmits at least two segments > on Full ACK reception. >=20 > would be better. I improved this along the lines of your above suggestion. From warren@kumari.net Mon Dec 5 13:12: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 2C0FF1F0C83; Mon, 5 Dec 2011 13:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6mE+IKy7PYb; Mon, 5 Dec 2011 13:12:19 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id A5DD11F0C7A; Mon, 5 Dec 2011 13:12:19 -0800 (PST) Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id AF0E81B401A9; Mon, 5 Dec 2011 16:12:18 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Dec 2011 16:12:17 -0500 Message-Id: <8F3F12E8-E0A0-40ED-B2E0-5AC30A1D91F6@kumari.net> To: secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-idr-fsm-subcode.all@tools.ietf.org, IESG IESG Subject: [secdir] Secdir review of draft-ietf-idr-fsm-subcode-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 21:12:20 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. These 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 several subcodes for BGP Finite State Machine = Error that could provide more information to help network operators in = diagnosing BGP FSM issues and correlating network events. The Security Considerations section is short and to the point: "This = document does not change the security properties of BGP." This is true, and I see no other security considerations needed... W= From magnusn@gmail.com Mon Dec 12 00:10:39 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 3BCCA21F8A64; Mon, 12 Dec 2011 00:10:39 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuOKsxabYNMA; Mon, 12 Dec 2011 00:10:38 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA1EA21F84C2; Mon, 12 Dec 2011 00:10:37 -0800 (PST) Received: by ggnk5 with SMTP id k5so5857082ggn.31 for ; Mon, 12 Dec 2011 00:10:37 -0800 (PST) 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=KgBYF4ibikjGeo08+WR+situAy2m2f7E72b7+yU2zW0=; b=QRU2TtmPIGY5eAI1WT0b01hzS40t3N/yaq80P9di4T7uNLLpiOoOzSociZ0D3rnZTO iovSGmCL2Lboh7Y8zdskh2uFgRoadqy5U9epAET9UxnZLMBhttEZpPy3pPOzHqGsgDfu tQe6qDCci1YOACJ58S9T561whQBMKcvaecYGU= MIME-Version: 1.0 Received: by 10.50.155.195 with SMTP id vy3mr10301311igb.46.1323677437402; Mon, 12 Dec 2011 00:10:37 -0800 (PST) Received: by 10.50.208.65 with HTTP; Mon, 12 Dec 2011 00:10:37 -0800 (PST) Date: Mon, 12 Dec 2011 00:10:37 -0800 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ospf-multi-instance@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] Secdir review of draft-ietf-ospf-multi-instance 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, 12 Dec 2011 08:10:39 -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 a method for allowing multiple instances on the same domain in OSPFv2. Since the Autype field in OSPFv2 will be halved by this document then one concern would have been if there were existing implementations using Autype values large enough to set bits in the higher octet. According to the authors this is not the case and so the risk of re-use of existing Autype values does apparently not exist. Conversely, when a router which does not understand this new use of the Autype field is presented with a packet from a router that is instance-aware (and uses a non-zero instance-id value) it will not accept it since it would represent an unknown authentication type. I would therefore tend to agree with the authors that the introduction of an InstanceID as part of the previous Autype field should not be a cause of concern. Editorial: - Section 2: Unclear sentence: "In support of this capability, this document introduces a modified packet header format with the Authentication Type field is split into an Instance ID and AuType." (Probably the "is" should be removed/replaced) - Section 5: Refers to Appendix D but there is no Appendix D. Presumably the link should be to Appendix D of OSPFv2. -- Magnus From weiler+secdir@watson.org Mon Dec 12 13:01: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 7E91521F8A6C for ; Mon, 12 Dec 2011 13:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYNLj90odWfj for ; Mon, 12 Dec 2011 13:01:55 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 999D621F8A69 for ; Mon, 12 Dec 2011 13:01:53 -0800 (PST) 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 pBCL1pwd082242 for ; Mon, 12 Dec 2011 16:01:51 -0500 (EST) (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 pBCL1ooe082232 for ; Mon, 12 Dec 2011 16:01:51 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 12 Dec 2011 16:01:50 -0500 (EST) 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]); Mon, 12 Dec 2011 16:01:51 -0500 (EST) 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: Mon, 12 Dec 2011 21:01:55 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview The out-of-order assignments end this week; we're back to the regular rotation. Donald Eastlake is next in the rotation. For telechat 2011-12-15 Reviewer LC end Draft Phillip Hallam-Baker T 2011-12-07 draft-gerhards-syslog-plain-tcp-12 Scott Kelly TR2011-12-12 draft-ietf-geopriv-policy-uri-04 Russ Mundy T 2011-11-30 draft-ietf-ppsp-problem-statement-07 Sandy Murphy T 2011-11-10 draft-ietf-v6ops-happy-eyeballs-06 Nico Williams T 2011-11-17 draft-ietf-simple-msrp-cema-03 For telechat 2012-01-05 Reviewer LC end Draft Derek Atkins T 2012-01-06 draft-arkko-ipv6-only-experience-04 Alan DeKok T 2012-01-06 draft-yevstifeyev-disclosure-relation-00 Love Hornquist-Astrand T 2011-12-29 draft-daboo-webdav-sync-06 Jeffrey Hutzelman T 2011-12-26 draft-gregorio-uritemplate-07 Tim Polk T 2011-12-28 draft-kucherawy-dkim-atps-11 Eric Rescorla T 2011-12-29 draft-ohye-canonical-link-relation-04 Larry Zhu T 2012-01-05 draft-amundsen-item-and-collection-link-relations-04 For telechat 2012-01-19 Reviewer LC end Draft Rob Austein T 2012-01-11 draft-ash-gcac-algorithm-spec-03 Last calls and special requests: Reviewer LC end Draft Richard Barnes 2011-12-20 draft-ietf-sipclf-problem-statement-09 Uri Blumenthal 2011-12-19 draft-ietf-storm-rddp-registries-00 Dave Cridland 2012-01-03 draft-os-ietf-sshfp-ecdsa-sha2-04 Alan DeKok 2011-12-05 draft-ietf-6man-exthdr-05 Julien Laganier 2011-12-15 draft-ietf-marf-redaction-03 David McGrew 2011-12-12 draft-ietf-mpls-tp-mib-management-overview-05 Hilarie Orman 2011-12-13 draft-ietf-sidr-rpki-rtr-20 Tina TSOU 2011-04-23 draft-shin-augmented-pake-08 From mcgrew@cisco.com Mon Dec 12 13:18: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 B1FDA21F84A5; Mon, 12 Dec 2011 13:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iB5uayelmgQd; Mon, 12 Dec 2011 13:18:20 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 251CD21F847F; Mon, 12 Dec 2011 13:18:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=658; q=dns/txt; s=iport; t=1323724700; x=1324934300; h=message-id:from:to:content-transfer-encoding: mime-version:subject:date:cc; bh=bBO8xBfaTTMU9M6aWWqX+bDvxlQkSzxKTH2qccAZMUM=; b=LkYddeuKk7RNlVmSQIRrx2v+cZBWq0aBrnZ9FD7jljwUVFtoj4x30IOf IAzziIFwjma+DSGY8u51M5ENt4Fv9nnDTe3+MUbGGwxSlyQ3EFBBoBJgE 5lfJnR1euALOzBF3iDVFHHtlR11rSlTjFeWtMPdPZ/tweuI6j5FvYnrhK 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAHBu5k6rRDoI/2dsb2JhbABDqweBBYILASUCP4E/NJ5qAZ4xiwpjBIgxjECFS4x9 X-IronPort-AV: E=Sophos;i="4.71,341,1320624000"; d="scan'208";a="20284002" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 12 Dec 2011 21:18:18 +0000 Received: from [10.32.254.210] ([10.32.254.210]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBCLIHAs015125; Mon, 12 Dec 2011 21:18:18 GMT Message-Id: <3426FBC7-B75A-46B9-A341-D6CE0EFFAD28@cisco.com> From: David McGrew To: secdir@ietf.org, draft-ietf-mpls-tp-mib-management-overview.all@tools.ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Dec 2011 13:18:17 -0800 X-Mailer: Apple Mail (2.936) Cc: "iesg@ietf.org IESG" Subject: [secdir] secdir review of draft-ietf-mpls-tp-mib-management-overview-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 21:18:20 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These 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. As the draft says: "This document describes the interrelationships amongst the different MIB modules relevant to MPLS-TP management and as such does not have any security implications in and of itself." The draft does give some motivation and overview of SNMP security, which is useful. regards, David From hilarie@purplestreak.com Mon Dec 12 23: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 167E621F86A4 for ; Mon, 12 Dec 2011 23:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xo-B6b2w2+lK for ; Mon, 12 Dec 2011 23:29:54 -0800 (PST) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0AB21F86A0 for ; Mon, 12 Dec 2011 23:29:54 -0800 (PST) Received: from mx03.mta.xmission.com ([166.70.13.213]) by out02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RaMoE-0006Vt-4S for secdir@ietf.org; Tue, 13 Dec 2011 00:29:54 -0700 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=sylvester.rhmr.com) by mx03.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RaMoD-0005hI-DD for secdir@ietf.org; Tue, 13 Dec 2011 00:29:54 -0700 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBD7TZOf001426 for ; Tue, 13 Dec 2011 00:29:35 -0700 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id pBD7TWcU001389; Tue, 13 Dec 2011 00:29:32 -0700 Date: Tue, 13 Dec 2011 00:29:32 -0700 Message-Id: <201112130729.pBD7TWcU001389@sylvester.rhmr.com> From: "Hilarie Orman" To: secdir@ietf.org X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx03.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-DomainKey: sender_domain=purplestreak.com; ; ; sender=hilarie@purplestreak.com; ; ; status=error X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa02 1397; Body=2 Fuz1=2 Fuz2=2 X-Spam-Combo: ;secdir@ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600) X-SA-Exim-Scanned: Yes (on mx03.mta.xmission.com) Subject: [secdir] Review of draft-ietf-sidr-rpki-rtr-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 07:29:55 -0000 security review of The RPKI/Router Protocol, draft-ietf-sidr-rpki-rtr-20 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The protocol defines the communication between a router and an Autonomous System (AS) cache validated by public keys. This is part of a work in progress to secure routing infrastructure. The caches implement a "resource public key infrastructure (RPKI)". I'll accept on faith that the records in the cache are secured by public keys in a reasonable fashion. The problem addressed by the protocol is: how do routers securely obtain the records, under the hypothesis that they will not actually carry out validation? The answer is a simple protocol that concentrates assuring record freshness and punts security to some preconfigured point-to-point communication with some kind of transport security. This document cheerily anticipates the debut of I-cant-Believe-Its-Not-TCPMD5 (TCP-AO). The draft makes reference to "monkey in the middle attacks". I can't decide if this is more insulting to men or monkeys, but in any case, it needs some kind of reference to distinguish it from the more normal MITM term. The Security Considerations state: The identity of the cache server MUST be verified and authenticated by the router client, and vice versa, before any data are exchanged. yet there is no explanation of what this means, in general, because the protocol has no authentication component. Some of the transports can do this, but not all. More explanation is needed. The cache identifies its boot instance via a nonce, and the client routers are supposed to record the nonce and discard all records if the nonce changes. The nonce is only 16 bits, though, and the probability of two boot instances choosing the same nonce is too high, in my opinion. "Commensurate" is an odd term. It simply means "don't use the serial number if the nonce doesn't match." Hilarie From nico@cryptonector.com Tue Dec 13 21:51: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 318CB11E80BB for ; Tue, 13 Dec 2011 21:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4b+CiueZiBy for ; Tue, 13 Dec 2011 21:51:18 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 641FC11E80BA for ; Tue, 13 Dec 2011 21:51:18 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 26E16674059 for ; Tue, 13 Dec 2011 21:51:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:content-type; q=dns; s= cryptonector.com; b=ePohLPqxwcroRXdXqktUzVfWpQ08/bM2zVuHrVuKknxU 9e6RRGB1tu6St2rdUMHbR9chrgvr131azCG79n4WQ/N3MbBQTFdEuZIgmPgF3vkD ZlQvFdLFhxkbLQRtq67l5HhOaH9562ACVjonc0CpxTQw0lVf4QpcaUA4FP6WK8Q= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=jLgMVsGNGPRI/RnanW4nKLHuw6E=; b=P6TGESpCZ6C a+3/CtKZlqz+j7d6HxC+tMkFHpnb3u78kL83zS72N+Owz+Nzt7cxxyw/wa1DhKse 2ddbqBloKs36CxknbVo+jQprVHfJ+JI3LyBH+FbwALoVR957d+WGWg1nwV8Gjohl P31ZWobTAhMSXxZCVAjo6Vak9cadZTvY= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id EED2E674058 for ; Tue, 13 Dec 2011 21:51:17 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so369576vcb.31 for ; Tue, 13 Dec 2011 21:51:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.34.167 with SMTP id a7mr3043470vdj.123.1323841877297; Tue, 13 Dec 2011 21:51:17 -0800 (PST) Received: by 10.220.155.197 with HTTP; Tue, 13 Dec 2011 21:51:17 -0800 (PST) Date: Tue, 13 Dec 2011 23:51:17 -0600 Message-ID: From: Nico Williams To: secdir@ietf.org, draft-ietf-simple-msrp-cema.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [secdir] Review of draft-ietf-simple-msrp-cema-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: Wed, 14 Dec 2011 05:51:19 -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. CEMA is an SDP/MSRP extension that enables the "anchoring" of MSRP traffic through middleboxes that do not act as MITMs. This is a good thing if such anchoring is needed at all. The security considerations seems complete enough to me, and I believe it matches the media anchoring mechanism described in section 4, though I'm not sufficiently familiar with MSRP to say so for certain. In general it seems that CEMA improves security here (by allowing proxies to anchor media without having to act as MITMs) without making it worse in any way: in particular security generally depends on signaling security in SIP. Nico -- From christer.holmberg@ericsson.com Tue Dec 13 22:24: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 0F38C1F0C49 for ; Tue, 13 Dec 2011 22:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-drPEcb5D1z for ; Tue, 13 Dec 2011 22:24:42 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 37BDD1F0C38 for ; Tue, 13 Dec 2011 22:24:42 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-51-4ee84128adc1 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2A.AE.09514.82148EE4; Wed, 14 Dec 2011 07:24:40 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.67]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 14 Dec 2011 07:24:40 +0100 From: Christer Holmberg To: Nico Williams , "secdir@ietf.org" , "draft-ietf-simple-msrp-cema.all@tools.ietf.org" Date: Wed, 14 Dec 2011 07:24:39 +0100 Thread-Topic: Review of draft-ietf-simple-msrp-cema-03 Thread-Index: Acy6JJBh+6vecEo3Q6+XMEEATrCrRAABHC7Q Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3BD4D2D7@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [secdir] Review of draft-ietf-simple-msrp-cema-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: Wed, 14 Dec 2011 06:24:43 -0000 Thank You very much for the review, Nico! Regards, Christer=20 > -----Original Message----- > From: Nico Williams [mailto:nico@cryptonector.com]=20 > Sent: 14. joulukuuta 2011 7:51 > To: secdir@ietf.org; draft-ietf-simple-msrp-cema.all@tools.ietf.org > Subject: Review of draft-ietf-simple-msrp-cema-03 >=20 > I have reviewed this document as part of the security=20 > directorate's ongoing effort to review all IETF documents=20 > being processed by the IESG. These comments were written=20 > primarily for the benefit of the security area directors.=20 > Document editors and WG chairs should treat these comments=20 > just like any other last call comments. >=20 > CEMA is an SDP/MSRP extension that enables the "anchoring" of=20 > MSRP traffic through middleboxes that do not act as MITMs. =20 > This is a good thing if such anchoring is needed at all. >=20 > The security considerations seems complete enough to me, and=20 > I believe it matches the media anchoring mechanism described=20 > in section 4, though I'm not sufficiently familiar with MSRP=20 > to say so for certain. > In general it seems that CEMA improves security here (by=20 > allowing proxies to anchor media without having to act as=20 > MITMs) without making it worse in any way: in particular=20 > security generally depends on signaling security in SIP. >=20 > Nico > -- > = From Sandra.Murphy@sparta.com Wed Dec 14 13:52:57 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 7B87611E80C9 for ; Wed, 14 Dec 2011 13:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tB8tjNeqHhoD for ; Wed, 14 Dec 2011 13:52:54 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 34CFC11E80C5 for ; Wed, 14 Dec 2011 13:52:54 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id pBELqrbF010620; Wed, 14 Dec 2011 15:52:53 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id pBELqoBv018907; Wed, 14 Dec 2011 15:52:50 -0600 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0339.001; Wed, 14 Dec 2011 16:52:43 -0500 From: "Murphy, Sandra" To: "secdir@ietf.org" , "v6ops-chairs@tools.ietf.org" , "draft-ietf-v6ops-happy-eyeballs@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-v6ops-happy-eyeballs Thread-Index: Acy6qkJoFrROnN5WT3Kq6sN+TRQwMw== Date: Wed, 14 Dec 2011 21:52:42 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6037913@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] secdir review of draft-ietf-v6ops-happy-eyeballs 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, 14 Dec 2011 21:52:57 -0000 I have reviewed this document draft-ietf-v6ops-happy-eyeballs-06 as part of= =0A= the security directorate's ongoing effort to review all IETF documents bein= g =0A= processed by the IESG. These comments were written primarily for the =0A= benefit of the security area directors. Document editors and WG chairs =0A= should treat these comments just like any other last call comments.=0A= =0A= This document sets requirements for any algorithm that produces "happy =0A= eyeballs" in a dual stack host =96 that is, an algorithm that reduces the d= elay =0A= due to making connection attempts with IPv6 addresses first and trying IPv4= =0A= only when the IPv6 attempt fails.=0A= =0A= The document attempts to be agnostic as to whether the preferred algorithm= =0A= is IPv6 or IPv4, but many of the statements only make sense if you presume = =0A= that the preferred algorithm is IPv6.=0A= =0A= The security considerations section points to the discussions in the text o= f =0A= "same origin" policies in web browsers, and problems that might occur if = =0A= different addresses were used on different connection attempts to the =0A= same origin. I can see that difficulties might occur if different addresse= s =0A= were used on different connection attempts to the same URI, so URIs of =0A= the same origin could also be a problem. But I do not understand the =0A= security interaction with the same origin policies, since draft-ietf-websec= -origin=0A= defines "same origin" only in terms of the host name part of the URI:=0A= =0A= o If the two origins are scheme/host/port triples, the two origins=0A= are the same if, and only if, they have identical schemes, hosts,=0A= and ports.=0A= =0A= I am wondering about IPSec complications with this new procedure. I =0A= suppose that there is ample opportunity to have inconsistent IPSec =0A= policies between ipv6 and ipv4 addresses for the same parts of the =0A= Internet. I don't think that there is a way for IPSec to express a =0A= preference for the address family, but the system address family =0A= preference might include IPSec as choosing the preference (what border =0A= point it would be going through, maybe?). Does a use of the =0A= winning address family over the preferred address family present =0A= an opportunity to get an unintended security result (like maybe =0A= downgrade almost)?=0A= =0A= The following are comments about the writing, not security.=0A= =0A= There are many places in the document where I was confused by the text.=0A= =0A= Page 4=0A= As discussed in more detail in Section 3.2, IPv6 connectivity is=0A= broken to specific prefixes or specific hosts, or slower than native=0A= IPv4 connectivity.=0A= =0A= Huh? Not always. I suspect this means "we focus on situations=0A= where" or "can be broken . . . or slower".=0A= =0A= Page 9=0A= (This is an example of text that makes more sense if you presume =0A= that the preferred address family is v6)=0A= =0A= Such an implementation MAY make subsequent connection attempts (to=0A= the same host or to other hosts) on the successful address family=0A= (e.g., IPv4). So long as new connections are being attempted by the=0A= host, such an implementation MUST occasionally make connection=0A= attempts using the host's preferred address family, as it may have=0A= become functional again, and it SHOULD do so every 10 minutes. The=0A= 10 minute delay before re-trying a failed address family avoids the=0A= simple doubling of connection attempts on both IPv6 and IPv4.=0A= Implementation note: this can be achieved by flushing Happy Eyeballs=0A= state every every 10 minutes, which does not significantly harm the=0A= application's subsequent connection setup time. If connections using=0A= the preferred address family are again successful, the preferred=0A= address family SHOULD be used for subsequent connections. Because=0A= this implementation is stateful, it MAY track connection success (or=0A= failure) based on IPv6 or IPv4 prefix (e.g., connections to the same=0A= prefix assigned to the interface are successful whereas connections=0A= to other prefixes are failing).=0A= =0A= I was confused that the first winning address family was allowed to be =0A= used:=0A= =0A= Such an implementation MAY make subsequent connection attempts (to=0A= the same host or to other hosts) on the successful address family=0A= =0A= in subsequent connections but the winning address family in retries was =0A= encouraged to be used in subsequent connections:=0A= =0A= If connections using=0A= the preferred address family are again successful, the preferred=0A= address family SHOULD be used for subsequent connections.=0A= =0A= This makes more sense if you presume they are talking about a situation =0A= where ipv6 is preferred, the ipv6 address was tried and failed. The first = =0A= successful address family was ipv4 and the later retry succeeded with ipv6.= =0A= =0A= So it is OK to keep using the ipv4 address, but once ipv6 has succeeded =0A= the recommendation is much stronger to continue to use the ipv6 address.=0A= =0A= I believe that the sentence that says =0A= it MAY track connection success (or=0A= failure) based on IPv6 or IPv4 prefix (e.g., connections to the same=0A= prefix assigned to the interface are successful whereas connections=0A= to other prefixes are failing).=0A= =0A= means that is implementations MAY track success by address family =0A= only, rather than per-prefix. (But I am not at all sure what the =0A= "assigned to the interface" means.)=0A= =0A= page 10=0A= =0A= While IPv6/IPv4 translation makes that difficult, IPv6/=0A= IPv4 translators do not need to be deployed on networks with dual=0A= stack clients, because dual stack clients can use their native IP=0A= address family.=0A= =0A= Is it expected that networks will migrate from ipv4-only to dual stack =0A= as a whole =96 there will not be a mix of ipv4-only and dual stack hosts = =0A= on the same network? If there is a mix, will the presence of translators = =0A= for the ipv4-only hosts present the mentioned difficulties to the dual =0A= stack hosts?=0A= =0A= Page 11=0A= =0A= Section 5.4 says:=0A= It is possible that an DNS query for an A or AAAA resource record=0A= will return more than one A or AAAA address. When this occurs, it is=0A= RECOMMENDED that a Happy Eyeballs implementation order the responses=0A= following the host's address preference policy and then try the first=0A= address. If that fails after a certain time (see Section 5.5), the=0A= next address SHOULD be the IPv4 address.=0A= =0A= Section 6 puts it differently:=0A= =0A= 3. If that connection does not complete within a short period of=0A= time (e.g., 200-300ms), initiate a connection attempt with the=0A= first address belonging to the other address family (e.g., IPv4)=0A= =0A= What if the preferred address family is ipv4?=0A= =0A= Section 5.5 says:=0A= =0A= Stateful algorithms are expected=0A= to be more aggressive (that is, make connection attempts closer=0A= together), as stateful algorithms maintain an estimate of the=0A= expected connection completion time.=0A= =0A= Do you mean the stateful algorithms are capable of maintaining an estimate?= =0A= Or do you mean that they always maintain an estimate (a SHOULD or MUST)?=0A= =0A= Section 5.6 says:=0A= Web browsers implement a Same Origin Policy [I-D.ietf-websec-origin]=0A= which causes subsequent connections to the same hostname to go to the=0A= same IPv4 (or IPv6) address as the previous successful connection.=0A= =0A= Do you mean "*requires* subsequent connections? I don't see how the =0A= policy causes an address choice.=0A= =0A= --Sandy Murphy=0A= From mundy@sparta.com Wed Dec 14 21:05:26 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 A607721F8ABD; Wed, 14 Dec 2011 21:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYZsfUjJ57KU; Wed, 14 Dec 2011 21:05:26 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id DF18921F8ABB; Wed, 14 Dec 2011 21:05:25 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id pBF55PaO012823; Wed, 14 Dec 2011 23:05:25 -0600 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id pBF55NBA025264; Wed, 14 Dec 2011 23:05:23 -0600 Received: from spiff.tislabs.com ([192.94.214.200]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Dec 2011 00:05:23 -0500 Received: from ubvm (unknown [10.66.1.77]) by spiff.tislabs.com (Postfix) with ESMTPS id C93CD5B51424; Thu, 15 Dec 2011 00:05:22 -0500 (EST) Received: from [127.0.0.1] (ubvm [172.16.115.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mundy) by ubvm (Postfix) with ESMTPSA id B0A4F27EFE8; Thu, 15 Dec 2011 00:05:21 -0500 (EST) From: Russ Mundy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Dec 2011 00:05:19 -0500 Message-Id: To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ppsp-problem-statement-all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 15 Dec 2011 05:05:23.0428 (UTC) FILETIME=[2692FA40:01CCBAE7] Cc: Russ Mundy Subject: [secdir] secdir Review of draft-ietf-ppsp-problem-statement 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, 15 Dec 2011 05:05:26 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. The document has more of a "marketing" tone to it than most IETF = documents and, as such, seems more like a "why do we need to do this = ppsp protocol" (or protocol suite?) than a problem statement. On the = other hand, if the working group believes that publishing this = information will help with reaching their goals or providing context to = potential future implementers of actual protocol specifications, I don't = see any reason not to publish it - as long as it remains Informational. With respect to the security considerations section, the information = seems to be good particularly since the document itself covers a wide = range of potential protocol specifications. Requiring subsequent = specifications to address specific threats and mitigations is good but = it would also be good for these specifications to document specific = security requirements for the protocols as well as the threats. = Additionally, specifically excluding support for a particular = requirement (Digital Rights Management (DRM)) does not seem to make = sense in this document since it claims to be a problem statement - this = sounds much more like the statement of a non-requirement than a security = consideration and should be in some requirements document or the = requirements section of protocol specifications. Russ Mundy From acee.lindem@ericsson.com Tue Dec 20 07:44: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 5737B21F867F; Tue, 20 Dec 2011 07:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGni+mi5z0cY; Tue, 20 Dec 2011 07:44:18 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8116521F85DB; Tue, 20 Dec 2011 07:44:18 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBKFi8fO002715; Tue, 20 Dec 2011 09:44:09 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.25]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 20 Dec 2011 10:44:03 -0500 From: Acee Lindem To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= Date: Tue, 20 Dec 2011 10:44:01 -0500 Thread-Topic: Secdir review of draft-ietf-ospf-multi-instance Thread-Index: Acy/LjM2xBipeG47T9yYPtk4JOThuw== Message-ID: <5B3F2069-57A3-47B6-9551-8F003EB6EE69@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-12-343774489"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "draft-ietf-ospf-multi-instance@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ospf-multi-instance 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, 20 Dec 2011 15:44:19 -0000 --Apple-Mail-12-343774489 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Magnus,=20 Thanks for the review. See inline.=20 On Dec 12, 2011, at 3:10 AM, Magnus Nystr=F6m wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > This document describes a method for allowing multiple instances on > the same domain in OSPFv2. >=20 > Since the Autype field in OSPFv2 will be halved by this document then > one concern would have been if there were existing implementations > using Autype values large enough to set bits in the higher octet. > According to the authors this is not the case and so the risk of > re-use of existing Autype values does apparently not exist. Actually, values greater than 256 are reserved. We've only used two = authentication types and we have a third in a WG draft.=20 = http://www.iana.org/assignments/ospf-authentication-codes/ospf-authenticat= ion-codes.xml Since we made the decision a long time ago to make the authentication = algorithm a property of the Security Association (SA) and not the = authentication type, we do not anticipate many new authentication types = in the future.=20 > Conversely, when a router which does not understand this new use of > the Autype field is presented with a packet from a router that is > instance-aware (and uses a non-zero instance-id value) it will not > accept it since it would represent an unknown authentication type. I > would therefore tend to agree with the authors that the introduction > of an InstanceID as part of the previous Autype field should not be a > cause of concern. Yes.=20 >=20 > Editorial: > - Section 2: Unclear sentence: "In support of this capability, this > document introduces a modified packet header format with the > Authentication Type field is split into an Instance ID and AuType." > (Probably the "is" should be removed/replaced) Yes - I will update in the next revision.=20 >=20 > - Section 5: Refers to Appendix D but there is no Appendix D. > Presumably the link should be to Appendix D of OSPFv2. Yes - I will update this as well.=20 I anticipate doing this next week as I'm off of work for the holidays. I = will send a follow-up E-mail once it is posted.=20 Thanks Again, Acee=20 >=20 > -- Magnus --Apple-Mail-12-343774489 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTIyMDE1NDQwMlowIwYJKoZI hvcNAQkEMRYEFPYklJlR37NRXSrJTnCFDXHU5rLhMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgEZlgvrS83a4U8IcjFnNSUBKKnXMsw3BmiF8EUbz91Q+8+fAYaDoYjxzHgLmxdDY 1bK0mD2bpowvNdBzBRxU2eHW3/eb7BaIqshq/8/dAp0uCtNU5i5QCptPoq0jd1Xugqqza7yOI7Ot 0yc5MTCdlkivtyE8nLg4V5z7+jyJhMsQAAAAAAAA --Apple-Mail-12-343774489-- From weiler+secdir@watson.org Wed Dec 21 08:47:25 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 38BD521F84D5 for ; Wed, 21 Dec 2011 08:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcSBm5H6s7jp for ; Wed, 21 Dec 2011 08:47:24 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id A12D221F84C2 for ; Wed, 21 Dec 2011 08:47:24 -0800 (PST) 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 pBLGlMGP096917 for ; Wed, 21 Dec 2011 11:47:22 -0500 (EST) (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 pBLGlMHp096910 for ; Wed, 21 Dec 2011 11:47:22 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 21 Dec 2011 11:47:21 -0500 (EST) 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]); Wed, 21 Dec 2011 11:47:22 -0500 (EST) 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: Wed, 21 Dec 2011 16:47:25 -0000 The next telechat is on January 5th, and most of the outstanding previosuly-assigned docs are scheduled for it. I hope everyone enjoys the upcoming holidays, however you celebrate them. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Sam Hartman is next in the rotation. For telechat 2012-01-05 Reviewer LC end Draft Derek Atkins T 2012-01-06 draft-arkko-ipv6-only-experience-04 Richard Barnes T 2011-12-20 draft-ietf-sipclf-problem-statement-09 Alan DeKok T 2011-12-05 draft-ietf-6man-exthdr-05 Alan DeKok T 2012-01-06 draft-yevstifeyev-disclosure-relation-00 Donald Eastlake T 2012-01-04 draft-ietf-6lowpan-nd-18 Shawn Emery T - draft-ietf-rtgwg-lfa-applicability-04 Tobias Gondrom T 2012-01-04 draft-ietf-softwire-gateway-init-ds-lite-06 Dan Harkins T 2012-01-05 draft-amundsen-item-and-collection-link-relations-04 Love Hornquist-Astrand T 2011-12-29 draft-daboo-webdav-sync-06 Jeffrey Hutzelman T 2011-12-26 draft-gregorio-uritemplate-07 Julien Laganier T 2011-12-15 draft-ietf-marf-redaction-03 Tim Polk T 2011-12-28 draft-kucherawy-dkim-atps-11 Eric Rescorla T 2011-12-29 draft-ohye-canonical-link-relation-04 For telechat 2012-01-19 Rob Austein T 2012-01-11 draft-ash-gcac-algorithm-spec-03 Phillip Hallam-Baker T 2012-01-18 draft-jiang-a6-to-historic-00 Last calls and special requests: Reviewer LC end Draft Uri Blumenthal 2011-12-19 draft-ietf-storm-rddp-registries-00 Dave Cridland 2012-01-03 draft-os-ietf-sshfp-ecdsa-sha2-04 Steve Hanna 2012-01-13 draft-nottingham-http-new-status-03 Tina TSOU 2011-04-23 draft-shin-augmented-pake-08 From new-work-bounces@ietf.org Tue Dec 20 09:19:05 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 4E82B21F8ABD; Tue, 20 Dec 2011 09:19:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1324401545; bh=o6Dc0tTttuZ0BoriI7FIefmqTfNU8pAfOMUaLuIeqRQ=; h=From:To:Mime-Version:Message-Id:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=Je4lkc8u/LMArbBYm66ps5rDfLYNT8syOH7fLyFyNRm9l9sno0jsGMYafmFppvk3g HqG5N22445vnW6DRfSwL6IksABKKzy3wRUp5nWZt6PePHRtVTrXwVzEPAp1BcJcEtS QNNGyPbHiqOJulsNzZrW+tMZhLMhSwNomGiSvvgo= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 705B921F8AC9; Tue, 20 Dec 2011 09:19:04 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20111220171904.705B921F8AC9@ietfa.amsl.com> Date: Tue, 20 Dec 2011 09:19:04 -0800 (PST) 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: Wed, 21 Dec 2011 08:53:39 -0800 Subject: [secdir] [new-work] WG Review: SPF Update (spfbis) 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, 20 Dec 2011 17:19:05 -0000 A new IETF working group has been proposed in the Applications 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, December 27, 2011 SPF Update (spfbis) ----------------------------------------- Status: Proposed Working Group Last Updated: 2011-12-09 Chair(s): TBD Applications Area Director(s): Pete Resnick Peter Saint-Andre Applications Area Advisor: Pete Resnick Mailing Lists: General Discussion:spfbis@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/spfbis Archive: http://www.ietf.org/mail-archive/web/spfbis/ Description of Working Group: The Sender Policy Framework (SPF, RFC4408) specifies the publication of a DNS record which states that a listed IP address is authorized to send mail on behalf of the listing domain name's owner. SMTP servers extract the domain name in the SMTP "MAIL FROM" or "HELO" command for confirming this authorization. The protocol has had Experimental status for some years and has become widely deployed. This working group will revise the specification, based on deployment experience and listed errata, and will seek Standards Track status for the protocol. The MARID working group created two specifications for publication of email-sending authorization: Sender-ID (RFFC4405, RFC4406 and RFC4407) and SPF (RFC4408), with both having Experimental status. By using IP addresses, both protocols specify authorization in terms of path, though unlike SPF, Sender-ID uses domain names found in the header of the message rather than the envelope. The two protocols rely on the same policy publication mechanism, namely a specific TXT resource record in the DNS. This creates a basic ambiguity about the interpretation of any specific instance of the TXT record. Because of this, there were concerns about conflicts between the two in concurrent operation. The IESG Note added to each invited an expression of community consensus in the period following these publications. Both enjoyed initially large deployments. Broad SPF use continues, and its linkage to the envelope -- rather than Sender-ID's linkage to identifiers in the message content -- has proven sufficient among operators. This concludes the experiment. Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language. The working group will also produce a document describing the course of the SPF/Sender-ID experiment (defined in the IESG note on the RFCs in question), bringing that experiment to a formal conclusion. No other work on Sender-ID will be done. Finally, the working group will develop the proposed "scope" extension found in draft-mehnle-spfbis-scope. Specifically out-of-scope for this working group: * Revisiting past technical arguments that were covered in the MARID working group, except where review is reasonably warranted based on operational experience. * Discussion of the merits of SPF. * Discussion of the merits of Sender-ID in preference to SPF. * Extensions to SPF other than the one specified above. The working group will re-charter to process other specific proposed extensions as they are identified. The initial draft set: draft-kitterman-4408bis draft-mehnle-spfbis-scope Goals and Milestones: MMM YYYY: A standards track document defining SPF, based on RFC4408 and as amended above, to the IESG for publication. MMM YYYY: A document describing the SPF/Sender-ID experiment and its conclusions to the IESG for publication. MMM YYYY: A standards track document creating the "scope" extension to the IESG for publication. _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From dharkins@lounge.org Wed Dec 28 10:13:33 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 7675321F8510; Wed, 28 Dec 2011 10:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.87 X-Spam-Level: X-Spam-Status: No, score=-4.87 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXjIyTZT2MlI; Wed, 28 Dec 2011 10:13:33 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA0421F850D; Wed, 28 Dec 2011 10:13:33 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id B54221022404A; Wed, 28 Dec 2011 10:13:32 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 28 Dec 2011 10:13:32 -0800 (PST) Message-ID: Date: Wed, 28 Dec 2011 10:13:32 -0800 (PST) From: "Dan Harkins" To: 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 Cc: draft-amundsen-item-and-collection-link-relations.all@tools.ietf.org Subject: [secdir] review of draft-amundsen-item-and-collection-link-relations 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, 28 Dec 2011 18:13:33 -0000 Hello, I have reviewed draft-amundsen-item-and-collection-link-relations 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 adds two new kinds of web links for "item" and "collection" to allow web resources to identify a relationship as part of a collection and, back the other way, for the collection to identify items that comprise it. Web links were defined in RFC 5988 and that document has a nice Security Considerations section. I see no security issues with this draft that would warrant any special mention and the Security Considerations of this draft basically state that. My only nit is to get rid of the passive voice in the Security Considerations, that is: 's/are not believed to/do not/'. regards, Dan. From weiler+secdir@watson.org Thu Dec 29 15:25: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 CEFB221F8AAC for ; Thu, 29 Dec 2011 15:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCNLy-qlkQ9M for ; Thu, 29 Dec 2011 15:25:17 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2F49B21F8AA8 for ; Thu, 29 Dec 2011 15:25:16 -0800 (PST) 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 pBTNPFr0063272 for ; Thu, 29 Dec 2011 18:25:15 -0500 (EST) (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 pBTNPE1n063267 for ; Thu, 29 Dec 2011 18:25:14 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 29 Dec 2011 18:25:14 -0500 (EST) 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]); Thu, 29 Dec 2011 18:25:15 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 23:25:17 -0000 I hope everyone had a good Christmas and has a pleasant and safe New Year celebration. As I observed last week, "most of the outstanding previosuly-assigned docs are scheduled for [the January 5th telechat]". If you have an old assignment, that document is likely on the telechat next week. Only four new assignments today. Leif Johansson is next in the rotation. For telechat 2012-01-05 Reviewer LC end Draft Derek Atkins T 2012-01-06 draft-arkko-ipv6-only-experience-04 Richard Barnes T 2011-12-20 draft-ietf-sipclf-problem-statement-09 Uri Blumenthal T 2011-12-19 draft-ietf-storm-rddp-registries-01 Alan DeKok T 2011-12-05 draft-ietf-6man-exthdr-05 Alan DeKok T 2012-01-06 draft-yevstifeyev-disclosure-relation-00 Donald Eastlake T 2012-01-04 draft-ietf-6lowpan-nd-18 Shawn Emery T - draft-ietf-rtgwg-lfa-applicability-04 Tobias Gondrom T 2012-01-04 draft-ietf-softwire-gateway-init-ds-lite-06 Love Hornquist-Astrand T 2011-12-29 draft-daboo-webdav-sync-06 Jeffrey Hutzelman T 2011-12-26 draft-gregorio-uritemplate-07 Tim Polk T 2011-12-28 draft-kucherawy-dkim-atps-13 Eric Rescorla T 2011-12-29 draft-ohye-canonical-link-relation-04 For telechat 2012-01-19 Reviewer LC end Draft Rob Austein T 2012-01-11 draft-ash-gcac-algorithm-spec-03 Phillip Hallam-Baker T 2012-01-18 draft-jiang-a6-to-historic-00 Jeffrey Hutzelman T 2012-01-04 draft-ietf-marf-authfailure-report-07 Julien Laganier T 2011-12-15 draft-ietf-marf-redaction-03 Last calls and special requests: Reviewer LC end Draft Dave Cridland 2012-01-03 draft-os-ietf-sshfp-ecdsa-sha2-04 Steve Hanna 2012-01-13 draft-nottingham-http-new-status-03 Sam Hartman 2012-01-05 draft-ietf-kitten-sasl-saml-06 Paul Hoffman 2012-01-12 draft-ietf-alto-reqs-12 Love Hornquist-Astrand 2012-01-13 draft-ietf-pcn-signaling-requirements-07 Tina TSOU 2011-04-23 draft-shin-augmented-pake-08 From rbarnes@bbn.com Fri Dec 30 13:32: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 BF06121F8450; Fri, 30 Dec 2011 13:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKD3T-wb8FdX; Fri, 30 Dec 2011 13:32:03 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id DA24A21F843A; Fri, 30 Dec 2011 13:32:03 -0800 (PST) Received: from [128.89.254.178] (port=51782 helo=[192.168.1.3]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Rgk3W-000Blp-Qh; Fri, 30 Dec 2011 16:32:03 -0500 From: Richard L. Barnes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Dec 2011 16:32:02 -0500 Message-Id: To: secdir@ietf.org, The IESG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] secdir review of draft-ietf-sipclf-problem-statement-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 21:32:04 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document provides a set of goals and a data model for a "common = logging format" for SIP, in analogy to the widely-used Apache log format = for HTTP. As the document correctly notes, the primary concern for this = document is the protection of potentially private data protected in such = logs. I do not think that the document misses any serious security = considerations. A couple of relatively minor comments: Section 5.1:=20 s/of a B2BUA/or a B2BUA/ Section 6:=20 It seems to me that the document would read better if this section were = swapped with Section 5. Section 6: You mention training anomaly-detection systems based on SIPCLF logs. It = seems to me that this approach could be much more limited for SIP than = it is for HTTP, both because of the greater inherent diversity in SIP = and because of SIPCLF does not have visibility into the media path. So = it could be good to comment on what these systems would and would not = detect, either here or in the Security Considerations. Are you aware = of any existing anomaly detection systems that would be able to use = SIPCLF data?=20 Section 8.1, Source-Address / Destination-Address: These definitions are a little ambiguous. I assume you mean the address = of the source/destination for a particular UDP/DTLS datagram or TCP/TLS = connection, as opposed to an address for a SIP-layer recipient. For = example, for an INVITE in the following topology... UAC -> ProxyA -> ProxyB -> UAS ... If ProxyB were logging in SIPCLF, then the inbound invite would have = Source-Address=3DIP(ProxyA) and Destination-Address=3DIP(ProxyB). Section 9.1: It would be helpful to have SIP messages to refer to here, either by = including them in this document, or by referring to a document = containing them, such as RFC 3665. Section 10: It seems important to note here that both operators and users have = private information at stake here -- topology mapping vs. identity = correlators and calling patterns. =20 Section 10:=20 With regard to transmitting logs over the Internet, the reference to RFC = 3552 is not very useful. More concrete examples would be better, e.g., = HTTPS, SSH. Might it also be possible/useful to convey SIPCLF messages = over Syslog?