Re: RESEND: Secdir review of draft-ietf-pwe3-oam-msg-map-14.txt=

On Jan 9, 2011, at 11:43 PM, Charlie = Kaufman 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.

I = don=92t know the back story on this document. It is an individual = submission, I assume targeting Informational status. The title is = =93Internet Protocols for the Smart Grid=94. I didn=92t immediately know = what =93Smart Grid=94 referred to, and the document assumes the reader = already knows, but a quick web search says that current usage is for an = upgrade to the electrical power grid supporting innovations like having = large numbers of small providers and intelligently managing load (i.e. = turning off low priority devices under conditions of peak load) so that = we don=92t need to provision for peak loads so much larger than average = loads.

Most of this document has = little to do with the Smart Grid. It is largely an overview of the = Internet Protocol Suite referencing the relevant RFCs for details. I = would have thought that such an overview would already exist, but my = quick search of RFCs did not find one. This would be a handy document to = be able to point newbies at, though this title might dissuade them. It=92s= possible that this overview leaves out broad swaths of IETF work = on the theory that it would be irrelevant to Smart Grid designers, but = such filtering was not obvious.
The part of this document that is = about the Smart Grid is Appendix A, which speculates on several ways the = Smart Grid might take advantages of Internet technology. I would hope = that the people designing the Smart Grid would be familiar with the = Internet Protocol Suite, but perhaps I=92m being = na=EFve.

Security is one of the most = important challenges designers of a Smart Grid will face, and this = document emphasizes parts of the Internet Protocol Suite that provide = security and that might be applicable (i.e. IPsec, TLS, XML-DSIG, and = S/MIME). [Note: I believe a reference to CMS would be more useful than = the indirect references to it via S/MIME]. It does not address (that I = saw) the fact that since the Smart Grid is a real time control system, = dealing effectively with Denial of Service attacks will be particularly = important in this context. While a lot of work has gone into QoS = guarantees on the Internet, my impression is that most of that work is = not standardized. The fact that the use of the power grid as a = networking mechanism appears to target non-general purpose use (i.e. it = does not appear anyone is planning to run on-demand video over it) makes = it plausible that this problem is = solvable.

Because this document does not = propose a specific protocol, is has only a token =93Security = Considerations=94 section (that notes that security is discussed in some = other sections). That seems appropriate to me.

I noted a couple of = typos:

P50 next to last line: =93a = distributed application in a set collectors=94 -> = ???

P52 first line: = unbalanced quotes.

> If this data MUST be a well-formed PANA packet, >> the security issues are minimal. But I don't see that requirement >> clearly in the document. > > This is the DPI aspect. The PRE can't verify that it's sending a valid PANA packet to the PaC? > What should we check for well-formation? Many if not all fields in the PANA > header may be updated by future releases of the spec (extensions, etc.). so > checking on them would force the PRE to get upgraded (with a revised version > of PANA-relay spec each time) when PaC/PAA gets upgraded. This is very > undesirable. Some basic level of checks should be possible. > I think we shall stick to relying on PAA-PRE security. Then it should be a MUST. Alan DeKok. From aland@deployingradius.com Mon Jan 10 05:23:37 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DAFD3A6AFB; Mon, 10 Jan 2011 05:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVyXG6uY9VOt; Mon, 10 Jan 2011 05:23:36 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 52A333A6AFA; Mon, 10 Jan 2011 05:23:36 -0800 (PST) Message-ID: <4D2B08DD.6010603@deployingradius.com> Date: Mon, 10 Jan 2011 14:25:49 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Margaret Wasserman References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> <001101cb9aa0$367b3480$a3719d80$@yegin@yegin.org> <4D064683.30009@deployingradius.com> <4D07A874.4010702@gridmerge.com> <4D07D090.9020407@deployingradius.com> <070601cba3ad$63852150$2a8f63f0$@yegin@yegin.org> <4D270D1D.8090006@deployingradius.com> <005f01cbb0b2$2bc21cc0$83465640$@yegin@yegin.org> <4D2AE752.2000504@deployingradius.com> <006001cbb0b7$da450050$8ecf00f0$@yegin@yegin.org> <4D2AF65C.6060903@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org, paduffy@cisco.com, Alper Yegin , pana@ietf.org, robert.cragie@gridmerge.com, samitac@ipinfusion.com, 'Ralph Droms' Subject: Re: [secdir] pana-relay security considerations X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 13:23:37 -0000 Margaret Wasserman wrote: > In my opinion, a security mechanism for PRE-PAA authentication needs to > be defined in this spec before we publish it. I think it should be > optional to actually _use_ the security mechanism, though since there > some situations (such as closed or otherwise secured networks) where > this type of security isn't required operationally. The security > considerations should make it clear what the risks are, and describe the > situations in which it would be safe not to use the PRE-to-PAA security. > > Alan, would that satisfy your concerns? PANA folks, would that meet > your needs? That would satisfy my concerns, yes. Alan DeKok. From margaretw42@gmail.com Mon Jan 10 04:24:33 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31F5D28C134; Mon, 10 Jan 2011 04:24:33 -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=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx7sKxe-XL9n; Mon, 10 Jan 2011 04:24:32 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 1900028C133; Mon, 10 Jan 2011 04:24:32 -0800 (PST) Received: by vws7 with SMTP id 7so7836867vws.31 for ; Mon, 10 Jan 2011 04:26:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=QwZUdrojJsTawoc3ox31HEtl+igA41D9Ao7nLYLQ+Yo=; b=fLs78LQt/dPIhQE8t7yX624IGZye9cb5ai7meYT3F/IC0Cfw7jrSTmaCaxn5xiudoQ HtOWrBQBLOq3m2Z4hMh5yTyGaxmrcQlbUAKE71y1Z0gJgOQg7P8OKGhnLCFg6/lnYJTA UgmB2lPm2GjZjyj5JqNuyuWmIWPs+ec/A8baQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=o9cJ+4xtwITCNIQYAE/SQUkshopjaBpJDTCZC+P91uzobATgfHwmhADLwMdF9ctvTd 6b/Kd7XEU9D8M3v5W72jeD+5h1mHNq7WES36zH8CfKTdeuDh5hR3OmhyP90e4w7S8iug XpYFSTRgCWGLv0SUtttPyNW+K+dd9gMhAxwe8= Received: by 10.220.188.133 with SMTP id da5mr8922414vcb.175.1294662405169; Mon, 10 Jan 2011 04:26:45 -0800 (PST) Received: from [10.36.0.42] (pool-108-20-27-240.bstnma.fios.verizon.net [108.20.27.240]) by mx.google.com with ESMTPS id d14sm6278228vcx.23.2011.01.10.04.26.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 04:26:44 -0800 (PST) Message-Id: From: Margaret Wasserman To: Alan DeKok In-Reply-To: <4D2AF65C.6060903@deployingradius.com> 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, 10 Jan 2011 07:26:42 -0500 References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> <001101cb9aa0$367b3480$a3719d80$@yegin@yegin.org> <4D064683.30009@deployingradius.com> <4D07A874.4010702@gridmerge.com> <4D07D090.9020407@deployingradius.com> <070601cba3ad$63852150$2a8f63f0$@yegin@yegin.org> <4D270D1D.8090006@deployingradius.com> <005f01cbb0b2$2bc21cc0$83465640$@yegin@yegin.org> <4D2AE752.2000504@deployingradius.com> <006001cbb0b7$da450050$8ecf00f0$@yegin@yegin.org> <4D2AF65C.6060903@deployingradius.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Mon, 10 Jan 2011 06:28:08 -0800 Cc: secdir@ietf.org, paduffy@cisco.com, Alper Yegin , pana@ietf.org, robert.cragie@gridmerge.com, samitac@ipinfusion.com, 'Ralph Droms' Subject: Re: [secdir] pana-relay security considerations X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 12:24:33 -0000 Hi Alan, On Jan 10, 2011, at 7:06 AM, Alan DeKok wrote: > >> I think we shall stick to relying on PAA-PRE security. > > Then it should be a MUST. I originally thought that we needed some form of PRE-PAA security, and your comments have, IMO, suggested more reasons why this is needed. In my opinion, a security mechanism for PRE-PAA authentication needs to be defined in this spec before we publish it. I think it should be optional to actually _use_ the security mechanism, though since there some situations (such as closed or otherwise secured networks) where this type of security isn't required operationally. The security considerations should make it clear what the risks are, and describe the situations in which it would be safe not to use the PRE-to-PAA security. Alan, would that satisfy your concerns? PANA folks, would that meet your needs? Margaret From weiler+secdir@watson.org Mon Jan 10 08:46:41 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ECA73A680B for ; Mon, 10 Jan 2011 08:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xch7mSgYvg4G for ; Mon, 10 Jan 2011 08:46:40 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id E20BA3A67FA for ; Mon, 10 Jan 2011 08:46:39 -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 p0AGmrih075634 for ; Mon, 10 Jan 2011 11:48:53 -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 p0AGmrDc075631 for ; Mon, 10 Jan 2011 11:48:53 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 10 Jan 2011 11:48:53 -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, 10 Jan 2011 11:48:53 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jan 2011 16:46:41 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Stephen Kent is next in the rotation. For telechat 2011-01-20 Reviewer LC end Draft Dave Cridland T 2010-12-03 draft-ietf-sipcore-sec-flows-07 Barry Leiba TR2010-12-16 draft-saintandre-tls-server-id-check-13 Stefan Santesson T 2010-12-30 draft-ietf-roll-security-framework-03 Larry Zhu T 2011-01-14 draft-ietf-6lowpan-hc-13 Last calls and special requests: Derek Atkins 2011-01-18 draft-groves-sakke-00 Rob Austein 2010-12-15 draft-salowey-secsh-uri-00 Rob Austein 2011-01-06 draft-ietf-6man-prefixlen-p2p-01 Richard Barnes 2011-01-18 draft-ietf-isis-ieee-aq-03 Dave Cridland 2011-01-18 draft-ietf-isis-purge-tlv-05 Alan DeKok 2011-01-18 draft-ietf-isis-reg-purge-00 Donald Eastlake 2011-01-07 draft-ietf-l3vpn-mvpn-infra-addrs-02 Stephen Farrell 2011-01-06 draft-ietf-mmusic-image-attributes-10 Tobias Gondrom - draft-ietf-mptcp-architecture-03 Phillip Hallam-Baker - draft-ietf-mptcp-threat-06 Steve Hanna 2011-01-05 draft-ietf-multimob-pmipv6-base-solution-07 Dan Harkins 2011-01-18 draft-igoe-secsh-suiteb-02 Sam Hartman 2011-01-18 draft-turner-cms-symmetrickeypackage-algs-00 Paul Hoffman 2011-01-18 draft-turner-additional-new-asn-06 Love Hornquist-Astrand 2011-02-01 draft-yevstifeyev-tn3270-uri-12 Jeffrey Hutzelman 2011-01-18 draft-groves-eccsi-00 Scott Kelly - draft-ymbk-aplusp-08 David McGrew - draft-ietf-ecrit-framework-12 Russ Mundy 2011-01-04 draft-cardona-cablelabs-urn-05 Sandy Murphy 2011-01-03 draft-turner-sha0-sha1-seccon-02 Eric Rescorla 2011-01-07 draft-ietf-pce-inter-layer-req-15 Nico Williams 2011-01-14 draft-yevstifeyev-http-headers-not-recognized-11 Larry Zhu 2010-09-30 draft-lundberg-app-tei-xml-06 Glen Zorn 2011-01-18 draft-groves-mikey-sakke-00 From alper.yegin@yegin.org Mon Jan 10 11:58:20 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE81428C117; Mon, 10 Jan 2011 11:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.859 X-Spam-Level: X-Spam-Status: No, score=-100.859 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEgfEN2hOL0t; Mon, 10 Jan 2011 11:58:20 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 13AD828C110; Mon, 10 Jan 2011 11:58:20 -0800 (PST) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M932L-1PSBBO2wt3-00CFvm; Mon, 10 Jan 2011 15:00:31 -0500 From: "Alper Yegin" To: "'Margaret Wasserman'" , "'Alan DeKok'" References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> <001101cb9aa0$367b3480$a3719d80$@yegin@yegin.org> <4D064683.30009@deployingradius.com> <4D07A874.4010702@gridmerge.com> <4D07D090.9020407@deployingradius.com> <070601cba3ad$63852150$2a8f63f0$@yegin@yegin.org> <4D270D1D.8090006@deployingradius.com> <005f01cbb0b2$2bc21cc0$83465640$@yegin@yegin.org> <4D2AE752.2000504@deployingradius.com> <006001cbb0b7$da450050$8ecf00f0$@yegin@yegin.org> <4D2AF65C.6060903@deployingradius.com> In-Reply-To: Date: Mon, 10 Jan 2011 21:59:29 +0200 Message-ID: <010101cbb100$ecead380$c6c07a80$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuwwaTIb/4A+U5fT3GmjFhBVvOXTgAPo5Kw Content-Language: en-us X-Provags-ID: V02:K0:b/VDN2plbSwZLBH8VzR/kZpOazowCauPzaA10qeoQda +esLQNt4mv1KU21R8Z7ZI7kIe90B9c9C7cxg/olGc14dlzPFqe EkwdbNtoMGERukISwAW6Pg1nZlW9AqDZyqZWUJWEsiqF0DkE+L sZdKou1avtdBBajtvfOcBk32ilQlRGsE6FATQWqh5drIHOayui rJ/KD2TV2gGs1RIY4v0Gz7q5hUYZuOyKa6SRfreqIQ= Cc: secdir@ietf.org, paduffy@cisco.com, pana@ietf.org, robert.cragie@gridmerge.com, samitac@ipinfusion.com, 'Ralph Droms' Subject: Re: [secdir] pana-relay security considerations X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:58:20 -0000 > On Jan 10, 2011, at 7:06 AM, Alan DeKok wrote: > > > >> I think we shall stick to relying on PAA-PRE security. > > > > Then it should be a MUST. Security considerations section already says so: Some of the risks stemming from the aforementioned threats are already handled by the EAP and PANA as described. The residual risks >>shall be<< mitigated using additional physical or cryptographic security in the network hosting the PREs and the PAAs. > I originally thought that we needed some form of PRE-PAA security, and > your comments have, IMO, suggested more reasons why this is needed. > > In my opinion, a security mechanism for PRE-PAA authentication needs > to be defined in this spec before we publish it. Continuing the modeling after DHCP, we could define use of IPsec (same way RFC 3315 does). > I think it should be > optional to actually _use_ the security mechanism, though since there > some situations (such as closed or otherwise secured networks) where > this type of security isn't required operationally. Indeed. > The security > considerations should make it clear what the risks are, and describe > the situations in which it would be safe not to use the PRE-to-PAA > security. > > Alan, would that satisfy your concerns? PANA folks, would that meet > your needs? Alper From d3e3e3@gmail.com Mon Jan 10 18:41:40 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF2F28C1BF; Mon, 10 Jan 2011 18:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.33 X-Spam-Level: X-Spam-Status: No, score=-103.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95zDZGUbrn3t; Mon, 10 Jan 2011 18:41:39 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id EA74728C1BE; Mon, 10 Jan 2011 18:41:38 -0800 (PST) Received: by wyf23 with SMTP id 23so21123762wyf.31 for ; Mon, 10 Jan 2011 18:43:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=jgoH31Grr67FW/hG4FjYMNrRChDEYtDuyo64/KSaZbw=; b=ebDbTUqcGQowiWTUtYyNlwfzrwMKNF/avcSmAGBq+BAK7V2pQE10f0+6lL7YxJhWr9 7QtrVz+PgSKnKUT7aI1488azqiAnUyXRtNzy+p1/X3aK0X92m0in4jVSn5jkOxVeHhwn EqgiPNSXoMWK0TuV6+88HKvmjJlpRo6QL9u/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=AFeqeT8m1XucnK+WNIb7MGeRLLu2Kc5zrK/F56YJOUBMBaZv7/r9OY1YO/vV0YC7Yk jVrIZgNeuZORnJC10mcjHLeUGCvt29FYgrrqBNVM/wEzHCG9x8p+HUtNVZ44Q5Pa+lv8 PeRUND+xicTYiCXQ7WItdZSmePRQi12jQBvkg= Received: by 10.227.141.138 with SMTP id m10mr4282142wbu.66.1294713833727; Mon, 10 Jan 2011 18:43:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.61.81 with HTTP; Mon, 10 Jan 2011 18:43:33 -0800 (PST) From: Donald Eastlake Date: Mon, 10 Jan 2011 21:43:33 -0500 Message-ID: To: iesg@ietf.org, secdir@ietf.org, draft-ietf-l3vpn-mvpn-infra-addrs.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [secdir] SecDir Review of draft-ietf-l3vpn-mvpn-infra-addrs-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 02:41:40 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This document appears to concern provider multicast routing using BGP in the context of "Multicast in MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast, where the customer traffic and the provider facilities may independently be IPv4 or IPv6. The type of customer traffic is explicitly indicated and this draft primarily provides for various field and message restrictions or, in other cases, that the provider traffic type (IPv4 or IPv6) will be determined explicitly from the length of the provider addresses, so as to remove ambiguity. It is basically an encoding matter and does not particularly seem to change the sensitivity of the messages involved. It's Security Considerations simply points to draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt which is already in the RFC Editor's queue. Considering the nature of the draft being reviewed, that seems adequate. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From gnakibly@yahoo.com Mon Jan 10 23:02:55 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0162F3A69B7 for ; Mon, 10 Jan 2011 23:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CODEmBJfAZde for ; Mon, 10 Jan 2011 23:02:52 -0800 (PST) Received: from nm25-vm0.bullet.mail.sp2.yahoo.com (nm25-vm0.bullet.mail.sp2.yahoo.com [98.139.91.228]) by core3.amsl.com (Postfix) with SMTP id 42A2E3A6765 for ; Mon, 10 Jan 2011 23:02:52 -0800 (PST) Received: from [98.139.91.70] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jan 2011 07:05:05 -0000 Received: from [98.139.91.4] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jan 2011 07:05:05 -0000 Received: from [127.0.0.1] by omp1004.mail.sp2.yahoo.com with NNFMP; 11 Jan 2011 07:05:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 908838.44534.bm@omp1004.mail.sp2.yahoo.com Received: (qmail 25568 invoked by uid 60001); 11 Jan 2011 07:05:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294729505; bh=3Tts7Tl0Kys5EzXbChwUzd/FBIrJqNXbj4hgodvG8ps=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sgiFN5pTi1hiAiirxQsJsSJNSlDTxLdtjqq4MarmSxdbNmjtOUX3WfU+cv8N5TfkA0e0hxj8EDLzBEo//dEf0f9dSHk469fWFLcmDhE/2hTbJaecE38DWmBKPs50jj8JdlyFkowUw7sFEKEsLZ4LcuH0falywnv5FAqbziHidI0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1c87KImWOTO/mkQqFDRtpx59HKjd50vr/9CJ4+0QtfSBoJ+D0783lcZtHgX6wIJF/JdpBQSHbjfRvQ0Yzma7/XH52plq+ZS3Z49HNinRZnrkStFn2DlrUVWOnUSnQ+rtJsfMzf26swbxJwF4RNh00zmK8KE8kajSlsI9mmk+wKQ=; Message-ID: <774066.24552.qm@web45512.mail.sp1.yahoo.com> X-YMail-OSG: GE1X5b0VM1kBUW0Ho.IGtrm7O4HMmuJbZQqUXWFlODvT4nb LwBKApDnE2pmgJ3n6WlztY2XFKftSHAbc5oxW2RfpxeFQldgJYJcfAfTvLdD Ix9j_Uw0.wPmjCF3Nfjm7WRl0sROQez9nQG8QWWdjre1jH7E3I2Oc_WC0ZO4 smxoQWRscBvpKG_WO3NJgCXbxKVuGch696AlwWyLxMZbwvgangs.0w20KWuY QoDdJdp9Fs95ep0PQzTRjcn40Z.mS45LoO23vsQVt6PeQi8nV97GQ5l1Gmf7 GNHgAsse2EwBehqJbj3o- Received: from [93.172.151.94] by web45512.mail.sp1.yahoo.com via HTTP; Mon, 10 Jan 2011 23:05:05 PST X-Mailer: YahooMailRC/553 YahooMailWebService/0.8.107.285259 References: Date: Mon, 10 Jan 2011 23:05:05 -0800 (PST) From: Gabi Nakibly To: Tom Yu , iesg@ietf.org, secdir@ietf.org, draft-ietf-v6ops-tunnel-loops.all@tools.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [secdir] secdir review of draft-ietf-v6ops-tunnel-loops-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 07:02:55 -0000 Hi Tom,=0AThanks for the valuable input. See our reponse inline.=0A=0AFred = and Gabi=0A=0A=0A=0A----- Original Message ----=0A> From: Tom Yu =0A> To: iesg@ietf.org; secdir@ietf.org; =0A>draft-ietf-v6ops-tunnel-lo= ops.all@tools.ietf.org=0A> Sent: Thu, December 30, 2010 6:00:24 AM=0A> Subj= ect: secdir review of draft-ietf-v6ops-tunnel-loops-01=0A> =0A> This docume= nt describes routing loop vulnerabilities inherent in the=0A> existing desi= gn of IPv6-in-IPv4 tunneling protocols, and suggests=0A> mitigation strateg= ies.=0A> =0A> While the Security Considerations section of this document cl= aims that=0A> the recommended checks do not introduce new security threats,= Section=0A> 3.1 mentions that the additional processing overhead for check= ing=0A> destination and source addresses may be considerable.=A0 It would b= e=0A> useful to have measurements or estimates of how this additional=0A> p= rocessing overhead compares to the effects of the routing loop attack=0A> t= hat it is intended to mitigate.=0A=0ASuch estimates will be added to the Se= curity Considerations section.=0A=0A> =0A> This document makes no mention o= f the Teredo attacks that are=0A> discussed in the USENIX WOOT paper.=A0 Th= e authors may wish to mention=0A> draft-gont-6man-teredo-loops-00 for the s= ake of completeness.=0A> =0A=0AWe will cite this draft.=0A=0A> Editorial:= =0A> =0A> Section 3 lists three categories of mitigation measures but the= =0A> accompanying text states that they fall under two categories.=0A> =0A>= In Section 3.1, in the sentence "However, this approach has some=0A> inher= it limitations", replace "inherit" with "inherent".=0A> =0A> In Section 4, = in the sentence "...other mitigation measures may be=0A> allowed is specifi= c deployment scenarios", replace "may be allowed is"=0A> with "may be feasi= ble in".=0A> =0A=0AAll these will be corrected.=0A=0A=0A=0A From new-work-bounces@ietf.org Tue Jan 11 10:35:11 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF9E28C2C7; Tue, 11 Jan 2011 10:35:11 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6ED7F28C274; Tue, 11 Jan 2011 10:35:11 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110111183511.6ED7F28C274@core3.amsl.com> Date: Tue, 11 Jan 2011 10:35:11 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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, 12 Jan 2011 11:10:19 -0800 Subject: [secdir] [new-work] WG Review: Audio/Video Transport Payloads (payload) 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, 11 Jan 2011 18:35:12 -0000 A new IETF working group has been proposed in the Real-Time Applications and Infrastructure 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, January 18, 2011. Audio/Video Transport Payloads (payload) ------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-12-03 Chairs: TBD Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: TBD Description of Working Group: The PAYLOAD working group is tasked with the specification and maintenance of payload formats for use with the Real-Time Transport Protocol, RTP [RFC3550]. The group will follow the guidelines established in "Guidelines for Writers of RTP Payload Format Specifications" [BCP 36], the "How to Write an RTP Payload Format" (under development) and is responsible for maintaining those guidelines. This working group will develop RTP payload formats for new media codecs, review and revise existing payload formats to advance those which are useful to Draft Standard or Standard, and declare others Historic. Goals and Milestones: Dec 2010 Submit RTP Payload Format for MIDI for Proposed Standard Feb 2011 Submit How to Write an RTP Payload Format for Informational Feb 2011 Submit RTP Payload Format for MPEG-4 Audio/Visual Streams for Proposed Standard Mar 2011 Submit RTP Payload Format for EVBR/G.718 for Proposed Standard Mar 2011 Submit RTP Payload Format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) for Proposed Standard Mar 2011 Submit RTP Payload Format for Bluetooth's SBC audio codec for Proposed Standard Apr 2011 Submit RTP Payload Format for MPEG2-TS preamble for Proposed Standard Apr 2011 Submit RTP Payload Format for DV (IEC 61834) Video for Proposed Standard Apr 2011 Submit RTP Payload Format for the iSAC codec for Proposed Standard Apr 2011 Submit RTP profile for the carriage of SMPTE 336M data for Proposed Standard Jun 2011 Submit RTP Payload Format for MVC Video for Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Jan 11 10:38:18 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCAE528C17D; Tue, 11 Jan 2011 10:38:18 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 84BA728B56A; Tue, 11 Jan 2011 10:38:17 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110111183817.84BA728B56A@core3.amsl.com> Date: Tue, 11 Jan 2011 10:38:17 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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, 12 Jan 2011 11:10:19 -0800 Subject: [secdir] [new-work] WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock) 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, 11 Jan 2011 18:38:18 -0000 A new IETF working group has been proposed in the Real-Time Applications and Infrastructure 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, January 18, 2011. Metric Blocks for use with RTCP's Extended Report Framework (xrblock) ------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-12-03 Chairs: TBD Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: TBD Description of Working Group: RFC3611, "RTP Control Protocol Extended Reports (RTCP XR)" established a framework to allow new information to be conveyed in RTCP, supplementing the original report blocks defined in RFC 3550, "RTP: A Transport Protocol for Real-Time Applications". The XRBLOCK working group is chartered to work within this framework, evaluating proposals for report block definitions containing new metrics. The group will follow the guidelines established in RFC5968, "Guidelines for Extending the RTP Control Protocol (RTCP)" and RTP Monitoring Architecture being developed in the RTPCORE working group. Goals and Milestones: Mar 2011 Submit RTCP XR Report Block for Measurement Identity Mar 2011 Submit RTCP XR Report Block for Burst/Gap Discard metric Reporting Mar 2011 Submit RTCP XR Report Block for Burst/Gap Loss metric Reporting Jun 2011 Submit RTCP XR Report Block for Concealed Seconds metric Reporting Jun 2011 Submit RTCP XR Report Block for Delay metric Reporting Jun 2011 Submit RTCP XR Report Block for Discard metric Reporting Sep 2011 Submit RTCP XR Report Block for Jitter Buffer Metric Reporting Sep 2011 Submit RTCP XR Report Block for Loss Concealment metric Reporting Sep 2011 Submit RTCP XR Report Block for Packet Delay Variation Metric Reporting Dec 2011 Submit RTCP XR Report Block for Run Length Encodings of Discarded Packets Dec 2011 Submit RTCP XR Report Block for QoE Metrics Reporting _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Jan 11 10:42:36 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A466228C2E7; Tue, 11 Jan 2011 10:42:36 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E16D528C287; Tue, 11 Jan 2011 10:42:35 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110111184235.E16D528C287@core3.amsl.com> Date: Tue, 11 Jan 2011 10:42:35 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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, 12 Jan 2011 11:10:19 -0800 Subject: [secdir] [new-work] WG Review: Audio/Video Transport Core Maintenence (avtcore) 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, 11 Jan 2011 18:42:36 -0000 A new IETF working group has been proposed in the Real-Time Applications and Infrastructure 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, January 18, 2011. Audio/Video Transport Core Maintenence (avtcore) ------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-12-03 Chairs: TBD Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: TBD Description of Working Group: The Real-time Transport Protocol, RTP, along with its associated profiles and payload formats provides for real-time transmission of audio and video over unicast and multicast transports. RTP itself has been shepherded to Full Standard. Its associated profiles, extensions, and payload formats are currently at various levels of standards maturity. The AVTCORE working group is chartered to maintain the core RTP/RTCP protocols and the AVP, SAVP, AVPF, and SAVPF profiles. The group will provide architectural guidance for extending the protocols and guidelines for their proper use. While other working groups may be chartered to work on application-specific extensions to the protocols, extensions that are generally applicable will be developed in AVTCORE. The AVTCORE working group will coordinate closely with the Security Area while working on maintenance and enhancements to the SRTP Profile. In addition to the milestones called out below, the AVTCORE working group's initial tasks will include completing any remaining work identified in those drafts from the AVT working group already in IESG Evaluation, with the exception of the Rapid Acquisition of Multicast RTP sessions, which will complete in the AVTEXT working group. Goals and Milestones: Dec 2010 Submit Guideline for Choosing RTCP CNAME as Proposed Standard Dec 2010 Submit use of AES-192 and AES-256 in Secure RTP for Proposed Standard Dec 2010 Submit Port Mapping Between Unicast and Multicast RTP Sessions for Proposed Standard Dec 2010 Submit Real-Time Transport Control Protocol (RTCP) in Overlay Multicast for Proposed Standard Feb 2011 Submit Monitoring Architecture for RTP for Informational Feb 2011 Guidelines for the use of Variable Bit Rate Audio with Secure RTP as informational (or possibly BCP) Apr 2011 Submit in band keying mechanism for SRTP draft for Proposed Standard Apr 2011 Submit Explicit Congestion Notification (ECN) for RTP over UDP for Proposed Standard May 2011 RTCP indication for retransmission suppression as proposed standard Sep 2011 Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP) for Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Jan 11 10:45:35 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72ECD28C300; Tue, 11 Jan 2011 10:45:35 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 0AE7928C2F7; Tue, 11 Jan 2011 10:45:33 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110111184534.0AE7928C2F7@core3.amsl.com> Date: Tue, 11 Jan 2011 10:45:34 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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, 12 Jan 2011 11:10:19 -0800 Subject: [secdir] [new-work] WG Review: Audio/Video Transport Extensions (avtext) 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, 11 Jan 2011 18:45:35 -0000 A new IETF working group has been proposed in the Real-Time Applications and Infrastructure 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, January 18, 2011. Audio/Video Transport Extensions (avtext) ------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-12-03 Chairs: TBD Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: TBD Description of Working Group: The Full-Standard Real-time Transport Protocol, RTP [RFC 3550], along with its associated profiles and payload formats provides for real- time transmission of audio and video over unicast and multicast transports. RTP is widely implemented, and deployed for a wide range of applications, ranging from telephony to television over IP. As new applications have emerged, the need for guidelines for the use of the RTP/RTCP protocols and extensions specific to those applications has been identified. The AVTEXT working group is charted to develop application-specific guidelines for the use of RTP/RTCP protocols with the AVP, SAVP, AVPF, and SAVPF profiles, and extensions to those protocols that are driven by application-specific needs. Proposals for extensions with general applicability to many different RTP/RTCP usages should be taken to the AVTCORE working group. The AVTEXT working group is constrained to use the protocol extension mechanisms defined in the core protocols (such as RTP Header extensions [RFC5285], AVPF Feedback Messages [RFC4585], and SDES Items [RFC3550]). If new ways to extend the core protocols are needed, they will be developed in the AVTCORE working group. In addition to the milestones called out below, the AVTEXT working group's initial tasks will include completing any new work identified during IESG evaluation for the Rapid Acquisition of Multicast RTP Sessions. Goals and Milestones: Dec 2010 Submit Considerations for RAMS Scenarios for Informational Oct 2011 Submit RTP Header extension for mixer to client audio level indication as Proposed Standard Oct 2011 Submit RTP Header extension for client to mixer audio level indication as proposed standard Dec 2011 Submit Support for multiple clock rates in an RTP session for Proposed Standard Dec 2011 Submit SRTP Store-and-Forward Use Cases and Requirements for Informational Dec 2011 Submit Use of the Secure Real-time Transport Protocol (SRTP) in Store-and-Forward Applications for Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From stephen.farrell@cs.tcd.ie Thu Jan 13 03:50:17 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28B0C3A6AAA; Thu, 13 Jan 2011 03:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.256 X-Spam-Level: X-Spam-Status: No, score=-103.256 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0KJAP8RgO-V; Thu, 13 Jan 2011 03:50:16 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id F14F23A6A9B; Thu, 13 Jan 2011 03:50:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 4341C3E4082; Thu, 13 Jan 2011 11:52:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1294919555; bh=7mle47ZpEcFMu6nw+Uy2RER4 IpqNRstjuYoji1U6M7M=; b=iEFgHYBHDd8cK/JmEVO2Jktq2FdYyQa7a3SNS42H eyRn7i0+DYziqnM9iS6R8DjIlESQGSFTO2aTfHTb4bpVY7XCuj3X9A68PNC3Li0Y OPv0KGtKS3/U9Mqk/Lz8ivZm5Q6UdEz1xONOVs5MfpdQW15ciMh4BNS3E05tN9kM 4lWmC+uupG292UADAoE00W1L7XR5OtvMWOw2WCd/EkTtHCehKdqxiVzaWbpGpk1Y mzGr0lZwlXdr/RUaum19Y+Ui0p2PCSlwzdFqKnTmNVsrlSL6swT4mK2kgJonHfEx lXWHIDloL+9zFEs6kmHKGza2DlPf1uyZaZYAqft2A7xUYg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 8Z6lBcUpXhR3; Thu, 13 Jan 2011 11:52:35 +0000 (GMT) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id DD0E53E4075; Thu, 13 Jan 2011 11:52:33 +0000 (GMT) Message-ID: <4D2EE782.3010801@cs.tcd.ie> Date: Thu, 13 Jan 2011 11:52:34 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mmusic-image-attributes.all@tools.ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir Review ofdraft-ietf-mmusic-image-attributes X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 11:50:17 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This draft defines a way to ask a sender to use different image attributes using SDP. The security considerations says that this doesn't change anything, but I don't quite agree. A requestor could (accidentally or on purpose) as for some very large image size or for some kind of transformation that puts a lot of load on a transcoder, and that could be part of some DoS attack. (I've actually seen this bug triggered accidentally in a real system that did more or less this.) I'd suggest adding a paragraph to the security considerations saying that implementations should be wary of this and could include some sanity checking of inputs or could try to detect cases where lots of resources are being used and then handle that somehow. I don't know how that'd be best done, nor whether any of that should use 2119 type language, but I assume the authors can figure that out. Stephen. From kyunghun.jung@samsung.com Thu Jan 13 05:31:55 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7D33A6B88 for ; Thu, 13 Jan 2011 05:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.147 X-Spam-Level: * X-Spam-Status: No, score=1.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhz4Y+qsvUnu for ; Thu, 13 Jan 2011 05:31:54 -0800 (PST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by core3.amsl.com (Postfix) with ESMTP id 2C5F13A6AAB for ; Thu, 13 Jan 2011 05:31:54 -0800 (PST) Received: from epms1.samsung.com (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built Sep 7 2010)) with ESMTP id <0LEY00E3YR03GD50@mailout3.samsung.com> for secdir@ietf.org; Thu, 13 Jan 2011 22:33:39 +0900 (KST) Received: from epv6spt1 ("port 21683"@[203.254.225.172]) by ms1.samsung.com (Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built Sep 7 2010)) with ESMTP id <0LEY00IYJR029Q40@ms1.samsung.com> for secdir@ietf.org; Thu, 13 Jan 2011 22:33:39 +0900 (KST) Message-id: <0LEY00IYRR039Q40@ms1.samsung.com> Date: Thu, 13 Jan 2011 13:33:39 +0000 (GMT) From: =?euc-kr?B?waSw5sjG?= To: Stephen Farrell , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-mmusic-image-attributes.all@tools.ietf.org" MIME-version: 1.0 X-MTR: 20110113131535653@kyunghun.jung Msgkey: 20110113131535653@kyunghun.jung X-EPLocale: ko_KR.euc-kr X-Priority: 3 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML X-EPTrCode: X-EPTrName: X-MLAttribute: X-RootMTR: 20110113131535653@kyunghun.jung X-ParentMTR: MIME-version: 1.0 Content-type: text/html; charset=euc-kr Content-transfer-encoding: base64 X-Generator: Namo ActiveSquare 7 7.0.0.44 X-Mailman-Approved-At: Thu, 13 Jan 2011 07:21:34 -0800 Subject: Re: [secdir] SecDir Review ofdraft-ietf-mmusic-image-attributes X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: kyunghun.jung@samsung.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 13:31:55 -0000 PEhUTUw+PEhFQUQ+PFRJVExFPlNhbXN1bmcgRW50ZXJwcmlzZSBQb3J0YWwgbXlTaW5nbGU8L1RJ VExFPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciIgaHR0cC1lcXVp dj1Db250ZW50LVR5cGU+DQo8U1RZTEUgaWQ9bXlzaW5nbGVfc3R5bGU+UCB7DQoJTUFSR0lOLVRP UDogNXB4OyBGT05ULUZBTUlMWTogsby4ssO8LCBhcmlhbDsgTUFSR0lOLUJPVFRPTTogNXB4OyBG T05ULVNJWkU6IDlwdA0KfQ0KVEQgew0KCU1BUkdJTi1UT1A6IDVweDsgRk9OVC1GQU1JTFk6ILG8 uLLDvCwgYXJpYWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQNCn0NCkxJIHsN CglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiCxvLiyw7wsIGFyaWFsOyBNQVJHSU4tQk9U VE9NOiA1cHg7IEZPTlQtU0laRTogOXB0DQp9DQpCT0RZIHsNCglMSU5FLUhFSUdIVDogMS40OyBN QVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiCxvLiyw7wsIGFyaWFsOyBGT05ULVNJWkU6IDlwdA0K fQ0KPC9TVFlMRT4NCg0KPE1FVEEgbmFtZT1HRU5FUkFUT1IgY29udGVudD1BY3RpdmVTcXVhcmU+ PC9IRUFEPg0KPEJPRFk+DQo8UD5EZWFyIE1yLiBTdGVwaGVuIEZhcnJlbGwgYW5kIElFVEYgZXhw ZXJ0czo8L1A+DQo8UD4mbmJzcDs8L1A+DQo8UD5UaGFuayB5b3UgZm9yIHlvdXIga2luZCBjb21t ZW50cy48L1A+DQo8UD4mbmJzcDs8L1A+DQo8UD5XaGVuIHdlIHN0YXJ0IHRoaXMgd29yayBpbiAy MDA3IChmaW5pc2hlZCBpbiAzR1BQIGFuZCBlYXJseSZuYnNwO2ltcGxlbWVudGF0aW9ucyBzb29u KSw8L1A+DQo8UD5vdXIga2V5IG9iamVjdGl2ZSB3YXMgdG8gbWF4aW1pemUgdGhlIHBlcmNlaXZl ZCZuYnNwO3F1YWxpdHkgb2YgNEcgbW9iaWxlIHZpZGVvIHRlbGVwaG9ueTwvUD4NCjxQPmF0IHRo ZSBsb3cgYnV0IG1vc3QgZXhwZW5zaXZlJm5ic3A7Yml0LXJhdGUsIHBlcmhhcHMgc2Vjb25kIG9u bHkgdG8gc2F0ZWxsaXRlIGluIHRlcm1zIG9mIGNvc3QuPC9QPg0KPFA+Jm5ic3A7PC9QPg0KPFA+ Q29uc2lkZXJpbmcgdGhlIHN0cm9uZyBzZWN1cml0eSZuYnNwO29mIElNUywgb3ZlciB3aGljaCB0 aGUgNEcgaGFuZHNldCZuYnNwO3VzaW5nIHRoaXMgYXR0cmlidXRlIHdpbGwgYmU8L1A+DQo8UD5k ZXBsb3llZCwgd2UgZGlkIG5vdCBwYXkgZW5vdWdoIGF0dGVudGlvbiB0byBhcmVhcyB5b3Uga2lu ZGx5IG1lbnRpb25lZC4gQXBwYXJhbnRseSwgaWYgdGhlPC9QPg0KPFA+aW1hZ2Ugc2l6ZXMgYWNj b21wYW55aW5nICJpbWFnZWF0dHIiIGFyZSBjb3JydXB0ZWQgZHVyaW5nIG5lZ290aWF0aW9uLCBz ZXNzaW9uIHNldHVwJm5ic3A7Y2FuIGJlPC9QPg0KPFA+ZGVsYXllZCBvciBldmVuIGRyb3BwZWQu IFdlIHdpbGwgcmVmbGVjdCB5b3VyIGFkdmljZXMgaW50byB0aGUgZHJhZnQgc29vbi48L1A+DQo8 UD4mbmJzcDs8L1A+DQo8UD5UaGFuayB5b3UgYWdhaW4gYW5kIG1hbnkgY29tbWVudHMgb3IgY29y cmVjdGlvbnMgd2lsbCBiZSBncmVhdGx5IHdlbGNvbWVkLjwvUD4NCjxQPiZuYnNwOzwvUD4NCjxQ Pkt5dW5naHVuIEp1bmc8L1A+DQo8UD5TYW1zdW5nIEVsZWN0cm9uaWNzIENvLiwgTHRkLjwvUD4N CjxQPiZuYnNwOzwvUD4NCjxQPi0tLS0tLS0gPEI+T3JpZ2luYWwgTWVzc2FnZTwvQj4gLS0tLS0t LTwvUD4NCjxQPjxCPlNlbmRlcjwvQj4gOiBTdGVwaGVuIEZhcnJlbGwmbHQ7c3RlcGhlbi5mYXJy ZWxsQGNzLnRjZC5pZSZndDs8L1A+DQo8UD48Qj5EYXRlPC9CPiA6IDIwMTEtMDEtMTMgMjA6NTIg KEdNVCswOTowMCk8L1A+DQo8UD48Qj5UaXRsZTwvQj4gOiBbc2VjZGlyXSBTZWNEaXIgUmV2aWV3 IG9mZHJhZnQtaWV0Zi1tbXVzaWMtaW1hZ2UtYXR0cmlidXRlczwvUD4NCjxQPiZuYnNwOzwvUD5J IGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJl Y3RvcmF0ZSdzPEJSPm9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMg YmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZTxCUj5JRVNHLiZuYnNwOyZuYnNwO0RvY3VtZW50IGVkaXRv cnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdDxCUj5saWtl IGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPEJSPjxCUj5UaGlzIGRyYWZ0IGRlZmluZXMg YSB3YXkgdG8gYXNrIGEgc2VuZGVyIHRvIHVzZSBkaWZmZXJlbnQgaW1hZ2U8QlI+YXR0cmlidXRl cyB1c2luZyBTRFAuPEJSPjxCUj5UaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2F5cyB0aGF0 IHRoaXMgZG9lc24ndCBjaGFuZ2UgYW55dGhpbmcsPEJSPmJ1dCBJIGRvbid0IHF1aXRlIGFncmVl LiBBIHJlcXVlc3RvciBjb3VsZCAoYWNjaWRlbnRhbGx5IG9yIG9uPEJSPnB1cnBvc2UpIGFzIGZv ciBzb21lIHZlcnkgbGFyZ2UgaW1hZ2Ugc2l6ZSBvciBmb3Igc29tZSBraW5kPEJSPm9mIHRyYW5z Zm9ybWF0aW9uIHRoYXQgcHV0cyBhIGxvdCBvZiBsb2FkIG9uIGEgdHJhbnNjb2RlciwgYW5kPEJS PnRoYXQgY291bGQgYmUgcGFydCBvZiBzb21lIERvUyBhdHRhY2suIChJJ3ZlIGFjdHVhbGx5IHNl ZW4gdGhpczxCUj5idWcgdHJpZ2dlcmVkIGFjY2lkZW50YWxseSBpbiBhIHJlYWwgc3lzdGVtIHRo YXQgZGlkIG1vcmUgb3I8QlI+bGVzcyB0aGlzLik8QlI+PEJSPkknZCBzdWdnZXN0IGFkZGluZyBh IHBhcmFncmFwaCB0byB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnM8QlI+c2F5aW5nIHRoYXQg aW1wbGVtZW50YXRpb25zIHNob3VsZCBiZSB3YXJ5IG9mIHRoaXMgYW5kIGNvdWxkPEJSPmluY2x1 ZGUgc29tZSBzYW5pdHkgY2hlY2tpbmcgb2YgaW5wdXRzIG9yIGNvdWxkIHRyeSB0byBkZXRlY3Q8 QlI+Y2FzZXMgd2hlcmUgbG90cyBvZiByZXNvdXJjZXMgYXJlIGJlaW5nIHVzZWQgYW5kIHRoZW4g aGFuZGxlIHRoYXQ8QlI+c29tZWhvdy4gSSBkb24ndCBrbm93IGhvdyB0aGF0J2QgYmUgYmVzdCBk b25lLCBub3Igd2hldGhlciBhbnk8QlI+b2YgdGhhdCBzaG91bGQgdXNlIDIxMTkgdHlwZSBsYW5n dWFnZSwgYnV0IEkgYXNzdW1lIHRoZSBhdXRob3JzPEJSPmNhbiBmaWd1cmUgdGhhdCBvdXQuPEJS PjxCUj5TdGVwaGVuLjwvQk9EWT48L0hUTUw+PGltZyBzcmM9J2h0dHA6Ly9leHQuc2Ftc3VuZy5u ZXQvbWFpbGNoZWNrL1NlZW5UaW1lQ2hlY2tlcj9kbz0zNWM1NGJlZGIxMTI3YzU1MGY4NjE1NjE2 ZjBhMDI1ODdlOGY0NGUwY2U0ZGU0ZDdhYmE4OWVhZWY2MDNjODE4ZjUzN2Q0YmM5ZTMzOWZmYjJh NWE2YjdkNDI2ZDAxZTMxYjIwOTA5YTA0ZWZkNGQyNzQ4Y2ZlMWQ0ZTg0NzQxOWNmODc4ZjlhMjZj ZTE1YTAnIGJvcmRlcj0wIHdpZHRoPTAgaGVpZ2h0PTAgc3R5bGU9J2Rpc3BsYXk6bm9uZSc+ From jpv@cisco.com Thu Jan 13 06:37:08 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3EE428C0F8; Thu, 13 Jan 2011 06:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.394 X-Spam-Level: X-Spam-Status: No, score=-110.394 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JG1Sb3ebGcf; Thu, 13 Jan 2011 06:37:07 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 8015E28C0DB; Thu, 13 Jan 2011 06:37:07 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABedLk2rR7Ht/2dsb2JhbACkR3OkEphignSCWASLEIMo Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 13 Jan 2011 14:39:30 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0DEdPR2018091; Thu, 13 Jan 2011 14:39:29 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 15:39:23 +0100 Received: from dhcp-lyon-144-254-54-119.cisco.com ([144.254.54.119]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 15:39:22 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-76-942261511 From: JP Vasseur In-Reply-To: <123DE172-C230-4A8E-81A8-2B60D9E6AD92@cisco.com> Date: Thu, 13 Jan 2011 15:39:17 +0100 Message-Id: <6C8230FE-0DC4-461A-8549-A7127DDDEB01@cisco.com> References: <123DE172-C230-4A8E-81A8-2B60D9E6AD92@cisco.com> To: Joseph Salowey (jsalowey) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 13 Jan 2011 14:39:22.0960 (UTC) FILETIME=[AB568500:01CBB32F] X-Mailman-Approved-At: Thu, 13 Jan 2011 07:21:34 -0800 Cc: draft-ietf-roll-routing-metrics.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-roll-routing-metrics-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 14:37:08 -0000 --Apple-Mail-76-942261511 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Joseph, Thanks for your review. On Jan 6, 2011, at 11:42 PM, Joseph Salowey (jsalowey) 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 > In general I think the document is clear. I have one security related = issue. The security considerations mention attacks where the metric = information is manipulated to cause problems. I think there may also be = cases where disclosure of some of the metric information may be an = issue. the main area of concern for me is the node energy metric. This = information may be useful to an attacker to determine which devices to = attack with out-of-band or in-band attacks involving energy draining. = I have not had a chance to see if the RPL protects the confidentiality = of these attributes. If this is a concern in a deployment environment = then the usage of these attributes may be limited. I think it is = probably worth mentioning this in the security considerations. >=20 >=20 JP> This is a very good point. How about adding the following:=20 "Some routing metrics may also be used to identify some areas of = weaknesses in the network (a highly unreliable links, a node running low = in terms of energy, ...): such information may be used by a potential = attacker. Thus it is RECOMMENDED to carefully consider which metrics = should be used by RPL and the level of visibility that they provide = about the network state or to use appropriate the security measures as = specified in draft-ietf-roll-rpl to protect that information." > Also energy metric introduce a new vector into the system for an = attacker to modify routing behavior. An attacker can purposely attempt = to modify the stored energy in a node to modify the metrics advertised. =20= >=20 JP> Right but this is also true for other metrics, this is why we made a = recommendation to stop advertising metrics for unstable links, which = should address your point. It is a generally accepted feature of routing = security that it is not possible to protect against subverted routers. = That is, a router that can be made to lie is a significant security risk = and the protection must be physical or in the management system access, = not in the routing protocol. Modifying the stored energy in a router = constitutes a physical attack on the router (i.e. subversion) and would, = of course, modify the router's ability to forward data. Thus, the = routing protocol would be correct to notify the rest of the network of = the revised state of power in the router and this would affect how = packets are routed. > Its not clear to me at this point if this is significant since the = power drain may have effect on metrics and routing beyond what is = advertised and it seems the recommendation to protect against unstable = links would be effective in this case as well. =20 >=20 >=20 Exactly. Thanks a lot. Cheers. JP. > Cheers, >=20 > Joe >=20 --Apple-Mail-76-942261511 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = Joseph,

Thanks for your = review.

On Jan 6, 2011, at 11:42 PM, Joseph = Salowey (jsalowey) 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.

In general I think the document is clear. I have one security = related issue. The security considerations mention attacks where = the metric information is manipulated to cause problems. I think = there may also be cases where disclosure of some of the metric = information may be an issue. the main area of concern for me is = the node energy metric. This information may be useful to an = attacker to determine which devices to attack with out-of-band or = in-band attacks involving energy draining. I have not had a = chance to see if the RPL protects the confidentiality of these = attributes. If this is a concern in a deployment environment then = the usage of these attributes may be limited. I think it is = probably worth mentioning this in the security considerations.

JP> This is a very good point. = How about adding the following:

"Some = routing metrics may also be used to identify some areas of weaknesses in = the network (a highly unreliable links, a node running low in terms of = energy, ...): such information may be used by a potential attacker. Thus = it is RECOMMENDED to carefully consider which metrics should be used by = RPL and the level of visibility that they provide about the network = state or to use appropriate the security measures as specified in = draft-ietf-roll-rpl to protect that information."

Also energy metric introduce a new vector into the system for an = attacker to modify routing behavior. An attacker can purposely = attempt to modify the stored energy in a node to modify the metrics = advertised.

JP> Right = but this is also true for other metrics, this is why we made a = recommendation to stop advertising metrics for unstable links, which = should address your point. It is a generally accepted feature of = routing security that it is not possible to protect against subverted = routers. That is, a router that can be made to lie is a significant = security risk and the protection must be physical or in the management = system access, not in the routing protocol. Modifying the stored energy = in a router constitutes a physical attack on the router (i.e. = subversion) and would, of course, modify the router's ability to forward = data. Thus, the routing protocol would be correct to notify the rest of = the network of the revised state of power in the router and this would = affect how packets are routed.

Its not clear to me at this point = if this is significant since the power drain may have effect on metrics = and routing beyond what is advertised and it seems the recommendation to = protect against unstable links would be effective in this case as = well.
=

Exactly.

T= hanks a = lot.

Cheers.

JP.

Cheers,

Joe

= --Apple-Mail-76-942261511-- From Adrian.Farrel@huawei.com Thu Jan 13 08:06:51 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32CF13A6BA0; Thu, 13 Jan 2011 08:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.567 X-Spam-Level: X-Spam-Status: No, score=-103.567 tagged_above=-999 required=5 tests=[AWL=-0.969, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBhCuuKnhJBD; Thu, 13 Jan 2011 08:06:49 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id CC4953A6BB4; Thu, 13 Jan 2011 08:06:49 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEY00LZNY7CO2@usaga01-in.huawei.com>; Thu, 13 Jan 2011 08:09:12 -0800 (PST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEY00F4YY7885@usaga01-in.huawei.com>; Thu, 13 Jan 2011 08:09:12 -0800 (PST) Date: Thu, 13 Jan 2011 16:09:08 +0000 From: Adrian Farrel In-reply-to: <6C8230FE-0DC4-461A-8549-A7127DDDEB01@cisco.com> To: 'JP Vasseur' , "'Joseph Salowey (jsalowey)'" Message-id: <040401cbb33c$37262ed0$a5728c70$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: multipart/alternative; boundary="Boundary_(ID_vF0svZAZe4m8D2EcK+tEfA)" Content-language: en-gb Thread-index: AQLGyxyKgkV2GhAribjZa9D4bCr9wQFqc1ySkc2OR5A= iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: <123DE172-C230-4A8E-81A8-2B60D9E6AD92@cisco.com> <6C8230FE-0DC4-461A-8549-A7127DDDEB01@cisco.com> Cc: secdir@ietf.org, 'The IESG' , draft-ietf-roll-routing-metrics.all@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-roll-routing-metrics-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 16:06:51 -0000 This is a multipart message in MIME format. --Boundary_(ID_vF0svZAZe4m8D2EcK+tEfA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I added an RFC note capturing this text (translated into English ;-) and put it on the agenda for the IESG on 1/20 (ballot had already been issued). Adrian From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of JP Vasseur Sent: 13 January 2011 14:39 To: Joseph Salowey (jsalowey) Cc: draft-ietf-roll-routing-metrics.all@tools.ietf.org; The IESG; secdir@ietf.org Subject: Re: secdir review of draft-ietf-roll-routing-metrics-14 Dear Joseph, Thanks for your review. On Jan 6, 2011, at 11:42 PM, Joseph Salowey (jsalowey) 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. In general I think the document is clear. I have one security related issue. The security considerations mention attacks where the metric information is manipulated to cause problems. I think there may also be cases where disclosure of some of the metric information may be an issue. the main area of concern for me is the node energy metric. This information may be useful to an attacker to determine which devices to attack with out-of-band or in-band attacks involving energy draining. I have not had a chance to see if the RPL protects the confidentiality of these attributes. If this is a concern in a deployment environment then the usage of these attributes may be limited. I think it is probably worth mentioning this in the security considerations. JP> This is a very good point. How about adding the following: "Some routing metrics may also be used to identify some areas of weaknesses in the network (a highly unreliable links, a node running low in terms of energy, ...): such information may be used by a potential attacker. Thus it is RECOMMENDED to carefully consider which metrics should be used by RPL and the level of visibility that they provide about the network state or to use appropriate the security measures as specified in draft-ietf-roll-rpl to protect that information." Also energy metric introduce a new vector into the system for an attacker to modify routing behavior. An attacker can purposely attempt to modify the stored energy in a node to modify the metrics advertised. JP> Right but this is also true for other metrics, this is why we made a recommendation to stop advertising metrics for unstable links, which should address your point. It is a generally accepted feature of routing security that it is not possible to protect against subverted routers. That is, a router that can be made to lie is a significant security risk and the protection must be physical or in the management system access, not in the routing protocol. Modifying the stored energy in a router constitutes a physical attack on the router (i.e. subversion) and would, of course, modify the router's ability to forward data. Thus, the routing protocol would be correct to notify the rest of the network of the revised state of power in the router and this would affect how packets are routed. Its not clear to me at this point if this is significant since the power drain may have effect on metrics and routing beyond what is advertised and it seems the recommendation to protect against unstable links would be effective in this case as well. Exactly. Thanks a lot. Cheers. JP. Cheers, Joe --Boundary_(ID_vF0svZAZe4m8D2EcK+tEfA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

I added an RFC note capturing this text (translated into English ;-) and put it on the agenda for the IESG on 1/20 (ballot had already been issued).

Adrian

From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of JP Vasseur
Sent: 13 January 2011 14:39
To: Joseph Salowey (jsalowey)
Cc: draft-ietf-roll-routing-metrics.all@tools.ietf.org; The IESG; secdir@ietf.org
Subject: Re: secdir review of draft-ietf-roll-routing-metrics-14

Dear Joseph,

< p>

Thanks for your review.

On Jan 6, 2011, at 11:42 PM, Joseph Salowey (jsalowey) 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 ust like any other last call comments.

In general I think the document is clear. I have one security related issue. The security considerations mention attacks where the metric information is manipulated to cause problems. I think there may also be cases where disclosure of some of the metric information may be an issue. the main area of concern for me is the node energy metric. This information may be useful to an attacker to determine which devices to attack with out-of-band or in-band attacks involving energy draining. I have not had a chance to see if the RPL protects the confidentiality of these attributes. If this is a concern in a deployment environment then the usage of these attributes may be limited. I think it is probably worth mentioning this in the security considerations.

JP> This is a ve ry good he following:

"Some routing metrics may also be used to identify some areas of weaknesses in the network (a highly unreliable links, a node running low in terms of energy, ...): such information may be used by a potential attacker. Thus it is RECOMMENDED to carefully consider which metrics should be used by RPL and the level of visibility that they provide about the network state or to use appropriate the security measures as specified in draft-ietf-roll-rpl to protect that information."

Also energy metric introduce a new vector into the system for an at tacker t . An attacker can purposely attempt to modify the stored energy in a node to modify the metrics advertised.

JP> Right but this is also true for other metrics, this is why we made a recommendation to stop advertising metrics for unstable links, which should address your point. It is a generally accepted feature of routing security that it is not possible to protect against subverted routers. That is, a router that can be made to lie is a significant security risk and the protection must be physical or in the management system access, not in the routing protocol. Modifying the stored energy in a router constitutes a physical attack on the router (i.e. subversion) and would, of course, modify the router's ability to forward data. Thus, the routing protocol would be correct to notify the rest of the network of the revised state of powe r in the outer and this would a fect how packets are routed.

Its not clear to me at this point if this is significant since the power drain may have effect on metrics and routing beyond what is advertised and it seems the recommendation to protect against unstable links would be effective in this case as well.

Exactly.

Thanks a lot.

Cheers.

JP.

Cheers,

Joe

--Boundary_(ID_vF0svZAZe4m8D2EcK+tEfA)-- From jsalowey@cisco.com Thu Jan 13 09:28:34 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 269CC28C10E; Thu, 13 Jan 2011 09:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOpklL9G5yu3; Thu, 13 Jan 2011 09:28:33 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 44C2228C0F7; Thu, 13 Jan 2011 09:28:33 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 13 Jan 2011 17:30:56 +0000 Received: from [10.33.249.181] ([10.33.249.181]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p0DHUtOt016119; Thu, 13 Jan 2011 17:30:56 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <6C8230FE-0DC4-461A-8549-A7127DDDEB01@cisco.com> Date: Thu, 13 Jan 2011 09:31:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <123DE172-C230-4A8E-81A8-2B60D9E6AD92@cisco.com> <6C8230FE-0DC4-461A-8549-A7127DDDEB01@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1082) Cc: draft-ietf-roll-routing-metrics.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-roll-routing-metrics-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 17:28:34 -0000 This resolution looks good to me. Thanks, Joe On Jan 13, 2011, at 6:39 AM, JP Vasseur wrote: > Dear Joseph, >=20 > Thanks for your review. >=20 > On Jan 6, 2011, at 11:42 PM, Joseph Salowey (jsalowey) wrote: >=20 >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >>=20 >> In general I think the document is clear. I have one security = related issue. The security considerations mention attacks where the = metric information is manipulated to cause problems. I think there may = also be cases where disclosure of some of the metric information may be = an issue. the main area of concern for me is the node energy metric. = This information may be useful to an attacker to determine which devices = to attack with out-of-band or in-band attacks involving energy draining. = I have not had a chance to see if the RPL protects the confidentiality = of these attributes. If this is a concern in a deployment environment = then the usage of these attributes may be limited. I think it is = probably worth mentioning this in the security considerations. >>=20 >>=20 > JP> This is a very good point. How about adding the following:=20 >=20 > "Some routing metrics may also be used to identify some areas of = weaknesses in the network (a highly unreliable links, a node running low = in terms of energy, ...): such information may be used by a potential = attacker. Thus it is RECOMMENDED to carefully consider which metrics = should be used by RPL and the level of visibility that they provide = about the network state or to use appropriate the security measures as = specified in draft-ietf-roll-rpl to protect that information." >> Also energy metric introduce a new vector into the system for an = attacker to modify routing behavior. An attacker can purposely attempt = to modify the stored energy in a node to modify the metrics advertised. =20= >>=20 > JP> Right but this is also true for other metrics, this is why we made = a recommendation to stop advertising metrics for unstable links, which = should address your point. It is a generally accepted feature of routing = security that it is not possible to protect against subverted routers. = That is, a router that can be made to lie is a significant security risk = and the protection must be physical or in the management system access, = not in the routing protocol. Modifying the stored energy in a router = constitutes a physical attack on the router (i.e. subversion) and would, = of course, modify the router's ability to forward data. Thus, the = routing protocol would be correct to notify the rest of the network of = the revised state of power in the router and this would affect how = packets are routed. >> Its not clear to me at this point if this is significant since the = power drain may have effect on metrics and routing beyond what is = advertised and it seems the recommendation to protect against unstable = links would be effective in this case as well. =20 >>=20 >>=20 > Exactly. >=20 > Thanks a lot. >=20 > Cheers. >=20 > JP. >> Cheers, >>=20 >> Joe >>=20 >=20 From dharkins@lounge.org Thu Jan 13 14:48:31 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A783A6C0D; Thu, 13 Jan 2011 14:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.335 X-Spam-Level: X-Spam-Status: No, score=-5.335 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tedud4D1Nu2t; Thu, 13 Jan 2011 14:48:31 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id F07E03A6BED; Thu, 13 Jan 2011 14:48:30 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 8DCC21022404C; Thu, 13 Jan 2011 14:50:54 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 13 Jan 2011 14:50:54 -0800 (PST) Message-ID: Date: Thu, 13 Jan 2011 14:50:54 -0800 (PST) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-igoe-secsh-suiteb.all@tools.ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [secdir] secdir review of draft-igoe-secsh-suiteb-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 22:48:31 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft documents how a Suite B-compliant SSH client can be built using various other documents that describe how to do ECC-DH, ECDSA, and AES-GCM in SSH. It establishes 2 minimum levels of security, one at 128-bits and another at 192-bits, and specifies how to use the ECC-DH, ECDSA, and AES-GCM components to achieve those two levels. I found no issues with the draft itself and my only complaint is that the Security Considerations seem a little insufficient for the task of describing how to put Suite B in SSH. They are, in their entirety: The security considerations of [SSH-Arch] apply. where [SSH-ARCH] is RFC 4251. The Security Considerations in RFC 4251 are very nice and it is proper to refer to them but, at the very least, it would be nice to provide some text around the following questions: 1. how much entropy is each side required to put into the ECC-DH exchange to achieve the appropriate minimum level of security? 2. in the introduction the draft mentions that following the requirements in the draft does not imply that an implementation is suitable for protection of classified data. What other guidance can the author recommend to leap that bar? Are there any other documents that specify the other requirements an implementation would have to comply with? regards, Dan. From paul.hoffman@vpnc.org Mon Jan 17 09:29:16 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C94B428C17B for ; Mon, 17 Jan 2011 09:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.416 X-Spam-Level: X-Spam-Status: No, score=-100.416 tagged_above=-999 required=5 tests=[AWL=-0.970, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp7y9l1qVGSB for ; Mon, 17 Jan 2011 09:29:16 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 311E928C163 for ; Mon, 17 Jan 2011 09:29:16 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0HHVn3I088443 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 17 Jan 2011 10:31:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D347D05.7050604@vpnc.org> Date: Mon, 17 Jan 2011 09:31:49 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Secdir review of draft-turner-additional-new-asn X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 17:29:16 -0000 Greetings again. This is a stub security review, given that one of the co-authors is a Security AD. This document is a pile of ASN.1 that updates earlier ASN.1 modules in various security documents. The Security Considerations section says, in total: This document itself does not have any security considerations. The ASN.1 modules keep the same bits-on-the-wire as the modules that they replace. I agree with that assessment. --Paul Hoffman From jpv@cisco.com Thu Jan 13 09:31:20 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263C428C12E; Thu, 13 Jan 2011 09:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.4 X-Spam-Level: X-Spam-Status: No, score=-110.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBz53mDUvPcN; Thu, 13 Jan 2011 09:31:19 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 39B2B28C0F7; Thu, 13 Jan 2011 09:31:19 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFzGLk2rR7Ht/2dsb2JhbACkSHOkQJhMgnSCWASLEIMo Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 13 Jan 2011 17:33:42 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0DHXftX024707; Thu, 13 Jan 2011 17:33:41 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 18:33:39 +0100 Received: from dhcp-lyon-144-254-54-119.cisco.com ([144.254.54.119]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 18:33:39 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: Date: Thu, 13 Jan 2011 18:33:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <123DE172-C230-4A8E-81A8-2B60D9E6AD92@cisco.com> <6C8230FE-0DC4-461A-8549-A7127DDDEB01@cisco.com> To: Joe Salowey X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 13 Jan 2011 17:33:39.0826 (UTC) FILETIME=[041DA520:01CBB348] X-Mailman-Approved-At: Mon, 17 Jan 2011 13:05:04 -0800 Cc: draft-ietf-roll-routing-metrics.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-roll-routing-metrics-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 17:31:20 -0000 Thanks Joe. On Jan 13, 2011, at 6:31 PM, Joe Salowey wrote: > This resolution looks good to me. >=20 > Thanks, >=20 > Joe >=20 > On Jan 13, 2011, at 6:39 AM, JP Vasseur wrote: >=20 >> Dear Joseph, >>=20 >> Thanks for your review. >>=20 >> On Jan 6, 2011, at 11:42 PM, Joseph Salowey (jsalowey) wrote: >>=20 >>> I have reviewed this document as part of the security directorate's >>> ongoing effort to review all IETF documents being processed by the >>> IESG. These comments were written primarily for the benefit of the >>> security area directors. Document editors and WG chairs should = treat >>> these comments just like any other last call comments. >>>=20 >>> In general I think the document is clear. I have one security = related issue. The security considerations mention attacks where the = metric information is manipulated to cause problems. I think there may = also be cases where disclosure of some of the metric information may be = an issue. the main area of concern for me is the node energy metric. = This information may be useful to an attacker to determine which devices = to attack with out-of-band or in-band attacks involving energy draining. = I have not had a chance to see if the RPL protects the confidentiality = of these attributes. If this is a concern in a deployment environment = then the usage of these attributes may be limited. I think it is = probably worth mentioning this in the security considerations. >>>=20 >>>=20 >> JP> This is a very good point. How about adding the following:=20 >>=20 >> "Some routing metrics may also be used to identify some areas of = weaknesses in the network (a highly unreliable links, a node running low = in terms of energy, ...): such information may be used by a potential = attacker. Thus it is RECOMMENDED to carefully consider which metrics = should be used by RPL and the level of visibility that they provide = about the network state or to use appropriate the security measures as = specified in draft-ietf-roll-rpl to protect that information." >>> Also energy metric introduce a new vector into the system for an = attacker to modify routing behavior. An attacker can purposely attempt = to modify the stored energy in a node to modify the metrics advertised. =20= >>>=20 >> JP> Right but this is also true for other metrics, this is why we = made a recommendation to stop advertising metrics for unstable links, = which should address your point. It is a generally accepted feature of = routing security that it is not possible to protect against subverted = routers. That is, a router that can be made to lie is a significant = security risk and the protection must be physical or in the management = system access, not in the routing protocol. Modifying the stored energy = in a router constitutes a physical attack on the router (i.e. = subversion) and would, of course, modify the router's ability to forward = data. Thus, the routing protocol would be correct to notify the rest of = the network of the revised state of power in the router and this would = affect how packets are routed. >>> Its not clear to me at this point if this is significant since the = power drain may have effect on metrics and routing beyond what is = advertised and it seems the recommendation to protect against unstable = links would be effective in this case as well. =20 >>>=20 >>>=20 >> Exactly. >>=20 >> Thanks a lot. >>=20 >> Cheers. >>=20 >> JP. >>> Cheers, >>>=20 >>> Joe >>>=20 >>=20 >=20 From weiler+secdir@watson.org Tue Jan 18 14:00:52 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B9853A6F00 for ; Tue, 18 Jan 2011 14:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVPsR8ULtfUh for ; Tue, 18 Jan 2011 14:00:51 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id B3B5E3A6DCE for ; Tue, 18 Jan 2011 14:00:50 -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 p0IM3Rl7077437 for ; Tue, 18 Jan 2011 17:03:27 -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 p0IM3Rwf077434 for ; Tue, 18 Jan 2011 17:03:27 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 18 Jan 2011 17:03:27 -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]); Tue, 18 Jan 2011 17:03:28 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 22:00:52 -0000 There are LOTS of new assignments, and, due to some advance telechat scheduling, there are five lists below. Please look carefully. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Juergen Schoenwaelder is next in the rotation. For telechat 2011-01-20 Reviewer LC end Draft Dave Cridland T 2010-12-03 draft-ietf-sipcore-sec-flows-08 Tobias Gondrom T - draft-ietf-mptcp-architecture-04 Phillip Hallam-Baker T - draft-ietf-mptcp-threat-07 Steve Hanna T 2011-01-05 draft-ietf-multimob-pmipv6-base-solution-07 Barry Leiba TR2010-12-16 draft-saintandre-tls-server-id-check-14 Stefan Santesson T 2010-12-30 draft-ietf-roll-security-framework-04 Larry Zhu T 2011-01-14 draft-ietf-6lowpan-hc-13 For telechat 2011-02-03 Hilarie Orman T 2011-01-26 draft-morton-ippm-rfc4148-obsolete-03 For telechat 2011-02-17 Scott Kelly T 2011-02-07 draft-ymbk-aplusp-08 Stephen Kent T 2011-02-10 draft-arkko-dual-stack-extra-lite-03 Tero Kivinen T 2011-02-14 draft-eastlake-sha2b-06 Chris Lonvick T 2011-02-14 draft-cheshire-dnsext-special-names-01 Sandy Murphy T 2011-02-01 draft-ietf-tsvwg-iana-ports-09 Radia Perlman T 2011-02-08 draft-mraihi-mutual-oath-hotp-variants-12 Eric Rescorla T 2011-02-08 draft-mraihi-totp-timebased-07 For telechat 2011-03-03 Julien Laganier T 2011-02-11 draft-holsten-about-uri-scheme-06 Magnus Nystrom T - draft-meadors-multiple-attachments-ediint-10 Last calls and special requests: Derek Atkins 2011-01-18 draft-groves-sakke-00 Rob Austein 2010-12-15 draft-salowey-secsh-uri-00 Rob Austein 2011-01-06 draft-ietf-6man-prefixlen-p2p-01 Richard Barnes 2011-01-18 draft-ietf-isis-ieee-aq-03 Dave Cridland 2011-01-18 draft-ietf-isis-purge-tlv-05 Alan DeKok 2011-01-18 draft-ietf-isis-reg-purge-00 Sam Hartman 2011-01-18 draft-turner-cms-symmetrickeypackage-algs-00 Love Hornquist-Astrand 2011-02-01 draft-yevstifeyev-tn3270-uri-12 Jeffrey Hutzelman 2011-01-18 draft-groves-eccsi-00 Barry Leiba 2011-01-31 draft-ietf-ccamp-mpls-tp-cp-framework-05 David McGrew - draft-ietf-ecrit-framework-12 David McGrew 2011-02-01 draft-ietf-intarea-shared-addressing-issues-02 Catherine Meadows 2011-01-25 draft-ietf-pim-registry-03 Kathleen Moriarty 2011-01-27 draft-ietf-pmol-metrics-framework-07 Russ Mundy 2011-01-04 draft-cardona-cablelabs-urn-05 Russ Mundy 2011-01-25 draft-ietf-speermint-architecture-17 Sandy Murphy 2011-01-03 draft-turner-sha0-sha1-seccon-02 Eric Rescorla 2011-01-07 draft-ietf-pce-inter-layer-req-15 Vincent Roca 2011-02-07 draft-reed-urn-dgiwg-02 Joe Salowey 2011-02-08 draft-turner-akf-algs-update-02 Stefan Santesson 2011-02-08 draft-turner-ekpct-algs-update-02 Nico Williams 2011-01-14 draft-yevstifeyev-http-headers-not-recognized-11 Larry Zhu 2010-09-30 draft-lundberg-app-tei-xml-06 Glen Zorn 2011-01-18 draft-groves-mikey-sakke-00 From catherine.meadows@nrl.navy.mil Tue Jan 18 14:34:54 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B677A28C0E0; Tue, 18 Jan 2011 14:34:54 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiaM2ZoFb0w3; Tue, 18 Jan 2011 14:34:53 -0800 (PST) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id B1AC03A7068; Tue, 18 Jan 2011 14:34:53 -0800 (PST) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id p0IMbT06013189; Tue, 18 Jan 2011 17:37:29 -0500 (EST) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id p0IMbRC6027966; Tue, 18 Jan 2011 17:37:27 -0500 (EST) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011011817372617948 ; Tue, 18 Jan 2011 17:37:26 -0500 From: Catherine Meadows Content-Type: multipart/alternative; boundary=Apple-Mail-10--744066565 Date: Tue, 18 Jan 2011 17:45:13 -0500 Message-Id: To: iesg@ietf.org, secdir@ietf.org, draft-ietf-pim-registry.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [secdir] secdir review of draft-ietf-pim-registry-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 22:34:54 -0000 --Apple-Mail-10--744066565 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This short draft provides instructions for an IANA registry for = Protocol Independent Multicast (PIM) message types. There is currently = no such registry, and there are already several RFCs specifying PIM message types that should be = included. The document gives the initial content of the registry based on these RFCs, as well as a new type which is reserved = for the extension of type space. The authors not that other than the possible security benefits of having = one place where the various PIM message types can be found, there are no security considerations. I agree with them, and = so don't have anything further to add. =20 Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail-10--744066565 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = have reviewed this document as part of the security = directorate's
ongoing effort to review all IETF documents being = processed by the
IESG. Document editors and WG chairs should = treat these comments just
like any other last call = comments.

This short draft provides instructions for = an IANA registry for Protocol Independent Multicast (PIM) message = types. There is currently no such registry, and there

are = already several RFCs specifying PIM message types that should be = included. The document gives the initial content of = the

registry based on these RFCs, as well as a new type which = is reserved for the extension of type = space.

The authors not that other than the = possible security benefits of having one place where the various PIM = message types can

be found, there are no security = considerations. I agree with them, and so don't have anything = further to = add.

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

= --Apple-Mail-10--744066565-- From rbarnes@bbn.com Tue Jan 18 15:25:17 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4129028C145; Tue, 18 Jan 2011 15:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.72 X-Spam-Level: X-Spam-Status: No, score=-102.72 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYhzXR4bvrU3; Tue, 18 Jan 2011 15:25:16 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6D91828C13C; Tue, 18 Jan 2011 15:25:16 -0800 (PST) Received: from [192.1.255.181] (port=49662 helo=col-raltmann-l1.nira.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PfKxu-000CMu-NJ; Tue, 18 Jan 2011 18:27:54 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: "Richard L. Barnes" In-Reply-To: <188D3671-05E9-40A2-9498-24BAE91B269E@bbn.com> Date: Tue, 18 Jan 2011 18:27:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4153935A-E8EE-4775-BEAE-3E695CDB0C5C@bbn.com> References: <188D3671-05E9-40A2-9498-24BAE91B269E@bbn.com> To: secdir@ietf.org, The IESG X-Mailer: Apple Mail (2.1082) Subject: [secdir] secdir review of draft-ietf-isis-ieee-aq-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 23:25:17 -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 a set of additional sub-TLVs for IS-IS that enable = IS-IS nodes to communicate information related to the IEEE 802.1aq = Shortest Path Bridging system.=20 The Security Considerations section of the document claims that these = extensions do not create any additional security risks. This may be the case, but I found it difficult to evaluate this claim = given a basic knowledge of IS-IS and none of 802.1aq. My high-level = impression is that the negotiations conducted through the mechanism = defined in this document have the ability to affect layer-2 routing in = new ways, with the implication that malicious actors in the protocol = have new ways to influence traffic patterns or deny service to users. =20= It would be helpful if the Security Considerations could explain why = such manipulations are not possible using these extensions (which would = seem to defeat the purpose of the extensions), or if they are, what = assumptions need to be true in order for the protocol to operate = properly. Do all internal network elements need to behave as specified? = Only the SPB instances? --Richard= From jhutz@cmu.edu Wed Jan 19 08:56:22 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD42428B56A; Wed, 19 Jan 2011 08:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.529 X-Spam-Level: X-Spam-Status: No, score=-106.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6vr70qb1RXf; Wed, 19 Jan 2011 08:56:19 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 310CD3A7178; Wed, 19 Jan 2011 08:56:19 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p0JGwvEV005422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jan 2011 11:58:57 -0500 (EST) Date: Wed, 19 Jan 2011 11:58:57 -0500 From: Jeffrey Hutzelman To: ietf@ietf.org, secdir@ietf.org, draft-groves-eccsi.all@tools.ietf.org Message-ID: <1AF6DD3921E5919222492B24@minbar.fac.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Subject: [secdir] secdir review of draft-groves-eccsi-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 16:56:22 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines an identity-based encryption algorithm, using elliptic-curve crypto, based in part on the design of ECDSA. In the system described, each participant has a well-known identifier and a public/private key pair generated by a central keying authority, which itself has a well-known public key. Each participant's public key is a function of that participant's identifer, the keying authority's well-known public key, and a long-term "validation token" which is initially provided the keying authority, and then transmitted by that participant along with each of its signatures. This system shares the usual security considerations of any public key cryptosystem, of ECC in general, and of ECDSA in particular; the security considerations section seems to do a reasonable job of calling these out. Recommendations are made for selecting an appropriate group size based on the desired symmetric-equivalent strength, but no information is given as to the derivation of this advice. I suggest a reference to RFC3766, or perhaps some more recent document which pays particular attention to ECC algorithms. Naturally, the security of the system depends on secure delivery of the agreed-upon group parameters, the keying authority's public key, and the generated keying material to each participant. This document calls out the need for suitable protection, but considers protocols or mechanisms for delivering this data to be out of scope. No explicit mechanism is provided for revocation or expiration of keys. However, identifiers are free-form, and could easily be extended to include timestamps, as discussed in the security considerations section. This is one of the most serious concerns I have with any identity-based crypto scheme, and I'm glad to see it called out and addressed. This document is unusual for the IETF, in that it defines a new cryptographic algorithm, which we normally don't do. While there is no particular reason not to publish it here, I would be wary of using this algorithm in any IETF protocol until it has seen extensive review by the cryptographic community. It looks to me like it should work, but I am not a cryptographer and may well have missed an obvious flaw. From barryleiba@gmail.com Wed Jan 19 10:08:14 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1749328C127; Wed, 19 Jan 2011 10:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.771 X-Spam-Level: X-Spam-Status: No, score=-102.771 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zxi4AZDpu4il; Wed, 19 Jan 2011 10:08:13 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 27BFE28C0EB; Wed, 19 Jan 2011 10:08:13 -0800 (PST) Received: by iyi42 with SMTP id 42so1141708iyi.31 for ; Wed, 19 Jan 2011 10:10:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=hZQRXC0fd+4Mxw8QvHTzmhczGObptFtpM54rm+J62Bc=; b=LDrW/RNfv5NwnbP8OsgOAJUImjkS+q2jsqfS5BJS30zs7HEC1RwZslKUmCrCjv1Evq cmYCQcEZqe/4nuvREWw9Gi4v0+GKx/h30K2E+elV9+J6/umLd2lKQ7O0l6SQI1W+Znp8 P+FcvcGRVWsLHsPLhmp7NvzGNq3rDKioZekJI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=dXrCdzlbFmT8uO8bPt/I9gBX6cwBjVnNFwHmlTc45IFqLRdZPATZNy39nhrTJA1lOo hm/QtXvL7bbq6TTozcgDR+vw8PC3wfMPGxt/jcJGJe/0Szpvgq2LfRmQ+oelPbt4+hR6 dus8AAUD6e6EfVc3lfs1s2ApSOEBXcAxlrkLY= MIME-Version: 1.0 Received: by 10.231.39.74 with SMTP id f10mr1240107ibe.84.1295460653722; Wed, 19 Jan 2011 10:10:53 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.231.208.12 with HTTP; Wed, 19 Jan 2011 10:10:53 -0800 (PST) Date: Wed, 19 Jan 2011 13:10:53 -0500 X-Google-Sender-Auth: RfYyMQpTxaugMET_xH4-X4wXaQg Message-ID: From: Barry Leiba To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, IESG Subject: [secdir] secdir review of draft-saintandre-tls-server-id-check-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 18:08:14 -0000 This is a re-review of the latest version, for tomorrow's IESG telechat. I've been following the discussion of the document since my last review, and am satisfied with where the document is now. This version isn't perfect -- and I still find it a difficult read -- but it pretty much says the right things and steers people in the right direction. I have some concern about expecting implementors to read it, understand it, and understand all the implications. That said, I think it's ready to publish, and we should go ahead with it. I see that it still needs five more ADs to take positions on it. I urge those ADs who have not done so to register "no objection" positions. Barry From tobias.gondrom@gondrom.org Thu Jan 20 03:46:03 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C4B83A70FA for ; Thu, 20 Jan 2011 03:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.158 X-Spam-Level: X-Spam-Status: No, score=-95.158 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWrUrCX7YAzM for ; Thu, 20 Jan 2011 03:46:03 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 7A0433A6F22 for ; Thu, 20 Jan 2011 03:46:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=nyx0bnYPEkacZaLVSiePj0+NKRP7JpGEQsePE5xkVKcDdxT+u/yUbYP+dkC9MsssVdpGmZbWW6yfNQJ30xM3ofQRkjGOy712y8MgOjcQqIU5gP6Fqa9pue99wcTt8Edp; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 32005 invoked from network); 20 Jan 2011 12:47:48 +0100 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 20 Jan 2011 12:47:48 +0100 Message-ID: <4D382103.6080601@gondrom.org> Date: Thu, 20 Jan 2011 11:48:19 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101206 SUSE/3.1.7 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mptcp-architecture.all@tools.ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-ietf-mptcp-architecture-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 11:46:03 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. In general the MPTCP idea and approach look good. There is a large number of security implications and potential problems with MPTCP. The draft's security consideration section basically just refers to two other drafts (draft-ietf-mptcp-threat-06 and draft-ietf-mptcp-multiaddressed-02) to address and solve them. As these elements are pretty central, I am not convinced that these references to "work in progress" drafts are sufficient and only "informative". Draft draft-ietf-mptcp-threat-06 describes some of the security concerns in good detail. I would recommend that the progress of the draft-ietf-mptcp-architecture draft should be halted/delayed until the referenced drafts (or at least some of them) are released. There are a number of issues I would like to raise (some of them might have been answered in one of the several referenced documents or documents referenced by referenced document): - section 5.8: Considering the wide range of threats and potential problems, section "5.8. Security" 3rd paragraph should change "A multi-addressed Multipath TCP SHOULD be able to" to "A multi-addressed Multipath TCP MUST be able to". These are really mandatory requirements to make sure MPTCP does not break and is equal to TCP. - does MPTCP reduce quality of service for other TCP users? section 2.2.3 states: "The use of multiple paths MUST NOT unduly harm users using single-path TCP at shared bottlenecks, beyond the impact that would occur from another single-path TCP flow." I fully agree with this concern. However you do not indicate how this shall be achieved. Considering the TCP-transparancy paradigm in MPTCP this could conflict with "fair shared resources" at bottlenecks? Maybe you can elaborate on how you want to achieve that. I am not sure I can fully see or understand that from draft-ietf-mptcp-congestion-01 (which btw. you maybe should reference in section 2.2.3)? - section 4, paragraph "Congestion Control": this is referencing to draft-ietf-mptcp-congestion-01, which in turn claims to have no security considerations and references to draft-ford-mptcp-multiaddressed-01 (which is experimental and a bit vague with the security considerations and still work in progress) and a non-existent [REF] to deal with this problem. This is not satisfying. - does it lead to traffic shaping (meaning that the network provider will give individual users different qualities of service for TCP). E.g. To make MPTCP equal to one TCP, do you have to reduce QoS for some of its TCP pieces? Or do you identify MPTCP at bottlenecks and allow only for specific users MPTCP? - Packet Scheduling: -- section 4, paragraph "Packet Scheduling" and section 5.3 "Buffer" thinking about scheduling packets on MPTCP layer means holding TCP packets back while waiting for others. Does that introduce a new dimension of memory resource requirements on the receiving machine which could lead to "flooding" attacks with MPTCP. (E.g. sending a MPTCP where one TCP packet is missing by intent and making the receiving endpoint keep all packets keep in memory waiting for the missing subflow packet)? (also refers to section 5.2. Reliability and Retransmissions) - what should happen when two subflow packets (with the same connection level sequence number) arrive via two different TCP paths? Within the time until all connection packets have been re-arranged (e.g. while waiting). Does that mean you can disrupt MPTCP by listening in on one subflow on one path and sending fake messages that will overlap (in connection sequence number) with packets from other paths? - agree with the assessment of section 5.1 on double sequencing ("a connection level sequence number, and another sequence number for each subflow"). However: - could this also make Denial of Service scenarios easier? (or meaning makes it more difficult for middleboxes to determine whether a TCP DoS attack is ongoing or a normal MPTCP (MPTCP's several TCP subflows from one source may look like "flooding" from one source)? - section "5.6. Connection Identification": comment: The Connection id MUST be protected against spoofing, because for MPTCP aware clients this could be used to divert traffic from a legitimate client to a non-legitimate client by spoofing to operate under the same connection id? Normally a server will reply back to the sender's IP address (the same TCP subflow). With MPTCP an attacker might inject a second "connection" into the flow and divert answers from the server to new IP (using the second MPTCP subflow path)? Kind regards, Tobias From kivinen@iki.fi Fri Jan 21 06:07:56 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9D83A699D; Fri, 21 Jan 2011 06:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNGVehkTVETb; Fri, 21 Jan 2011 06:07:55 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2BDC23A6998; Fri, 21 Jan 2011 06:07:54 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p0LEAbF1002374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 16:10:37 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p0LEAaFv000109; Fri, 21 Jan 2011 16:10:36 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19769.37852.869585.298102@fireball.kivinen.iki.fi> Date: Fri, 21 Jan 2011 16:10:36 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 17 min X-Total-Time: 23 min Cc: draft-eastlake-sha2b.all@tools.ietf.org Subject: [secdir] Review of draft-eastlake-sha2b-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 14:07:56 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document contains c-source code for the SHA1, SHA224, SHA256, SHA384, and SHA512 for just hash functions, hmac functions and HKDF functions. It also contains description of SHA224, SHA256, SHA384, and SHA512 algorithms. I did review the whole document including the code review on the actual library functions. I did skip most of the test driver code while doing code review. I also tested that the code include compiles, and produced correct results in my system. I did this by comparing the results from the functions in the draft and our own crypto library implementation. As our library does not support inputs that are not multiple of 8 bits, I did not verify the XXXFinalBits implementations against external implementation. Security consideration section say: ---------------------------------------------------------------------- This document is intended to provide convenient open source access by the Internet community to the United States of America Federal Information Processing Standard Secure Hash Algorithms (SHAs) [FIPS 180-2], HMACs based thereon, and HKDF. No independent assertion of the security of these functions by the authors for any particular use is intended. ---------------------------------------------------------------------- On the other hand the C-source files has following security related statements: ---------------------------------------------------------------------- * The SHA-1 algorithm produces a 160-bit message digest for a * given data stream. It should take about 2**n steps to find a * message with the same digest as a given message and * 2**(n/2) to find any two messages with the same digest, * when n is the digest size in bits. Therefore, this * algorithm can serve as a means of providing a * "fingerprint" for a message. ---------------------------------------------------------------------- which do give some assertion of the security of the functions. On the other hand the statement in the SHA1.c might even be incorrect, as I think there are attacks now that can find collisions in 2^69 steps instead of 2^80 steps (http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html). There might be even faster attacks by now. ---------------------------------------------------------------------- Some other nits: In section 3: > 3. Operations on Words ... > > d. The rotate right (circular right shift) operation ROTR^n(x), where > x is a w-bit word and n is an integer with 0 <= n < w, is > defined by > > ROTR^n(x) = (x>>n) OR (x<<(w-n)) > > e. The rotate left (circular left shift) operation ROTL^n(x), where x > is a w-bit word and n is an integer with 0 <= n < w, is defined > by > > ROTL^n(X) = (x<>w-n) ^^^ Could also use "(w-n)" instead of "w-n" just to make sure of the precedence. -- When compiling shatest.c on NetBSD 5.99.39 I do get following warnings: ---------------------------------------------------------------------- shatest.c: In function 'unhexStr': shatest.c:1312: warning: array subscript has type 'char' shatest.c:1320: warning: array subscript has type 'char' shatest.c: In function 'scasecmp': shatest.c:1522: warning: array subscript has type 'char' shatest.c:1523: warning: array subscript has type 'char' ---------------------------------------------------------------------- This is because shatest.c gives char directly to the tolower which is macro in NetBSD. The unhexStr and scasecmp functions should do the similar "(int)(unsigned char)" cast before giving *hexstr/*s1/*s2 to tolower. -- kivinen@iki.fi From tony@att.com Fri Jan 21 08:48:45 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D25553A6A59; Fri, 21 Jan 2011 08:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmbmOaaX6VGy; Fri, 21 Jan 2011 08:48:45 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 1288E3A6A53; Fri, 21 Jan 2011 08:48:44 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1295628690!3011328!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 19370 invoked from network); 21 Jan 2011 16:51:31 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-11.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Jan 2011 16:51:31 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p0LGppo0017334; Fri, 21 Jan 2011 11:51:52 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p0LGpl6j017238; Fri, 21 Jan 2011 11:51:47 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p0LGpOnr027848; Fri, 21 Jan 2011 11:51:25 -0500 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p0LGpJAK027623; Fri, 21 Jan 2011 11:51:19 -0500 Received: from [135.70.217.160] (vpn-135-70-217-160.vpn.east.att.com[135.70.217.160]) by maillennium.att.com (mailgw1) with ESMTP id <20110121165118gw100e4l1ue> (Authid: tony); Fri, 21 Jan 2011 16:51:18 +0000 X-Originating-IP: [135.70.217.160] Message-ID: <4D39B987.808@att.com> Date: Fri, 21 Jan 2011 11:51:19 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Tero Kivinen References: <19769.37852.869585.298102@fireball.kivinen.iki.fi> In-Reply-To: <19769.37852.869585.298102@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 23 Jan 2011 15:54:07 -0800 Cc: draft-eastlake-sha2b.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-eastlake-sha2b-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 16:48:45 -0000 Thank you for comments Tero. More privately. Tony On 1/21/2011 9:10 AM, Tero Kivinen wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. From scott@hyperthought.com Mon Jan 24 10:21:57 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D08D3A6B21 for ; Mon, 24 Jan 2011 10:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.039 X-Spam-Level: X-Spam-Status: No, score=-3.039 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hlp71m5TvyJv for ; Mon, 24 Jan 2011 10:21:56 -0800 (PST) Received: from smtp162.iad.emailsrvr.com (smtp162.iad.emailsrvr.com [207.97.245.162]) by core3.amsl.com (Postfix) with ESMTP id 748F93A6A6C for ; Mon, 24 Jan 2011 10:21:56 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp46.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 9642FE87B7; Mon, 24 Jan 2011 13:24:51 -0500 (EST) X-Virus-Scanned: OK Received: from dynamic13.wm-web.iad.mlsrvr.com (dynamic13.wm-web.iad1a.rsapps.net [192.168.2.220]) by smtp46.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 795F0E86F7; Mon, 24 Jan 2011 13:24:51 -0500 (EST) Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic13.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 6A36F3218001; Mon, 24 Jan 2011 13:24:51 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Mon, 24 Jan 2011 10:24:51 -0800 (PST) Date: Mon, 24 Jan 2011 10:24:51 -0800 (PST) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ymbk-splusp.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1295893491.433714482@192.168.4.58> X-Mailer: webmail8 Subject: [secdir] secdir review of draft-ymbk-splusp X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 18:21:57 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments.=0A=0AThis document describes a way to extend th= e IPv4 address space by reclaiming some of the TCP/UDP port bits for use as= address bits. The document is well written, and the security consideration= s seem complete. I see no security issues with this document.=0A=0A--Scott= =0A From weiler+secdir@watson.org Tue Jan 25 05:28:19 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5D63A686D for ; Tue, 25 Jan 2011 05:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcbVxX4Q9Hy4 for ; Tue, 25 Jan 2011 05:28:19 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id C61A33A6858 for ; Tue, 25 Jan 2011 05:28:18 -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 p0PDVFT1042154 for ; Tue, 25 Jan 2011 08:31: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 p0PDVFZh042150 for ; Tue, 25 Jan 2011 08:31:15 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 25 Jan 2011 08:31: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]); Tue, 25 Jan 2011 08:31:15 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 13:28:20 -0000 Carl Wallace is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2011-02-03 Reviewer LC end Draft Kathleen Moriarty T 2011-01-27 draft-ietf-pmol-metrics-framework-07 Hilarie Orman T 2011-01-26 draft-morton-ippm-rfc4148-obsolete-03 For telechat 2011-02-17 Stephen Kent T 2011-02-10 draft-arkko-dual-stack-extra-lite-03 Chris Lonvick T 2011-02-14 draft-cheshire-dnsext-special-names-01 Sandy Murphy T 2011-02-01 draft-ietf-tsvwg-iana-ports-09 Radia Perlman T 2011-02-08 draft-mraihi-mutual-oath-hotp-variants-12 Eric Rescorla T 2011-02-08 draft-mraihi-totp-timebased-07 For telechat 2011-03-03 Julien Laganier T 2011-02-11 draft-holsten-about-uri-scheme-06 Magnus Nystrom T - draft-meadors-multiple-attachments-ediint-10 Juergen Schoenwaelder T 2011-02-18 draft-bryan-metalinkhttp-19 Last calls and special requests: Derek Atkins 2011-01-18 draft-groves-sakke-00 Rob Austein 2010-12-15 draft-salowey-secsh-uri-00 Rob Austein 2011-01-06 draft-ietf-6man-prefixlen-p2p-01 Dave Cridland 2011-01-18 draft-ietf-isis-purge-tlv-05 Alan DeKok 2011-01-18 draft-ietf-isis-reg-purge-00 Sam Hartman 2011-01-18 draft-turner-cms-symmetrickeypackage-algs-00 Love Hornquist-Astrand 2011-02-01 draft-yevstifeyev-tn3270-uri-12 Barry Leiba 2011-01-31 draft-ietf-ccamp-mpls-tp-cp-framework-05 David McGrew - draft-ietf-ecrit-framework-12 David McGrew 2011-02-01 draft-ietf-intarea-shared-addressing-issues-02 Russ Mundy 2011-01-04 draft-cardona-cablelabs-urn-05 Russ Mundy 2011-01-25 draft-ietf-speermint-architecture-17 Sandy Murphy 2011-01-03 draft-turner-sha0-sha1-seccon-03 Eric Rescorla 2011-01-07 draft-ietf-pce-inter-layer-req-15 Vincent Roca 2011-02-07 draft-reed-urn-dgiwg-02 Joe Salowey 2011-02-08 draft-turner-akf-algs-update-02 Stefan Santesson 2011-02-08 draft-turner-ekpct-algs-update-02 Yaron Sheffer 2011-02-01 draft-ietf-ccamp-rwa-wson-framework-10 Tina TSOU 2011-02-07 draft-ietf-netconf-4741bis-07 Nico Williams 2011-01-14 draft-yevstifeyev-http-headers-not-recognized-11 Larry Zhu 2010-09-30 draft-lundberg-app-tei-xml-06 Glen Zorn 2011-01-18 draft-groves-mikey-sakke-00 From hartmans@mit.edu Tue Jan 25 09:03:56 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C902D3A6819; Tue, 25 Jan 2011 09:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.72 X-Spam-Level: X-Spam-Status: No, score=-102.72 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e26Q63lIJ2yg; Tue, 25 Jan 2011 09:03:56 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 099433A6817; Tue, 25 Jan 2011 09:03:55 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 9A8F620246; Tue, 25 Jan 2011 12:05:02 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 38529432C; Tue, 25 Jan 2011 12:06:36 -0500 (EST) From: Sam Hartman To: secdir@ietf.org Date: Tue, 25 Jan 2011 12:06:36 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: iesg@ietf.org Subject: [secdir] secdir review of draft-turner-cms-symmetrickeypackage-algs-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 17:03:56 -0000 I reviewed this draft. The keyprov working group has defined a CMS content type for transporting a symmetric key and related parameters. (That was a big part of why we chartered them) In order to protected these keys, various CMS facilities can be used. This draft describes what algorithms need to be implemented each CMS mode. There were no surprises; this looks fine. From hilarie@purplestreak.com Tue Jan 25 10:17:49 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BE7C3A6868 for ; Tue, 25 Jan 2011 10:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLteX751Fmep for ; Tue, 25 Jan 2011 10:17:48 -0800 (PST) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by core3.amsl.com (Postfix) with ESMTP id 53A563A6853 for ; Tue, 25 Jan 2011 10:17:48 -0800 (PST) Received: from mx02.mta.xmission.com ([166.70.13.212]) by out02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PhnVW-0007Va-9s; Tue, 25 Jan 2011 11:20:46 -0700 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=fermat.rhmr.com) by mx02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PhnVT-0003R1-0s; Tue, 25 Jan 2011 11:20:46 -0700 Received: from fermat.rhmr.com (localhost [127.0.0.1]) by fermat.rhmr.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p0PILHYF025061; Tue, 25 Jan 2011 11:21:17 -0700 Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id p0PILHGK025060; Tue, 25 Jan 2011 11:21:17 -0700 Date: Tue, 25 Jan 2011 11:21:17 -0700 Message-Id: <201101251821.p0PILHGK025060@fermat.rhmr.com> X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f From: "Hilarie Orman" To: secdir@ietf.org X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx02.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; sa03 1397; Body=1 Fuz1=1 Fuz2=1 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 mx02.mta.xmission.com) Cc: acmorton@att.com Subject: [secdir] Security review of draft-morton-ippm-rfc4148-obsolete-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jan 2011 18:17:49 -0000 Security review of draft-morton-ippm-rfc4148-obsolete-03 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 abstract explains the reasons for abandoning IPPM: This memo reclassifies RFC 4148, the IP Performance Metrics (IPPM) Registry as Obsolete, and withdraws the IANA IPPM Metrics Registry itself from use because it is obsolete. The current registry structure has been found to be insufficiently detailed to uniquely identify IPPM metrics. Despite apparent efforts to find current or even future users, no one has responded to the call for interest in the RFC 4148 registry during the second half of 2010. I don't see any security impacts of this action, and I did read the "security considerations", which I hope will be withdrawn before submission to the RFC editor. Hilarie From tena@huawei.com Tue Jan 25 13:27:33 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9A543A68B1; Tue, 25 Jan 2011 13:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.237 X-Spam-Level: X-Spam-Status: No, score=-106.237 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6s2su1Enpefb; Tue, 25 Jan 2011 13:27:32 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 8D3B43A68C6; Tue, 25 Jan 2011 13:27:32 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFL00KLGL2UFA@usaga02-in.huawei.com>; Tue, 25 Jan 2011 13:30:31 -0800 (PST) Received: from TingZousc1 ([10.212.245.166]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFL00CLMKYGRG@usaga02-in.huawei.com>; Tue, 25 Jan 2011 13:30:30 -0800 (PST) Date: Tue, 25 Jan 2011 13:27:56 -0800 From: Tina Tsou To: ops-dir@ietf.org, secdir@ietf.org Message-id: <01a201cbbcd7$197946c0$4c6bd440$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=ISO-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: Acu81rPbyWvC8QjGT6iixeTbXkVESw== x-cr-hashedpuzzle: Kb73 N1+x QaCS SRUO X9iC a/5H iiZT ohFD ooWx pZsn pgCe tH+x uHtg xbaB yRyF 8PCf; 5; ZAByAGEAZgB0AC0AeQBtAGIAawAtAGEAcABsAHUAcwBwAEAAdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnADsAaQBlAHMAZwBAAGkAZQB0AGYALgBvAHIAZwA7AGkAZQB0AGYAQABpAGUAdABmAC4AbwByAGcAOwBvAHAAcwAtAGQAaQByAEAAaQBlAHQAZgAuAG8AcgBnADsAcwBlAGMAZABpAHIAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {94249E4E-AC6C-4722-8559-B0DA304CD2B0}; dABlAG4AYQBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Tue, 25 Jan 2011 21:27:43 GMT; UgBlAHYAaQBlAHcAIABvAGYAIABkAHIAYQBmAHQALQB5AG0AYgBrAC0AYQBwAGwAdQBzAHAALQAwADgA x-cr-puzzleid: {94249E4E-AC6C-4722-8559-B0DA304CD2B0} Cc: iesg@ietf.org, draft-ymbk-aplusp@tools.ietf.org, ietf@ietf.org Subject: [secdir] Review of draft-ymbk-aplusp-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 21:27:34 -0000 I reviewed the document draft-ymbk-aplusp-08 in general. =20 Operations directorate and Security directorate reviews are solicited primarily to help the area directors improve their efficiency, = particularly when preparing for IESG telechats, and allowing them to focus on = documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work = going on in other parts of the IETF. =20 Reviews from OpsDir/SecDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted = in last call and earlier, may also help the document editors improve their documents. =20 ----- This document is well written, though there may be some nits. Comment #1: In Abstract section this draft proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 = address. A SOHO CPE (A+P) may provide with website service. When a host in = external network accesses this website, what information that DNS servers = feedback to host? If it is an IP address, it can't uniquely identify the CPE. If it = is IP + port range, how can host recognize this and process? If it is IP + = some a Port, how can DNS server know when port changed?=20 Some Operators identify services by five elements include UDP/TCP = well-known ports when CPE is an unreliable device. If well-known ports changed, = service can't be recognized. Comment #2: Abstract section, "In the face of IPv4 address exhaustion, the need for addresses is = stronger than the need to be able to address thousands of applications on a = single host." - This viewpoint is not always true. During the transition from IPv4 to IPv6, some set of operators do not want the services are affected, which = may result some customers lost. A smoothly transition technology is more favorable. Comment #3: Section 1.1 says: Another issue with CGN is the trade-off between = session state and network placement. - If there are too many session state to keep, two CGN or more can be placed. A distributed CGN may be a good choice. And single point of = failure can be resolved Comment #4: In section 3.3.1, it says: different port-ranges can have different lifetimes, and the CPE is not entitled to use them after they expire = what is the appropriate lifetime for a port-rang? When for P2P application, = many ports are used. In a short-term period, when for some fixed service = (e.g. site), a port may be used for many years. Will the server allocate port according application? Or else there is some security problem or port efficient allocation. For the more, port allocation will make more = burdens for server because of large number s of ports and high frequency requisition. Comment #5: SMAP (stateless A+P Mapping) is proposed in section 4.1, IPv4 address = and port is embedded in the IPv6 address =96 which would be used to create a tunnel.=20 - In section 5.2, =93Dynamic Allocation of Port Ranges=94 is proposed. = What if the allocated ports do not belong to a single IP address? The SMAP = mechanism may not work in this case.=20 - The IPv6 address would follow the format defined in [I-D.ietf-behave-address-format], but port is not included in the = address formats defined by that draft. Any plan to define the address format? Here is the format defined in [I-D.ietf-behave-address-format]: +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |PL| 0-------------32--40--48--56--64--72--80--88--96--104---------| +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |32| prefix |v4(32) | u | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |40| prefix |v4(24) | u |(8)| suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |48| prefix |v4(16) | u | (16) | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |56| prefix |(8)| u | v4(24) | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |64| prefix | u | v4(32) | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |96| prefix | v4(32) | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ =09 Figure 1 Comment #6: In section 5.1.2 A+P for Mobile Providers=20 - If=A0A+P is implemented in a terminal device, e.g. mobile phone and = PC, there might be some problems, e.g. ARP problem =96 terminal would not be = able to send packets to other terminals sharing the same IP address with = itself.=20 - Any thoughts about the solution? A new NAT layer between the IP and TCU/UDP layer in the stack? Comment #7: Section 5.2, it says: mechanism can allocate a port range from another = IP within the same subnet. - For example, an internal host1 communicate with an external host2. At first CPE allocates IP1 and a port for some a session. During the communication, more sessions are built and there are no more ports in = IP1. If IP2 is used for session, the packet may be discarded by host2. There may be some errors. Where does 198.51.100.3 come? I can't find it = in Figure 15. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From new-work-bounces@ietf.org Tue Jan 25 09:29:07 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043E13A686E; Tue, 25 Jan 2011 09:29:07 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E418A3A6841; Tue, 25 Jan 2011 09:29:04 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110125172904.E418A3A6841@core3.amsl.com> Date: Tue, 25 Jan 2011 09:29:04 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 25 Jan 2011 13:52:14 -0800 Subject: [secdir] [new-work] WG Review: Light-Weight Implementation Guidance (lwig) 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, 25 Jan 2011 17:29:07 -0000 A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, February 1, 2011. Light-Weight Implementation Guidance (lwig) ------------------------------------------- Current Status: Proposed Working Group Last updated: 2011-01-23 Chairs: TBD Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Transport Area Advisor: TBD Mailing Lists: General Discussion: lwip@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lwip Archive: http://www.ietf.org/mail-archive/web/lwip Description of Working Group: Communications technology is being embedded into our environment. Different types of devices in our buildings, vehicles, equipment and other objects have a need to communicate. It is expected that most of these devices employ the Internet Protocol suite. However, there is a lot of variation in the capabilities between different types of devices, and it is not always easy to embed all the necessary features. The Light-Weight Implementation Guidance (LWIG) Working Group focuses on helping the implementors of the smallest devices. The goal is to be able to build minimal yet interoperable IP-capable devices for the most constrained environments. Building a small implementation does not have to be hard. Many small devices use stripped down versions of general purpose operating systems and their TCP/IP stacks. However, there are implementations that go even further in minimization and can exist in as few as a couple of kilobytes of code, as on some devices this level of optimization is necessary. Technical and cost considerations may limit the computing power, battery capacity, available memory, or communications bandwidth that can be provided. To overcome these limitations the implementors have to employ the right hardware and software mechanisms. For instance, certain types of memory management or even fixed memory allocation may be required. It is also useful to understand what is necessary from the point of view of the communications protocols and the application employing them. For instance, a device that only acts as a client or only requires one connection can simplify its TCP implementation. The purpose of the LWIG working group is to collect experiences from existing small IP stacks with regards to protocol implementation techniques and other details that have been useful in deployments. The group shall focus only on techniques that have been used in actual implementations and do not impact interoperability with other devices. The techniques shall also not affect conformance to the relevant specifications. The output of this work is a document that describes implementation techniques for reducing complexity, memory footprint, or power usage. The main focus is in the IPv4, IPv6, UDP, TCP, ICMPv4/v6, MLD/IGMP, ND, DHCPv4/v6, IPsec, 6LOWPAN, and RPL protocols. This document would be helpful for the implementors of new devices or for the implementors of new general-purpose small IP stacks. It is also expected that the document increases our knowledge of what existing small implementations do, and helps in the further optimization of the existing implementations. On areas where the considerations for small implementations have already been documented the group shall make an effort to refer to those documents instead of developing its own. Generic hardware design advice and software implementation techniques are outside the scope of this work, as such expertise is not within the IETF domain. Protocol implementation experience, however, is within the IETF domain. The group shall also not develop any new protocols or protocol behavior modifications beyond what is already allowed by existing RFCs, because it is important to ensure that different types of devices can work together. The group shall not develop assumptions or profiles about the operating environment of the devices, because, in general, it is not possible to guarantee any special configuration. Finally, while implementation techniques relating to security mechanisms are within scope, mere removal of security functionality from a protocol is not an acceptable recommendation. Given that the group works on both IP and transport layer protocols it is necessary to ensure that expertise in both aspects is present in the group. Participation from the implementors of existing small IP stacks is also required. Milestones: Feb 2011 Design team of experts and a document editor recruited Aug 2011 First version of the implementation guidance document submitted Mar 2012 Submit the implementation guidance document to the IESG for publication as an Informational RFC _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From randy@psg.com Tue Jan 25 13:47:46 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D34353A68C0; Tue, 25 Jan 2011 13:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tb+oBhACSlPP; Tue, 25 Jan 2011 13:47:46 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id F0A0D3A68BC; Tue, 25 Jan 2011 13:47:45 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Phqme-000Huc-5o; Tue, 25 Jan 2011 21:50:40 +0000 Date: Wed, 26 Jan 2011 06:50:39 +0900 Message-ID: From: Randy Bush To: Tina Tsou In-Reply-To: <01a201cbbcd7$197946c0$4c6bd440$@com> References: <01a201cbbcd7$197946c0$4c6bd440$@com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Tue, 25 Jan 2011 13:52:13 -0800 Cc: ops-dir@ietf.org, ietf@ietf.org, iesg@ietf.org, draft-ymbk-aplusp@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ymbk-aplusp-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 21:47:47 -0000 > Operations directorate and Security directorate reviews are solicited > primarily to help the area directors improve their efficiency, particularly > when preparing for IESG telechats, and allowing them to focus on documents > requiring their attention and spend less time on the trouble-free ones. and which are you? can't be ops, as you are a vendor. so security? but we already received the security review. but thanks for the review anyway. randy, a bit confused From new-work-bounces@ietf.org Tue Jan 25 20:50:30 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B8F43A68FD; Tue, 25 Jan 2011 20:50:30 -0800 (PST) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 567403A68FD for ; Tue, 25 Jan 2011 20:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPZS4WZiTq0V for ; Tue, 25 Jan 2011 20:50:28 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 8703A3A689B for ; Tue, 25 Jan 2011 20:50:28 -0800 (PST) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1PhxNm-00035j-7P; Tue, 25 Jan 2011 23:53:26 -0500 Message-Id: <76F17EAA-3C07-42DE-8DD7-EA541517E88E@w3.org> From: Ian Jacobs To: new-work@ietf.org Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 Jan 2011 22:53:25 -0600 X-Mailer: Apple Mail (2.936) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 26 Jan 2011 14:08:15 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Audio Working Group (until 2011-02-25) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 04:50:30 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Rich Web Client Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Audio Working Group: http://www.w3.org/2010/12/audio-wg-charter As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2011-02-25 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Doug Schepers, Team Contact . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2006/rwc/Activity [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From tena@huawei.com Wed Jan 26 14:47:21 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88D563A69EB; Wed, 26 Jan 2011 14:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.251 X-Spam-Level: X-Spam-Status: No, score=-106.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MdE4+9WBvCZ; Wed, 26 Jan 2011 14:47:20 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 7F6803A69DD; Wed, 26 Jan 2011 14:47:20 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFN00J8EJFXKY@usaga02-in.huawei.com>; Wed, 26 Jan 2011 14:50:21 -0800 (PST) Received: from TingZousc1 ([10.212.246.230]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFN00M4CJFQNG@usaga02-in.huawei.com>; Wed, 26 Jan 2011 14:50:21 -0800 (PST) Date: Wed, 26 Jan 2011 14:50:18 -0800 From: Tina Tsou In-reply-to: To: 'Randy Bush' Message-id: <001701cbbdab$6b3ce000$41b6a000$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acu82qXBYG9862qhTTOT3oPTAW8HiQA0AorA References: <01a201cbbcd7$197946c0$4c6bd440$@com> Cc: ops-dir@ietf.org, ietf@ietf.org, iesg@ietf.org, draft-ymbk-aplusp@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ymbk-aplusp-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 22:47:21 -0000 Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Tuesday, January 25, 2011 1:51 PM To: Tina Tsou Cc: ops-dir@ietf.org; secdir@ietf.org; draft-ymbk-aplusp@tools.ietf.org; iesg@ietf.org; ietf@ietf.org Subject: Re: Review of draft-ymbk-aplusp-08 > Operations directorate and Security directorate reviews are solicited > primarily to help the area directors improve their efficiency, particularly > when preparing for IESG telechats, and allowing them to focus on documents > requiring their attention and spend less time on the trouble-free ones. and which are you? can't be ops, as you are a vendor. so security? but we already received the security review. [Tina: I know the author is my friend Randy, so I have to be very careful ;-) I'm a member and also the secretary of Operations directorate. Here is the wiki page for the Operations directorate. http://trac.tools.ietf.org/area/ops/trac/wiki/Directorates You can see many of us do not have the affiliation of operators. I did the additional review besides the allocated member's review. I'm also a member of Security directorate. I did the additional review besides the allocated member's review. Hope it clarifies. ] but thanks for the review anyway. randy, a bit confused From clonvick@cisco.com Wed Jan 26 18:47:28 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16CF43A6906; Wed, 26 Jan 2011 18:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qf4aU9HSaRvr; Wed, 26 Jan 2011 18:47:27 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5DB7A3A6A5F; Wed, 26 Jan 2011 18:47:27 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGJsQE2rR7Hu/2dsb2JhbACWXAGOIXOgW5tKhU8EhRc Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 27 Jan 2011 02:50:29 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0R2oTAp029783; Thu, 27 Jan 2011 02:50:29 GMT Date: Wed, 26 Jan 2011 18:50:29 -0800 (PST) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-cheshire-dnsext-special-names.all@tools.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [secdir] SECDIR review of draft-cheshire-dnsext-special-names-01.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 02:47:28 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall, the document appears to be well written and I havn't found any security concerns with it. I will bring up a couple of nits that the authors may want to address. The use of the term "carve" may not be well understood by non-native English speakers. Perhaps using the term "reserved" would be better. in the IANA section, shouldn't the IESG perform the check that your 7 questions are answered appropriately? Along those lines, since you give examples of special-use domain names, wouldn't it be appropriate to start the IANA registry with those? The last lines of section 2 are: processes, that process should be used. Reservation of a Special-Use Domain Names is not a mechanism for circumventing normal domain name registration processes. I'd s/Names/Name/ Regards, Chris From kent@bbn.com Thu Jan 27 08:26:46 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196EB3A690D for ; Thu, 27 Jan 2011 08:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.412 X-Spam-Level: X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LETj-lZyPB4b for ; Thu, 27 Jan 2011 08:26:44 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E873C3A690A for ; Thu, 27 Jan 2011 08:26:43 -0800 (PST) Received: from [192.1.255.194] (port=49192) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PiUjD-000Gpj-KS; Thu, 27 Jan 2011 11:29:47 -0500 Mime-Version: 1.0 Message-Id: Date: Thu, 27 Jan 2011 11:29:43 -0500 To: secdir@ietf.org From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-915976709==_ma============" Cc: ars.eggert@nokia.com, jari.arkko@piuha.net, Ralph Droms Subject: [secdir] review of draft-arkko-dual-stack-extra-lite-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 16:26:46 -0000 --============_-915976709==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is a very brief (8-page) document. It defines how to employ address translation (NAT) to serve a large (> 2^24) user population without making use of a large private address space. Thus the focus here is a bit different from the usual NAT context, where one uses a large-enough private address space behind a NAT, and maps that space into a smaller (typically IPV4) address space on the other side of a NAT. The authors review several other approaches to dealing with the problem, as a prelude to presenting the proposed solution. The solution put forth here is applicable to nets where each endpoint has a point-to-point link to a NAT (vs. a broadcast net). The authors note that if tunneling is already being used to connect endpoints to a gateway/NAT, this technique also is applicable. In either case the NAT maintains a map between the overlapping private address spaces and the public space by associating a network interface ID (as well as the private IP address) with each endpoint. The authors recommend employing their solution for dealing with the IPv4 addresses that need to be associated with endpoints in the dual stack [RFC 4213] deployment model for IPv6. They also note that their proposal could be used in another IPv6 deployment model [I-D.ietf-behave-v6v4-xlate-stateful], but that it probably is not necessary there, because of the abundance of IPv6 address space. The security considerations section is but one sentence: "This practices outlined in this document do not affect the security properties of address translation." I think this needs to be expanded upon :. The authors should cite at least one RFC that deals with NAT and has sustentative security considerations section. If they can't find a suitable RFC (2993 is the obvious candidate, but it is outdated in several of its references and comments) then they at least describe why they believe that this proposal introduces no new security implications. --============_-915976709==_ma============ Content-Type: text/html; charset="us-ascii" review of draft-arkko-dual-stack-extra-lite-03

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

This is a very brief (8-page) document. It defines how to employ address translation (NAT) to serve a large (> 2^24) user population without making use of a large private address space. Thus the focus here is a bit different from the usual NAT context, where one uses a large-enough private address space behind a NAT, and maps that space into a smaller (typically IPV4) address space on the other side of a NAT.

The authors review several other approaches to dealing with the problem, as a prelude to presenting the proposed solution. The solution put forth here is applicable to nets where each endpoint has a point-to-point link to a NAT (vs. a broadcast net). The authors note that if tunneling is already being used to connect endpoints to a gateway/NAT, this technique also is applicable. In either case the NAT maintains a map between the overlapping private address spaces and the public space by associating a network interface ID (as well as the private IP address) with each endpoint.

The authors recommend employing their solution for dealing with the IPv4 addresses that need to be associated with endpoints in the dual stack [RFC 4213] deployment model for IPv6. They also note that their proposal could be used in another IPv6 deployment model [I-D.ietf-behave-v6v4-xlate-stateful], but that it probably is not necessary there, because of the abundance of IPv6 address space.

The security considerations section is but one sentence: "This practices outlined in this document do not affect the security properties of address translation." I think this needs to be expanded upon :. The authors should cite at least one RFC that deals with NAT and has sustentative security considerations section. If they can't find a suitable RFC (2993 is the obvious candidate, but it is outdated in several of its references and comments) then they at least describe why they believe that this proposal introduces no new security implications.

--============_-915976709==_ma============-- From randy@psg.com Wed Jan 26 15:31:05 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E41013A69FB; Wed, 26 Jan 2011 15:31:05 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGu5zEWhrbXs; Wed, 26 Jan 2011 15:31:05 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id C4A963A69FA; Wed, 26 Jan 2011 15:31:04 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PiEsD-000LkQ-Ow; Wed, 26 Jan 2011 23:34:01 +0000 Date: Thu, 27 Jan 2011 08:34:06 +0900 Message-ID: From: Randy Bush To: Tina Tsou In-Reply-To: <001701cbbdab$6b3ce000$41b6a000$@com> References: <01a201cbbcd7$197946c0$4c6bd440$@com> <001701cbbdab$6b3ce000$41b6a000$@com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Fri, 28 Jan 2011 09:08:42 -0800 Cc: ops-dir@ietf.org, ietf@ietf.org, iesg@ietf.org, draft-ymbk-aplusp@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ymbk-aplusp-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 23:31:06 -0000 > I'm a member and also the secretary of Operations directorate. the ops dir is a joke. does reviews for an area director who does not do his/her own? there is an ops cabal that meets at ietf and has ML etc. all actual ops except for one guest, the actual ops director, ron. > http://trac.tools.ietf.org/area/ops/trac/wiki/Directorates > You can see many of us do not have the affiliation of operators. welcome to the ietf > I'm also a member of Security directorate. must be fun. randy From j.schoenwaelder@jacobs-university.de Fri Jan 28 12:38:52 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4C83A6876; Fri, 28 Jan 2011 12:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.118 X-Spam-Level: X-Spam-Status: No, score=-103.118 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UKZicY6qm+g; Fri, 28 Jan 2011 12:38:51 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 83E4C3A680E; Fri, 28 Jan 2011 12:38:51 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EDCD2C0045; Fri, 28 Jan 2011 21:41:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wpFONHENNrMG; Fri, 28 Jan 2011 21:41:57 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9306CC0054; Fri, 28 Jan 2011 21:41:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 248BC1633032; Fri, 28 Jan 2011 21:41:46 +0100 (CET) Date: Fri, 28 Jan 2011 21:41:46 +0100 From: Juergen Schoenwaelder To: iesg@ietf.org, secdir@ietf.org, draft-bryan-metalinkhttp.all@tools.ietf.org Message-ID: <20110128204146.GA24446@elstar.local> Mail-Followup-To: iesg@ietf.org, secdir@ietf.org, draft-bryan-metalinkhttp.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [secdir] secdir review of draft-bryan-metalinkhttp-19.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 20:38:52 -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. Metalink provides meta information about resources such as locations where copies can be found or checksums. This specification defines how Metalink data can be transported as HTTP header lines. The document is generally easy to follow. The security considerations seem to be short but appropriate. That said, it seems the text in section 3 is not final in the sense that there might still be an open issue, although there is also text that says that it is up to the server to decide how many Link headers to send. The fix might be as simple as removing the following text: [[Some organizations have many mirrors. Only send a few mirrors, or only use the Link header fields if Want-Digest is used?]] But then Appendix C lists this again as an open issue, together with a question whether partial hashes should be carried in HTTP as well. Perhaps the answer is "no" and this is just an old open issue item - I can't judge. Editorial nits: - p1: s/althought/although/ - p7: s/fieldss/fields/ - p10: s/fieldss/fields/ - p11: s/fieldss/fields/ - p11: s/fieldss/fields/ - p11: s/syncronisation/synchronisation - p12: s/cyptographic/cryptographic - p13: s/fieldss/fields/ - p15: s/reponse/response/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From anthonybryan@gmail.com Sat Jan 29 22:38:11 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 147413A6925; Sat, 29 Jan 2011 22:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.626 X-Spam-Level: X-Spam-Status: No, score=-3.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bbv579sUtPgb; Sat, 29 Jan 2011 22:38:09 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 586133A68C8; Sat, 29 Jan 2011 22:38:09 -0800 (PST) Received: by ewy8 with SMTP id 8so2263216ewy.31 for ; Sat, 29 Jan 2011 22:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=yomlNnYl37zCf1eIAug2QEa4+OlC2Zi+F0xSAPtjAoE=; b=uOdGI9Q7+kAoADHpPw23aZjrzOMktWCVCFkq2Hpx569uEUKnPBHmyBVInlQj9nq+6W rn5HR56H4tiAUeYeeRBFMVKcEr5XWmByeS4Y0zmr0t7NC0heUiuvrY/RYHS91TYY5Cyw np3OQ1Y9VFx1pPbLRuWqb+Z+OxZsPVyqO35wY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=rANPhv37Qt9I8nP5FKporwxEyS9fIcY6ZuhG5X7WJzCkqycS5NKg4ful4qZOtg14vm 8TRXbXQS1ubsgahFR8SoIZozDR2++A6dR8Qiw5fzlEWHn/zzwSo4VYIPLi1vRhJfTnaZ k6LQtIFNBHk8D2Sox3K2GQk9G7hfclJ5sNYAo= MIME-Version: 1.0 Received: by 10.213.22.209 with SMTP id o17mr6959305ebb.41.1296369678666; Sat, 29 Jan 2011 22:41:18 -0800 (PST) Received: by 10.213.98.69 with HTTP; Sat, 29 Jan 2011 22:41:18 -0800 (PST) In-Reply-To: <20110128204146.GA24446@elstar.local> References: <20110128204146.GA24446@elstar.local> Date: Sun, 30 Jan 2011 01:41:18 -0500 Message-ID: From: Anthony Bryan To: Juergen Schoenwaelder , iesg@ietf.org, secdir@ietf.org, draft-bryan-metalinkhttp.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [secdir] secdir review of draft-bryan-metalinkhttp-19.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 06:38:11 -0000 On Fri, Jan 28, 2011 at 3:41 PM, Juergen Schoenwaelder 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. =A0These comments were written primarily for the benefit of the > security area directors. =A0Document editors and WG chairs should treat > these comments just like any other last call comments. > > Metalink provides meta information about resources such as locations > where copies can be found or checksums. This specification defines how > Metalink data can be transported as HTTP header lines. The document is > generally easy to follow. The security considerations seem to be short > but appropriate. > > That said, it seems the text in section 3 is not final in the sense > that there might still be an open issue, although there is also text > that says that it is up to the server to decide how many Link headers > to send. The fix might be as simple as removing the following text: > > =A0 [[Some organizations have many mirrors. =A0Only send a few mirrors, o= r > =A0 only use the Link header fields if Want-Digest is used?]] > > But then Appendix C lists this again as an open issue, together with a > question whether partial hashes should be carried in HTTP as > well. Perhaps the answer is "no" and this is just an old open issue > item - I can't judge. yes, old issue. I've removed the text. > Editorial nits: > > - p1: s/althought/although/ > > - p7: s/fieldss/fields/ > > - p10: s/fieldss/fields/ > > - p11: s/fieldss/fields/ > > - p11: s/fieldss/fields/ > > - p11: s/syncronisation/synchronisation > > - p12: s/cyptographic/cryptographic > > - p13: s/fieldss/fields/ > > - p15: s/reponse/response/ eep! I've fixed all those typos. thanks, Juergen. --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From gwz@net-zen.net Sun Jan 30 03:55:00 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D22D23A6977 for ; Sun, 30 Jan 2011 03:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.636 X-Spam-Level: X-Spam-Status: No, score=-103.636 tagged_above=-999 required=5 tests=[AWL=0.963, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLnAqBhUpeaC for ; Sun, 30 Jan 2011 03:55:00 -0800 (PST) Received: from smtpauth20.prod.mesa1.secureserver.net (smtpauth20.prod.mesa1.secureserver.net [64.202.165.36]) by core3.amsl.com (Postfix) with SMTP id 02D0D3A6973 for ; Sun, 30 Jan 2011 03:54:59 -0800 (PST) Received: (qmail 9082 invoked from network); 30 Jan 2011 11:58:10 -0000 Received: from unknown (124.122.190.93) by smtpauth20.prod.mesa1.secureserver.net (64.202.165.36) with ESMTP; 30 Jan 2011 11:58:08 -0000 From: "Glen Zorn" To: , , , Date: Sun, 30 Jan 2011 18:57:44 +0700 Organization: Network Zen Message-ID: <000001cbc074$eb1b10f0$c15132d0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvAdODyYgmg4dzFQJWjFf21rT3diA== Content-Language: en-us Subject: [secdir] secdir review of draft-groves-mikey-sakke-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 11:55:00 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. EDITORIAL COMMENTS In the Abstract, the acronym IDPKC doesn't match the capitalized letters in its expansion. Suggestion: s/Identifier-based Public Key Cryptography/Identifier-Based Public Key Cryptography/ In section 1, paragraph 2, s/legislation/legislations/. Why is the word "identifier" (and variants) persistently capitalized? It doesn't appear to be being used as a proper noun. In the title of section 2, s/Mode;/Mode:/. In section 2.1, paragraph 1, the acronym "TGK" is not expanded on first use. There is no IANA Considerations section, FULL STOP. From sra@hactrn.net Sun Jan 30 14:44:58 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D54823A6B48; Sun, 30 Jan 2011 14:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.76 X-Spam-Level: X-Spam-Status: No, score=-99.76 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+gAWpgpcrDJ; Sun, 30 Jan 2011 14:44:58 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id D669F3A6B44; Sun, 30 Jan 2011 14:44:57 -0800 (PST) Received: from angband.hactrn.net (host-174-45-45-87.gdj-co.client.bresnan.net [174.45.45.87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "angband.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 5ECF628451; Sun, 30 Jan 2011 22:48:06 +0000 (UTC) Received: from angband.hactrn.net (localhost [IPv6:::1]) by angband.hactrn.net (Postfix) with ESMTP id 9D8FD15ED25; Sun, 30 Jan 2011 13:17:09 +0000 (UTC) Date: Sun, 30 Jan 2011 08:17:09 -0500 From: Rob Austein To: iesg@ietf.org, secdir@ietf.org, draft-salowey-secsh-uri.all@tools.ietf.org MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20110130131709.9D8FD15ED25@angband.hactrn.net> Subject: [secdir] Review of draft-salowey-secsh-uri-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 22:44:59 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft defines URI syntax and semantics for ssh. The proposed mechanism is straightforward, and the authors have shown laudable restraint in defining only the minimum necessary to do the job. I have no serious security concerns regarding this document, but did notice one omission: the (otherwise quite good) discussion of the fingerprint option gives no guidance on interaction with RFC 4255. Such a discussion need not be very long (a paragraph would do), but should cover both the presence and absence of a verified DNSSEC signature for the SSHFP RRset, as the recommendations presumably will be different for those two cases. From sra@hactrn.net Sun Jan 30 14:44:59 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E88733A6B44; Sun, 30 Jan 2011 14:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.295 X-Spam-Level: X-Spam-Status: No, score=-100.295 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwIpiqTNu-pp; Sun, 30 Jan 2011 14:44:58 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id D66E63A6B47; Sun, 30 Jan 2011 14:44:57 -0800 (PST) Received: from angband.hactrn.net (host-174-45-45-87.gdj-co.client.bresnan.net [174.45.45.87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "angband.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 9AC052846B; Sun, 30 Jan 2011 22:48:06 +0000 (UTC) Received: from angband.hactrn.net (localhost [IPv6:::1]) by angband.hactrn.net (Postfix) with ESMTP id 75A0915ED88; Sun, 30 Jan 2011 13:48:10 +0000 (UTC) Date: Sun, 30 Jan 2011 08:48:09 -0500 From: Rob Austein To: iesg@ietf.org, secdir@ietf.org, draft-ietf-6man-prefixlen-p2p.all@tools.ietf.org MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20110130134810.75A0915ED88@angband.hactrn.net> Subject: [secdir] Review of draft-ietf-6man-prefixlen-p2p-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 22:44:59 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft discusses several reasons why the recommendations against using 127-bit prefixes on inter-router IPv6 point-to-point links in the current RFCs are not merely specious but actively harmful, and details several attack scenarios in which 127-bit prefixes on inter-router point-to-point links are a better defense than anything that can be done with 64-bit prefixes. The draft concludes by requiring (if this draft is adopted) router support for 127-bit prefixes and makes some recommendations on how to avoid having use of 127-bit prefixes cause problems with other IPv6 implementations. I have no security concerns regarding this document. Should have done this years ago, and the authors of this draft deserve our thanks for their perseverance.