From Ted.Lemon@nominum.com Sat Feb 1 10:22:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6C11A03EC; Sat, 1 Feb 2014 10:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvyF7J3tN82e; Sat, 1 Feb 2014 10:22:54 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8DECF1A045F; Sat, 1 Feb 2014 10:22:54 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUu07elODlQmgf/ugMDtWzUYeXKC/3Un8@postini.com; Sat, 01 Feb 2014 10:22:50 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 742FD1B82F8; Sat, 1 Feb 2014 10:22:50 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 6DBB9190052; Sat, 1 Feb 2014 10:22:50 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 1 Feb 2014 10:22:50 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4736056F@PUEXCB1B.nanterre.francetelecom.fr> Date: Sat, 1 Feb 2014 13:22:45 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <2B98A618-A1A3-40E2-8C0B-31F677ACE327@nominum.com> References: <1f794d77ca95458d9d7cf06e20950090@BLUPR05MB737.namprd05.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36F4736024C@PUEXCB1B.nanterre.francetelecom.fr> <638ccecdeecb4b458718b1c33821c092@BLUPR05MB737.namprd05.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36F473603EB@PUEXCB1B.nanterre.francetelecom.fr> <9e76a90f04f24e3aa156abcc1cca7f5e@BLUPR05MB737.namprd05.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36F4736056F@PUEXCB1B.nanterre.francetelecom.fr> To: "mohamed.boucadair@orange.com Boucadair" X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "draft-ietf-pcp-nat64-prefix64.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir Review of draft-ietf-pcp-nat64-prefix64-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 18:22:56 -0000 On Jan 24, 2014, at 7:51 AM, mohamed.boucadair@orange.com wrote: > For issue#9, I didn't added any change for the moment but will = reconsider it if we received a similar comment during the WGLC.=20 >=20 > The next revision of the draft will include what we have agreed so = far. Thanks for getting this update done, Med, and for the review and = feedback, Stephen. I've looked at Med's response on point 9, and it = makes sense to me, so I'm going to assume that no further action on that = is needed unless I hear otherwise. From dharkins@lounge.org Sat Feb 1 10:54:11 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877D71A05ED; Sat, 1 Feb 2014 10:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kpb7ARPbBtDy; Sat, 1 Feb 2014 10:54:09 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB5F1A05CF; Sat, 1 Feb 2014 10:54:09 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id CFBF31022400A; Sat, 1 Feb 2014 10:54:05 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 1 Feb 2014 10:54:05 -0800 (PST) Message-ID: Date: Sat, 1 Feb 2014 10:54:05 -0800 (PST) From: "Dan Harkins" To: draft-ietf-alto-protocol.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 Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-alto-protocol X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 18:54:11 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft defines a protocol that allows a server to provide network location information, network structure and network cost/preference to a client which then can build an abstract view of the network in order to determine how best to use it. This draft is "ready with nits" (per secdir review instructions). And those nits are: - 6.1.1.1 mixes the idea of "cost" and "preference". While it's natural for people to prefer lower cost I think it would be better to say so explicitly: "A lower value indicates a lower cost" or this field "conveys a generic measure indicating preference for routing traffic from source to destination" or something like that. - 6.1.2, while a particular Cost Map may contain only one of the two cost modes, servers MUST implement support for both, right? It's not clear from the text. - 6.3, since the tag must not contain ASCII characters below 0x21 or above 0x7e you can't really construct one from the hash of the contents of a Network Map. Also, given those restrictions and the fact that a tag just has to be less than or equal to 64 octets, the probability of identical tags being used is not zero. I think the probability of the tag from example 11.3.1.7 is 0.5 to collide with one of just 460 other Network Maps. I suggest requiring a tag to be 64 octets. That will make even money probability of collision among nearly 3000 other Network Maps, which is safer. - 8.3.5, encryption and integrity protection go hand-in-hand, they cannot be "and/or". Suggest changing the sentence to "When confidentiality and data integrity between client and server are required, and server and/or client authentication is required…." This section should refer to section 15 (Security Considerations). - 11.3.2.6, what does it mean for a Version Tag to be "consistent with" another Version Tag? Do you mean that they are "identical"? Same length and same value? Or would "0004579342" be "consistent" with "4579342"? - 15.3.1, the ALTO data can be sensitive since it includes things like endpoint addresses (useful for those who like to monitor the Internet). I think risk (2) here should include mention of that. There may be classes of ALTO data for which certain clients are authorized to receive and others are not. - 15.3.2, the Security Considerations section seems an odd place for normative language-- "HTTP Digest authentication MUST be supported". I suggest finding a more appropriate place, perhaps 8.3.5, to spell out normative requirements. Also, authenticating the client in the TLS exchange would be much preferable and I think mention should be made on that option. I think differentiated authorization (see my previous comment) would be easier this way too. - 15.4.2, authorization of an authenticated client is another useful protection strategy here-- some client's may get obfuscated data, and some may get the raw data. I think the Security Considerations are well done. regards, Dan. From d3e3e3@gmail.com Sun Feb 2 09:22:59 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476951A00F3; Sun, 2 Feb 2014 09:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4w9nCB1SI8z; Sun, 2 Feb 2014 09:22:57 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5521A00F1; Sun, 2 Feb 2014 09:22:57 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id wo20so7064938obc.0 for ; Sun, 02 Feb 2014 09:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SrPxE0VVxEgSgLa6zx2pSKdwO6gT/lu3Y5ximzvlNBc=; b=HGy5bYSUe45xnNJbLdRygCvbJb4A4DWpGhnoJrgJCCHnMAWlkSJl+lEYS7BibrZMTY KJOCQmhADqAKo1Fi2sFEJrvF1qhlCqLBg//6bD3L3Mgbc9SrXgc+HXYBQlrCf1FCKWfO LF4iNcHUNXF0YKjvt8v0cGriW10NXK43Ra8jCvIijmKL/iwJT2UsIREStkq1a1NuMqV7 0OW2pYCsh+2jpkzpZsMGYeEUAkXInH8N53I964yTBEIOgNLF7BxyggnoA2sL/AxS+6+3 ylXUsQb240xuNVoDUsbODHiQXxS/SNP74yrApsiwsZUbIPlBLMTX1YAQTLsDjTKv6u6v 0ktA== X-Received: by 10.60.115.6 with SMTP id jk6mr54820oeb.67.1391361772792; Sun, 02 Feb 2014 09:22:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.33.102 with HTTP; Sun, 2 Feb 2014 09:22:32 -0800 (PST) In-Reply-To: <20140131.211640.309066023.mbj@tail-f.com> References: <20140131.211640.309066023.mbj@tail-f.com> From: Donald Eastlake Date: Sun, 2 Feb 2014 12:22:32 -0500 Message-ID: To: Martin Bjorklund Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-netmod-system-mgmt.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-netmod-system-mgmt-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 17:22:59 -0000 Hi Martin, On Fri, Jan 31, 2014 at 3:16 PM, Martin Bjorklund wrote: > Hi, > > Thank you for your review! > > Donald Eastlake wrote: >> Hi, >> >> Sorry this review is late. >> >> 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. >> >> I believe this draft is ready with issues. >> >> This draft specifies a YANG data model for configuration and >> identification of NETCONF server device information. You might think >> there would not be much in the way of Security Considerations for a >> "data model" but the model includes User Authentication, sensitive >> writable data objects, and the like. >> >> For user password authentication, there are provisions for storing a >> plain text of the password or a salted hash. Hash functions available >> are MD5, SHA-256, and SHA-512. >> >> Security Considerations: >> >> The Security Considerations section seems pretty thorough in covering >> NETCONF security features such as SSH transport and access controls. >> However, I believe the Security Considerations should recommend not >> storing passwords as plaintext but rather as a salted hash. > > Actually, the clear text password is never stored: > > The '$0$' prefix signals that the value is clear text. When > such a value is received by the server, a hash value is > calculated, and the string '$$$' or > $$$$ is prepended to the result. This > value is stored in the configuration data store. > > The client can send a clear text password (over SSH or TLS) but the > server will never store it in clear text. Ahh, OK. >> While the >> Security Considerations section refers to RFC 6151 for MD5 Security >> Considerations and having that reference is good, I believe this >> document should also recommend that MD5 not be used as the password >> salted hash function. > > This was discussed in the WG, and we felt that whatever we would say > would be better stated in RFC 6151. Maybe we can be more explicit > about the recommendation: > > OLD: > > This YANG model defines a type "crypt-hash" that can be used to store > MD5 hashes. ^RFC6151^ discusses security considerations for MD5. > > > NEW: > > This YANG model defines a type "crypt-hash" that can be used to store > MD5 hashes. ^RFC6151^ discusses security considerations for MD5. The > usage of MD5 is NOT RECOMMENDED. That would make me happy. >> For the list of sensitive readable data and sensitive remote procedure >> call operations, the draft is careful to say "It is thus important to >> control access to these operations." However, while it is pretty >> obvious, these words or equivalent seem to be missing in reference to >> the sensitive writable data. > > The Security Consideration section is modeled after a template found > at: > > http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines > > I don't mind an update, but I believe we should update the template as > well in this case. > > The current text says that "write operations [...] without protection > can have a negative effect [...]". > > The other paragraphs use the phrase: > > "It is thus important to control [...] access [to these data nodes]". > > I think the current text says the same thing, but I guess it can be > made more explicit: > > OLD: > > There are a number of data nodes defined in this YANG module which are > writable/creatable/deletable (i.e. config true, which is the > default). These data nodes may be considered sensitive or vulnerable > in some network environments. Write operations (e.g. edit-config) to > these data nodes without proper protection can have a negative effect > on network operations. These are the subtrees and data nodes and their > sensitivity/vulnerability: > > > NEW: > > There are a number of data nodes defined in this YANG module which are > writable/creatable/deletable (i.e. config true, which is the > default). These data nodes may be considered sensitive or vulnerable > in some network environments. Write operations to these data nodes can > have a negative effect on network operations. It is thus important to > control write access (e.g., via edit-config) to these data nodes. > These are the subtrees and data nodes and their > sensitivity/vulnerability: OK. >> Trivial: >> >> Section 2.3, first line: "need" -> "needs" >> Section 2.3, 2nd paragraph, second line: "need" -> "needs" >> I believe RPC should be expanded to "remote procedure call" at its one >> use in the text of the draft, unless I've expanded the acronym wrong, >> which would be proof that whatever it stands for it should be spelled >> out. > > All fixed. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > /martin From jhutz@cmu.edu Sun Feb 2 11:33:19 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37FA1A0101; Sun, 2 Feb 2014 11:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8DNgaTtOro4; Sun, 2 Feb 2014 11:33:17 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (smtp02.srv.cs.cmu.edu [128.2.217.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4A31A0100; Sun, 2 Feb 2014 11:33:17 -0800 (PST) Received: from [192.168.202.157] (pool-108-39-146-104.pitbpa.fios.verizon.net [108.39.146.104]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s12JX4Vo020510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 2 Feb 2014 14:33:10 -0500 (EST) Message-ID: <1391369584.4360.72.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: Dan Harkins Date: Sun, 02 Feb 2014 14:33:04 -0500 In-Reply-To: <23845_1391280851_s11IsAD0008772_cd3fb9f2748d08183af6652c0d58f61a.squirrel@www.trepanning.net> References: <23845_1391280851_s11IsAD0008772_cd3fb9f2748d08183af6652c0d58f61a.squirrel@www.trepanning.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.201 Cc: secdir@ietf.org, draft-ietf-alto-protocol.all@tools.ietf.org, iesg@ietf.org, jhutz@cmu.edu Subject: Re: [secdir] secdir review of draft-ietf-alto-protocol X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 19:33:20 -0000 On Sat, 2014-02-01 at 10:54 -0800, Dan Harkins wrote: > - 6.3, since the tag must not contain ASCII characters below > 0x21 or above 0x7e you can't really construct one from the > hash of the contents of a Network Map. Uh, sure you can. Figure out some scheme for serializing the contents. Compute a hash. Encode in base64. Or hex. > Also, given those > restrictions and the fact that a tag just has to be less than > or equal to 64 octets, the probability of identical tags being > used is not zero. I think the probability of the tag from > example 11.3.1.7 is 0.5 to collide with one of just 460 > other Network Maps. > > I suggest requiring a tag to be 64 octets. That will make > even money probability of collision among nearly 3000 > other Network Maps, which is safer. OK, maybe I'm confused and reading out of context here. But I once had someone tell me I needed to change my 5-character username because they were requiring all usernames to be at least 6 characters, _in order to increase the number of possible usernames_. That is, they claimed they were increasing the size of a namespace by eliminating possible names. The point is, if a tag is required to be exactly 64 octets, you get 0x5e^64 possible tags. But if it is required to be up to 64 octets, you get Sum(i=0..64) 0x5e^i possible tags, which is strictly greater than 0x5e^64. So, requiring a tag to be 64 octets _reduces_ the number of possible tags, thereby increasing the chance of collision. > - 8.3.5, encryption and integrity protection go hand-in-hand, > they cannot be "and/or". Huh? That's not true. Confidentiality and integrity are separable, and it is common to want one without the other. As it turns out, neither TLS nor SSH generally gives you that option, but the and/or is about which features you need, not what is practical. I do agree that it's clearer to use the word "confidentiality" rather than "encryption". -- Jeff From leifj@sunet.se Sun Feb 2 13:32:05 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DF01A00D8; Sun, 2 Feb 2014 13:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.535, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7C-GEWQsST5; Sun, 2 Feb 2014 13:32:02 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) by ietfa.amsl.com (Postfix) with ESMTP id 9279B1A00D6; Sun, 2 Feb 2014 13:32:02 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id s12LVsA6031441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 2 Feb 2014 22:31:54 +0100 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.4/8.14.4) with ESMTP id s12LVoZa003806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Feb 2014 22:31:53 +0100 (CET) X-Footer: c3VuZXQuc2U= Received: from [10.0.0.112] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.2) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256 bits)); Sun, 2 Feb 2014 22:31:48 +0100 Message-ID: <52EEB943.1070709@sunet.se> Date: Sun, 02 Feb 2014 22:31:47 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-xrblock-rtcp-xr-synchronization.all@tools.ietf.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09LlxvSsw - b19c3f417bf6 - 20140202 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: [secdir] secdir review of draft-ietf-xrblock-rtcp-xr-synchronization-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 21:32:05 -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. >From the abstract: This document defines two RTP Control Protocol (RTCP) Extended Report (XR) Blocks that allow the reporting of synchronization delay and offset metrics for use in a range of RTP applications. This is outside the area of my expertise but the claim in the Security Considerations section that this I-D doesn't introduce any new security issues beyond those described in RFC3611 seem reasonable. I'd say this goes in the "no problem" bucket. From dharkins@lounge.org Sun Feb 2 18:18:54 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B99F1A0155; Sun, 2 Feb 2014 18:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrNKMRAs090y; Sun, 2 Feb 2014 18:18:53 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 60A261A014F; Sun, 2 Feb 2014 18:18:53 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id E8F3A1022400A; Sun, 2 Feb 2014 18:18:48 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 2 Feb 2014 18:18:49 -0800 (PST) Message-ID: In-Reply-To: <1391369584.4360.72.camel@destiny.pc.cs.cmu.edu> References: <23845_1391280851_s11IsAD0008772_cd3fb9f2748d08183af6652c0d58f61a.squirrel@www.trepanning.net> <1391369584.4360.72.camel@destiny.pc.cs.cmu.edu> Date: Sun, 2 Feb 2014 18:18:49 -0800 (PST) From: "Dan Harkins" To: "Jeffrey Hutzelman" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: iesg@ietf.org, draft-ietf-alto-protocol.all@tools.ietf.org, secdir@ietf.org, jhutz@cmu.edu Subject: Re: [secdir] secdir review of draft-ietf-alto-protocol X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 02:18:54 -0000 On Sun, February 2, 2014 11:33 am, Jeffrey Hutzelman wrote: > On Sat, 2014-02-01 at 10:54 -0800, Dan Harkins wrote: >> - 8.3.5, encryption and integrity protection go hand-in-hand, >> they cannot be "and/or". > > Huh? That's not true. Confidentiality and integrity are separable, and > it is common to want one without the other. As it turns out, neither > TLS nor SSH generally gives you that option, but the and/or is about > which features you need, not what is practical. They may be separable but you don't want to separate them. You never want to do encryption without integrity protection. You can do integrity protection without encryption though and there are TLS ciphersuites to give you that-- TLS_RSA_WITH_NULL_SHA256-- but there are none that give you encryption without also giving you integrity protection. You can address the comment by swapping terms, i.e. say "integrity protection and/or encryption". Dan. From dharkins@lounge.org Sun Feb 2 19:09:01 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798A91A0036; Sun, 2 Feb 2014 19:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2w4nez2vo28i; Sun, 2 Feb 2014 19:09:00 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 293F21A0032; Sun, 2 Feb 2014 19:09:00 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id E29611022400A; Sun, 2 Feb 2014 19:08:50 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 2 Feb 2014 19:08:51 -0800 (PST) Message-ID: <943e83dcb64a8666ea82900f013b2b9b.squirrel@www.trepanning.net> In-Reply-To: <1391369584.4360.72.camel@destiny.pc.cs.cmu.edu> References: <23845_1391280851_s11IsAD0008772_cd3fb9f2748d08183af6652c0d58f61a.squirrel@www.trepanning.net> <1391369584.4360.72.camel@destiny.pc.cs.cmu.edu> Date: Sun, 2 Feb 2014 19:08:51 -0800 (PST) From: "Dan Harkins" To: "Jeffrey Hutzelman" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: draft-ietf-alto-protocol.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-alto-protocol X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 03:09:01 -0000 On Sun, February 2, 2014 11:33 am, Jeffrey Hutzelman wrote: > On Sat, 2014-02-01 at 10:54 -0800, Dan Harkins wrote: > >> Also, given those >> restrictions and the fact that a tag just has to be less than >> or equal to 64 octets, the probability of identical tags being >> used is not zero. I think the probability of the tag from >> example 11.3.1.7 is 0.5 to collide with one of just 460 >> other Network Maps. >> >> I suggest requiring a tag to be 64 octets. That will make >> even money probability of collision among nearly 3000 >> other Network Maps, which is safer. > > OK, maybe I'm confused and reading out of context here. But I once had > someone tell me I needed to change my 5-character username because they > were requiring all usernames to be at least 6 characters, _in order to > increase the number of possible usernames_. That is, they claimed they > were increasing the size of a namespace by eliminating possible names. Well that's a hair brained policy, but username selection is not a good analogy. I was at a company that had no strict requirements on a username so there should have been a near infinite size of the namespace. But we had a collision when the company had less than 10 employees because there was another "dan" at the company. > The point is, if a tag is required to be exactly 64 octets, you get > 0x5e^64 possible tags. But if it is required to be up to 64 octets, you > get Sum(i=0..64) 0x5e^i possible tags, which is strictly greater than > 0x5e^64. So, requiring a tag to be 64 octets _reduces_ the number of > possible tags, thereby increasing the chance of collision. That would be the case if all tags in the Sum(i=1..64) 0x5e^i tagspace were equally probable of being chosen. Which implies implementations choosing a random tag length for each tag generated in addition to a random tag selection scheme for the randomly chosen length. I suspect, though, that in practice the tag length will be fixed for a particular implementation and the tag selection scheme will not necessarily be random. So the herd mentality, plus the proliferation of one or two companies' ALTO servers, will result in a severely reduced size of the effective tagspace and the increased possibility of collisions. A tag generated as SHA256(NetworkMap) represented in 64 hex characters would basically guarantee you'd never have a collision. Saying, "it can be anything you want as long as it's less than 64 octets" would not. Dan. From kwiereng@cisco.com Mon Feb 3 05:46:56 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3013D1A021D; Mon, 3 Feb 2014 05:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvkkOVwHjEEg; Mon, 3 Feb 2014 05:46:48 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8D91ADEB5; Mon, 3 Feb 2014 05:32:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4224; q=dns/txt; s=iport; t=1391434361; x=1392643961; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4Txnc/D/I4HPHX5ZuCnYMaeLhNQxD+igAa2C7vSIruQ=; b=PZt5+C3mJMv79kprmqUfjRZ/daF5eoEuEOXE4zc+/lkQrgu8xShhMliw 2YmwFpYWEAo47w2DUXlK5Gflxg3iX2FATxERFQLV5iTsbjdSaaG6remvb ELBi9HKuxOY/M66sEoe5SrSG1IAEqu6Z9wF740V5qrwbd/0s7XL+FOCnP U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAHGZ71KtJV2Z/2dsb2JhbABZgww4V706T4EHFnSCJQEBAQMBOj8FCwIBCBEEAQEfEDIdCAIEDgUJh3QIDcwyF44nCgEFAgEcMwIFBoMegRQElEKDaJIhgy2BaAEfIg X-IronPort-AV: E=Sophos;i="4.95,772,1384300800"; d="scan'208";a="301450472" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 03 Feb 2014 13:32:40 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s13DWeBr017018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Feb 2014 13:32:40 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.181]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Mon, 3 Feb 2014 07:32:39 -0600 From: "Klaas Wierenga (kwiereng)" To: Roni Even Thread-Topic: Secdir review of draft-ietf-p2psip-rpr-11 Thread-Index: AQHPHZxuadjFPudg1EiEZvef0HUYVpqjhjwQgABr8IA= Date: Mon, 3 Feb 2014 13:32:39 +0000 Message-ID: <9FF8C147-4F05-4A56-B36A-615858D46882@cisco.com> References: <521F1B37-7D82-485C-AA8F-624695BC5797@cisco.com> <760B7D45D1EFF74988DBF5C2122830C23E54F3CF@szxpml507-mbx.exmail.huawei.com> In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C23E54F3CF@szxpml507-mbx.exmail.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.102.158] Content-Type: text/plain; charset="us-ascii" Content-ID: <9B4808C1DD04304B9B7AA0B4841D6625@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ron.even.tlv@gmail.com" , "iesg@ietf.org" , "draft-ietf-p2psip-rpr.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-p2psip-rpr-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 13:46:56 -0000 On Feb 3, 2014, at 2:06 PM, Roni Even wrote: Hi Roni, > Thanks for the comments. > In order to use a relay, the peer need to learn who is the relevant relay= as > described in section 3.1 and 3.2 so they are not arbitrary peers, > furthermore section 4.1 says that a relay can limit the number of > connections. So what happens if a relay has reached that maximum? Doesn't that mean that= the relay has become effectively unusable? But since my SPOF comment doesn= 't seem to hold this is not much of an issue. > The relay is used for the response path. The source establish a connectio= n > to a relay known to him and if succeed send the information in the outgoi= ng > message. The response should come from the target peer. >=20 > So the general security in RFC6490 will work. The relay is not a point of > failure since this is an optional mechanism and if the communication fail= s > the routing will fall back to SRR. ah ok, the sentence "If peer A knows it is behind a NAT or NATs, and knows = one or more relay peers with whom they have a prior connections, peer A can try RPR. " in 3.1 threw me off. I missed that there was in any case an estab= lished connection from A to B. So if I now understand correctly, you are de= aling with a case in which SRR is in any case also always possible?=20 >=20 > We can add some sentence in the security section about the relay limiting > the number of connections and maybe about verifying that the connection > request for the response is from the destination peer in the outgoing > message if the relay will keep state (not recommended) I think that is useful >=20 > As for being trusted, I think you are right, the relay need to comply wit= h > the security specifications in RFC6490. ok >=20 > BTW: Sorry for not responding earlier bur this was probably since the ema= il > sent to draft-ietf-p2psip-rpr-10.all@tools.ietf.org so it did not reach u= s. arghhh, I need to say sorry here, I clearly was a bit too hasty with my cop= y/paste of the draft name! Klaas >=20 > Roni Even >=20 > ________________________________________ > From: Klaas Wierenga (kwiereng) [kwiereng@cisco.com] > Sent: Thursday, January 30, 2014 11:19 AM > To: draft-ietf-p2psip-rpr.all@tools.ietf.org > Cc: secdir@ietf.org; iesg@ietf.org > Subject: Secdir review of draft-ietf-p2psip-rpr-11 >=20 > Hi, >=20 > I reviewed earlier version 10 (http://www.ietf.org/mail-archive/web/secdi= r/current/msg04256.html), I didn't get any response and the security consid= erations don't seem to address what I wrote at that time, so I'll repeat: >=20 > -- > Hi, >=20 > I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. These = comments were written primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments just like = any other last call comments. >=20 > This document defines an optional extension to RELOAD to support Relay Pe= er Routing (RPR) mode (as opposed to Symmetric Recursive Routing (SRR). The= document is straightforward and clear, but with respect to the security co= nsiderations a few comments: >=20 > - I am surprised that there is no discussion on the relay peer being the = single (or few) point of failure, and thus becoming an interesting target = for DoS attacks: the relay peer acts as a hub for all traffic coming from t= he peers that have it as their relay. Especially when there is a limited nu= mber of relays it becomes attractive to bring the relay down. >=20 > - The other thing I wonder about is why there is the need to trust the re= lay, why is this different from the DRR case (apart from the observation in= my previous comment)? It seems that the system would work just fine withou= t the explicit trust in the relay peer, in fact, the way I understand it ev= ery peer in the overlay can in principle act as a relay peer (I imagine a s= cenario where the relay peer acts as the "established connection"). >=20 > Cheers, >=20 > Klaas Wierenga > -- >=20 From roni.even@mail01.huawei.com Mon Feb 3 06:07:09 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72AF1A01F5; Mon, 3 Feb 2014 06:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBvkz7P5edsD; Mon, 3 Feb 2014 06:07:07 -0800 (PST) Received: from hwsga02-in.huaweimarine.com (unknown [58.251.153.224]) by ietfa.amsl.com (Postfix) with ESMTP id 7111B1AD8F0; Mon, 3 Feb 2014 05:07:10 -0800 (PST) Received: from 172.24.1.80 (EHLO szxpml204-edg.exmail.huawei.com) ([172.24.1.80]) by szxrg12-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVH69315; Mon, 03 Feb 2014 21:07:03 +0800 (CST) Received: from SZXPML404-HUB.exmail.huawei.com (10.82.67.165) by szxpml204-edg.exmail.huawei.com (172.24.2.15) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Feb 2014 21:06:34 +0800 Received: from SZXPML507-MBX.exmail.huawei.com ([169.254.2.88]) by szxpml404-hub.exmail.huawei.com ([10.82.67.165]) with mapi id 14.03.0158.001; Mon, 3 Feb 2014 21:06:59 +0800 From: Roni Even To: "Klaas Wierenga (kwiereng)" , "draft-ietf-p2psip-rpr.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-p2psip-rpr-11 Thread-Index: AQHPHZxuadjFPudg1EiEZvef0HUYVpqjhjwQ Date: Mon, 3 Feb 2014 13:06:58 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C23E54F3CF@szxpml507-mbx.exmail.huawei.com> References: <521F1B37-7D82-485C-AA8F-624695BC5797@cisco.com> In-Reply-To: <521F1B37-7D82-485C-AA8F-624695BC5797@cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 03 Feb 2014 06:08:28 -0800 Cc: "ron.even.tlv@gmail.com" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-p2psip-rpr-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 14:07:10 -0000 Hi, Thanks for the comments. In order to use a relay, the peer need to learn who is the relevant relay a= s described in section 3.1 and 3.2 so they are not arbitrary peers, furthermore section 4.1 says that a relay can limit the number of connections. The relay is used for the response path. The source establish a connection to a relay known to him and if succeed send the information in the outgoing message. The response should come from the target peer. So the general security in RFC6490 will work. The relay is not a point of failure since this is an optional mechanism and if the communication fails the routing will fall back to SRR. We can add some sentence in the security section about the relay limiting the number of connections and maybe about verifying that the connection request for the response is from the destination peer in the outgoing message if the relay will keep state (not recommended) As for being trusted, I think you are right, the relay need to comply with the security specifications in RFC6490. BTW: Sorry for not responding earlier bur this was probably since the email sent to draft-ietf-p2psip-rpr-10.all@tools.ietf.org so it did not reach us. Roni Even ________________________________________ From: Klaas Wierenga (kwiereng) [kwiereng@cisco.com] Sent: Thursday, January 30, 2014 11:19 AM To: draft-ietf-p2psip-rpr.all@tools.ietf.org Cc: secdir@ietf.org; iesg@ietf.org Subject: Secdir review of draft-ietf-p2psip-rpr-11 Hi, I reviewed earlier version 10 (http://www.ietf.org/mail-archive/web/secdir/= current/msg04256.html), I didn't get any response and the security consider= ations don't seem to address what I wrote at that time, so I'll repeat: -- 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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document defines an optional extension to RELOAD to support Relay Peer= Routing (RPR) mode (as opposed to Symmetric Recursive Routing (SRR). The d= ocument is straightforward and clear, but with respect to the security cons= iderations a few comments: - I am surprised that there is no discussion on the relay peer being the si= ngle (or few) point of failure, and thus becoming an interesting target fo= r DoS attacks: the relay peer acts as a hub for all traffic coming from the= peers that have it as their relay. Especially when there is a limited numb= er of relays it becomes attractive to bring the relay down. - The other thing I wonder about is why there is the need to trust the rela= y, why is this different from the DRR case (apart from the observation in m= y previous comment)? It seems that the system would work just fine without = the explicit trust in the relay peer, in fact, the way I understand it ever= y peer in the overlay can in principle act as a relay peer (I imagine a sce= nario where the relay peer acts as the "established connection"). Cheers, Klaas Wierenga -- From benl@google.com Mon Feb 3 09:50:27 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F451A01DA for ; Mon, 3 Feb 2014 09:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 453jtx7VaepU for ; Mon, 3 Feb 2014 09:50:26 -0800 (PST) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 08E381A01C9 for ; Mon, 3 Feb 2014 09:50:25 -0800 (PST) Received: by mail-vc0-f175.google.com with SMTP id ij19so4906976vcb.6 for ; Mon, 03 Feb 2014 09:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=p7MK6Sw9aCrjAVOOv710wc55vtwZnfhsGiGEAbSDfhY=; b=OK1dCJ8nDvOM3YruGU5V8q8XHXY/PPpOUO915D3VJFzPQPzCyiHJ+E/LLGHWso1nX2 7GHS76ZQpRQLYQCgCnQi5HKhFdjnKc8QocG39vUHYSrch53eMgDggifsmVZO2seQuYEp zctn34aSjYXP5j4OGsLpPmWARPbZfb0J/V7zJFCYhfPMTwRZaygLfR8QYpZxce1SFcBN EfDewN+OGk5wYMwfZ4WJKpkrX6ZmdvjVzeujRyj6MzsX2Nj+DU3eTY0Aq0SxCp2GJxeK GBV7F1Jzedbl9qr1ftVQLrEbhCn3qNaeviJA1KecdwfjWIMIk5QlOM1DYKzk35S0pbDQ PNCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=p7MK6Sw9aCrjAVOOv710wc55vtwZnfhsGiGEAbSDfhY=; b=dP4LAAmhHUfvYGbsvcX9jWOWdeI8Fp4c/mhnqbZpZ5F6vrYKNfmxDOa9DVSPW7Mvih 4RQ+z83qcmbzI/de0nkLdaTAL75qrzVKQGxQKdcBh1a1OTc4udEqihLYNCirO8yV9Ost 4oeGUjRGBGs0Xn2mpS1S/zgup5iFaB2/UoIoRe/C20kvmEjxJNq57feJYqC6+5biGlq5 JYcdHXce3Z4LvqoBMLZEj0iduoXTayM8S2HQMBAmAjBIUi8POQukOjcPVC3CNaXfadM3 Up0399aq3XdnT2RWJWIs7FyrgFd77YcRGPj27oyxw84eS/kSvJAigEUfcQ0rIn8NzPOZ GiFg== X-Gm-Message-State: ALoCoQl9/PUisR+lrVbp0fKfCodA19WH6XkgpLO3/HCdY5BYT79E9P3p/gGvPzN4MNXNYqfItZAAJ4lojlXVlWeJGbzeR3SATux/mdiGmcWuhQOeExvISt3I0y3M3xUdk0Zc9fjdf6R0bDwCx5KJgH+K9OYsaKr9EWVEaOqRHi1F3x3Ys2y0qLm6BElzLdfiqIbh1azXz8/q MIME-Version: 1.0 X-Received: by 10.220.58.202 with SMTP id i10mr2623581vch.23.1391449825545; Mon, 03 Feb 2014 09:50:25 -0800 (PST) Received: by 10.52.230.105 with HTTP; Mon, 3 Feb 2014 09:50:25 -0800 (PST) Date: Mon, 3 Feb 2014 17:50:25 +0000 Message-ID: From: Ben Laurie To: The IESG , "secdir@ietf.org" , draft-ietf-stox-presence.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [secdir] sec-dir review of draft-ietf-stox-presence-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 17:50:27 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: ready with nits Detail: the I-D documents a mapping between two fairly well-matched presence protocols, and hence does not introduce much danger. The one area of concern is that SIP presence subscriptions are short-lived and XMPP's are long-lived, thus opening the possibility of an amplification attack against SIP via XMPP. The suggested mitigation is weak: "To help prevent such an attack, access to an XMPP- SIP gateway that is hosted on the XMPP network SHOULD be restricted to XMPP users associated with a single domain or trust realm (e.g., a gateway hosted at simple.example.com ought to allow only users within the example.com domain to access the gateway, not users within example.org, example.net, or any other domain)" Many XMPP servers allow open registration and so this defence is no defence at all in that case. Perhaps some kind of rate limitation would be useful? Also, this part: "Furthermore, whenever an XMPP-SIP gateway seeks to refresh an XMPP user's long-lived subscription to a SIP user's presence, it MUST first send an XMPP stanza of type "probe" from the address of the gateway to the "bare JID" (user@domain.tld) of the XMPP user, to which the user's XMPP server MUST respond in accordance with [RFC6121]; however, the administrator of an XMPP-SIP gateway MAY (based on local service provisioning) exempt "known good" XMPP servers from this check (e.g., the XMPP server associated with the XMPP-SIP gateway as described above)." is unclear: how does it help? From kent@bbn.com Mon Feb 3 13:06:25 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2BC1A01DA for ; Mon, 3 Feb 2014 13:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVgmeJipoG4J for ; Mon, 3 Feb 2014 13:06:21 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 03BBD1A015A for ; Mon, 3 Feb 2014 13:06:20 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:48610 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WAQib-000F5H-VE; Mon, 03 Feb 2014 16:06:15 -0500 Message-ID: <52F004B7.5080909@bbn.com> Date: Mon, 03 Feb 2014 16:05:59 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: secdir , curtis@occnc.com, kireeti@juniper.net, samante@apple.com, agmalis@gmail.com, cpignata@cisco.com, Stewart Bryant , Adrian Farrel , Loa Andersson , rcallon@juniper.net, swallow@cisco.com Content-Type: multipart/alternative; boundary="------------080800000307000501000302" Subject: [secdir] SECDIR review of draft-ietf-mpls-forwarding-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 21:06:25 -0000 This is a multi-part message in MIME format. --------------080800000307000501000302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit SECDIR review of draft-ietf-mpls-forwarding-06 I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments. This documentis a candidate Informational RFC. It cites about 25 MPLS RFCs (normatively) as a basis for guidelines for MPLS router implementers and network providers, with respect to forwarding of MPLS traffic. The Security Considerations Section is very brief. It correctly states that it is a review of forwarding behavior specified in numerous MPLS RFCs, and thus introduces no new security requirements. It makes specific reference to Section 4.6, which specifies (at a high level) some tests for DoS susceptibility in MPLS routers. The paragraph that includes this reference should be extended to include pointers to Section 2.6.1 (which discusses DoS concerns), and to Section 3.6 (which includes a list of DoS protection questions to be posed to suppliers). It might be nice to summarize the security considerations recommendations from the MPLS RFCs that are normative references in this document. Since this document is a summary of forwarding-relevant requirements from these documents, plus practical advice, such a summary would be useful here, and fitting. Some suggested edits: 2.1.2.MPLS Differentiated Services [RFC2474] deprecates the IP Type of Service (TOS) and IP Precedence (Prec) fields and replaces them with the Differentiated Services Field more commonly known as the Differentiated Services Code Point (DSCP) field.[RFC2475] defines the Differentiated Services architecture, which in other forum is often called a Quality of Service (QoS) architecture. Either use "fora" (correct Latin) or "forums" (common English) 2.1.8.1.Pseudowire Sequence Number Pseudowire (PW) sequence number support is most important for PW payload types with a high expectation of lossless and/or in-order delivery.Identifying lost PW packets and exact amount of lost payload is critical for PW services which maintain bit timing, such as Time Division Multiplexing (TDM) services since these services MUST compensate lost payload on a bit-for-bit basis. "the exact amount" With PW services which maintain bit timing, packets that have been received out of order also MUST be identified and may be either re- ordered or dropped. Uppercase MAY? The term "microflow" does not appear to be defined anywhere in this document, but is used a number of times. I suggest including the definition from RFC 2474. 2.4.4.MPLS Entropy Label The MPLS entropy label simplifies flow group identification [RFC6790] at midpoint LSR.Prior to the MPLS entropy label midpoint LSR needed to inspect the entire label stack and often the IP headers to provide ... Missing an article, or make LSR plural. Many service providers consider it a hard requirement that use of UDP and TCP ports can be disabled.Therefore there is a stong incentive for implementations to provide both options. "strong" Cryptographic authentication can is some circumstances be subject to DoS attack by overwhelming the capacity of the decryption with a high volume of malicious traffic. "in" --------------080800000307000501000302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

 

SECDIR review of draft-ietf-mpls-forwarding-06

 

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

 

This document is a candidate Informational RFC. It cites about 25 MPLS RFCs (normatively) as a basis for guidelines for MPLS router implementers and network providers, with respect to forwarding of MPLS traffic.

 

The Security Considerations Section is very brief. It correctly states that it is a review of forwarding behavior specified in numerous MPLS RFCs, and thus introduces no new security requirements. It makes specific reference to Section 4.6, which specifies (at a high level) some tests for DoS susceptibility in MPLS routers. The paragraph that includes this reference should be extended to include pointers to Section 2.6.1 (which discusses DoS concerns), and to Section 3.6 (which includes a list of DoS protection questions to be posed to suppliers).

 

It might be nice to summarize the security considerations recommendations from the MPLS RFCs that are normative references in this document. Since this document is a summary of forwarding-relevant requirements from these documents, plus practical advice, such a summary would be useful here, and fitting.

 

Some suggested edits:

 

2.1.2.  MPLS Differentiated Services

 

   [RFC2474] deprecates the IP Type of Service (TOS) and IP Precedence

   (Prec) fields and replaces them with the Differentiated Services

   Field more commonly known as the Differentiated Services Code Point

   (DSCP) field.  [RFC2475] defines the Differentiated Services

   architecture, which in other forum is often called a Quality of

   Service (QoS) architecture.

 

Either use “fora” (correct Latin) or “forums” (common English)

 

2.1.8.1.  Pseudowire Sequence Number

 

   Pseudowire (PW) sequence number support is most important for PW

   payload types with a high expectation of lossless and/or in-order

   delivery.  Identifying lost PW packets and exact amount of lost

   payload is critical for PW services which maintain bit timing, such

   as Time Division Multiplexing (TDM) services since these services

   MUST compensate lost payload on a bit-for-bit basis.

 

“the exact amount”

 

 

With PW services which maintain bit timing, packets that have been

   received out of order also MUST be identified and may be either re-

   ordered or dropped.

 

Uppercase MAY?

 

The term “microflow” does not appear to be defined anywhere in this document, but is used a number of times. I suggest including the definition from RFC 2474.

 

2.4.4.  MPLS Entropy Label

 

   The MPLS entropy label simplifies flow group identification [RFC6790] at midpoint LSR.  Prior to the MPLS entropy label midpoint LSR needed  to inspect the entire label stack and often the IP headers to provide …

 

Missing an article, or make LSR plural.

 

Many service providers consider it a hard requirement

that use of UDP and TCP ports can be disabled.  Therefore there is a stong incentive for implementations to provide both options.

 

“strong”

 

Cryptographic authentication can is some circumstances be subject

to DoS attack by overwhelming the capacity of the decryption with

a high volume of malicious traffic.

 

“in”

--------------080800000307000501000302-- From ietfdbh@comcast.net Mon Feb 3 18:54:59 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF551A0355 for ; Mon, 3 Feb 2014 18:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sRVJD1lvUa6 for ; Mon, 3 Feb 2014 18:54:57 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 3225E1A0353 for ; Mon, 3 Feb 2014 18:54:57 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta02.westchester.pa.mail.comcast.net with comcast id N2Fg1n0031vXlb8512uw1a; Tue, 04 Feb 2014 02:54:56 +0000 Received: from [192.168.253.239] ([64.192.52.34]) by omta17.westchester.pa.mail.comcast.net with comcast id N2uc1n0050kGrnC3d2ufwJ; Tue, 04 Feb 2014 02:54:54 +0000 From: David Harrington Content-Type: multipart/alternative; boundary="Apple-Mail=_361D9D53-A3EE-430F-8FE0-EA5949C7D816" Date: Mon, 3 Feb 2014 21:54:34 -0500 To: draft-ietf-avtext-rtp-duplication.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Message-Id: <6BE7194C-1E4F-46AB-B3E1-082A05579B4F@comcast.net> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391482496; bh=tisqhm2UdnmADLKJAiw6DhL9fzZqWKC2kS4YW2fXdlw=; h=Received:Received:From:Content-Type:Date:Subject:To:Message-Id: Mime-Version; b=nEztninNfLODNe480SeZzLfu6e/VJV3TJMtNwmBs4ru75l7ZusuTg1R/IqbzL2MTR bFRRBKRU1NWZyTxy/CUYx9kE9d99leDq7rzIGVL9zCSYzZBNhlpvVQ2xu9Z2EPKKhU oakP/2EiDxJQ71KYJ+n45k442axCTfHBLN5B2fxeFDl2OcUl2wns0hVVIFwQH+53JY OPiZh49x4gTXfhZlu9fvxw+UDSPl38kO2RXyIVdGhsVpnFwn5RV5lvGJnP3VegNLhK 6zUaD9rWTVCJY2dg8llcjwOWAOT4CO8NIqwkCpYYWsHEM/tBQgABO07OlxbRZUjDHV ksYnMfFMiH97w== Subject: [secdir] secdr review of draft-ietf-avtext-rtp-duplication X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 02:54:59 -0000 --Apple-Mail=_361D9D53-A3EE-430F-8FE0-EA5949C7D816 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. =46rom a security perspective, I believe this draft is Ready for = publication. Comments: I am not an expert is RTP, RTCP, and related protocols. I assume this is = a valid extension based largely on the authorship by Ali Begen, and = suggestions by Magnus Westerlund. I have a concern with section 3.4, which lists two states that are = REQUIRED to exist for this specification, and then discusses that other = approaches could work but would require an additional specification. = Doesn't that make this appropriate for SHOULD rather than REQUIRED = terminology? in section 4.2, "We require =85"; does the protocol specification = REQUIRE this? s/section section/section/ David Harrington ietfdbh@comcast.net --Apple-Mail=_361D9D53-A3EE-430F-8FE0-EA5949C7D816 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 
I have reviewed this =
document as part of the security directorate's=20
ongoing effort to review all IETF documents being processed by the=20
IESG.  These comments were written primarily for the benefit of the=20
security area directors.  Document editors and WG chairs should treat=20
these comments just like any other last call =
comments.

=46rom a security perspective, I = believe this draft is Ready for = publication.

Comments:
I am not an = expert is RTP, RTCP, and related protocols. I assume this is a valid = extension based largely on the authorship by Ali Begen, and suggestions = by Magnus Westerlund.

I have a concern with = section 3.4, which lists two states that are REQUIRED to exist for this = specification, and then discusses that other approaches could work but = would require an additional specification. Doesn't that make this = appropriate for SHOULD rather than REQUIRED = terminology?

in section 4.2, "We require =85"; = does the protocol specification REQUIRE = this?

s/section = section/section/

David Harrington

=

= --Apple-Mail=_361D9D53-A3EE-430F-8FE0-EA5949C7D816-- From csp@csperkins.org Tue Feb 4 10:05:14 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEFA1A0155; Tue, 4 Feb 2014 10:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKPcMS55tnsf; Tue, 4 Feb 2014 10:05:12 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DE61A0135; Tue, 4 Feb 2014 10:05:12 -0800 (PST) Received: from [130.209.247.112] (port=56241 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WAkMu-00088b-Lv; Tue, 04 Feb 2014 18:05:09 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Colin Perkins In-Reply-To: <6BE7194C-1E4F-46AB-B3E1-082A05579B4F@comcast.net> Date: Tue, 4 Feb 2014 18:05:20 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <90488B49-3048-4D96-A0D6-D5BB249C868A@csperkins.org> References: <6BE7194C-1E4F-46AB-B3E1-082A05579B4F@comcast.net> To: David Harrington X-Mailer: Apple Mail (2.1827) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = X-Mailman-Approved-At: Tue, 04 Feb 2014 10:14:15 -0800 Cc: secdir@ietf.org, The IESG , draft-ietf-avtext-rtp-duplication.all@tools.ietf.org Subject: Re: [secdir] secdr review of draft-ietf-avtext-rtp-duplication X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 18:05:14 -0000 On 4 Feb 2014, at 02:54, David Harrington wrote: > I have reviewed this document as part of the security directorate's=20 > ongoing effort to review all IETF documents being processed by the=20 > IESG. These comments were written primarily for the benefit of the=20 > security area directors. Document editors and WG chairs should treat=20= > these comments just like any other last call comments. >=20 >=20 > =46rom a security perspective, I believe this draft is Ready for = publication. >=20 > Comments: > I am not an expert is RTP, RTCP, and related protocols. I assume this = is a valid extension based largely on the authorship by Ali Begen, and = suggestions by Magnus Westerlund. >=20 > I have a concern with section 3.4, which lists two states that are = REQUIRED to exist for this specification, and then discusses that other = approaches could work but would require an additional specification. = Doesn=92t that make this appropriate for SHOULD rather than REQUIRED = terminology? The intent is to say, =93You are currently required to do X or Y, but = future extensions to this specification may relax condition Y given = appropriate signalling=94. We can try to clarify, if that=92s not clear. > in section 4.2, "We require =85"; does the protocol specification = REQUIRE this? Changing =93We require out-of-band signalling=94 to =93Out-of-band = signalling is needed=94 would cover the intended meaning, and avoid the = potential confusion. --=20 Colin Perkins http://csperkins.org/ From stpeter@stpeter.im Tue Feb 4 19:11:34 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BACC1A000C; Tue, 4 Feb 2014 19:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2xhBZg42wHF; Tue, 4 Feb 2014 19:11:31 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BD5961A0013; Tue, 4 Feb 2014 19:11:31 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D51EC4032A; Tue, 4 Feb 2014 20:11:30 -0700 (MST) Message-ID: <52F1ABE1.4000805@stpeter.im> Date: Tue, 04 Feb 2014 20:11:29 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ben Laurie , The IESG , "secdir@ietf.org" , draft-ietf-stox-presence.all@tools.ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [secdir] sec-dir review of draft-ietf-stox-presence-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 03:11:34 -0000 Hi Ben, thanks for the review. Comments inline. On 2/3/14, 10:50 AM, Ben Laurie wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Summary: ready with nits > > Detail: the I-D documents a mapping between two fairly well-matched > presence protocols, and hence does not introduce much danger. The one > area of concern is that SIP presence subscriptions are short-lived and > XMPP's are long-lived, thus opening the possibility of an > amplification attack against SIP via XMPP. > > The suggested mitigation is weak: > > "To help prevent such an attack, access to an XMPP- > SIP gateway that is hosted on the XMPP network SHOULD be restricted > to XMPP users associated with a single domain or trust realm (e.g., a > gateway hosted at simple.example.com ought to allow only users within > the example.com domain to access the gateway, not users within > example.org, example.net, or any other domain)" > > Many XMPP servers allow open registration and so this defence is no > defence at all in that case. Don't allow open registration. :-) Further, I think it would be irresponsible to offer a generalized gateway for use by any domain, so the foregoing text might be misleading. > Perhaps some kind of rate limitation > would be useful? All self-respecting XMPP servers include rate limiting, but it's unclear whether that would really help much in practice since you don't any sort of amplification in order to attack users at another domain even in the absence of a gateway (just normal XMPP server-to-server will do). > Also, this part: > > "Furthermore, whenever an XMPP-SIP gateway seeks to refresh > an XMPP user's long-lived subscription to a SIP user's presence, it > MUST first send an XMPP stanza of type "probe" from the > address of the gateway to the "bare JID" (user@domain.tld) of the > XMPP user, to which the user's XMPP server MUST respond in accordance > with [RFC6121]; however, the administrator of an XMPP-SIP gateway MAY > (based on local service provisioning) exempt "known good" XMPP > servers from this check (e.g., the XMPP server associated with the > XMPP-SIP gateway as described above)." > > is unclear: how does it help? This check at least places a burden on the XMPP server itself and verifies if the XMPP user has an active presence session before updating the presence subscription on the SIP side of the gateway. I'll think about the matter more deeply and formulate some better text. Peter -- Peter Saint-Andre https://stpeter.im/ From curtis@ipv6.occnc.com Tue Feb 4 20:18:00 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E681A002F for ; Tue, 4 Feb 2014 20:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVXE777OjN6g for ; Tue, 4 Feb 2014 20:17:55 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 642C31A002E for ; Tue, 4 Feb 2014 20:17:54 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s154HcTt094007; Tue, 4 Feb 2014 23:17:38 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201402050417.s154HcTt094007@maildrop2.v6ds.occnc.com> To: Stephen Kent From: Curtis Villamizar In-reply-to: Your message of "Mon, 03 Feb 2014 16:05:59 -0500." <52F004B7.5080909@bbn.com> Date: Tue, 04 Feb 2014 23:17:38 -0500 Cc: swallow@cisco.com, samante@apple.com, cpignata@cisco.com, kireeti@juniper.net, secdir , agmalis@gmail.com, curtis@occnc.com, rcallon@juniper.net, Adrian Farrel , Loa Andersson , Stewart Bryant Subject: Re: [secdir] SECDIR review of draft-ietf-mpls-forwarding-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 04:18:00 -0000 Steve, Thanks for providing this review. Responses are inline. In message <52F004B7.5080909@bbn.com> Stephen Kent writes: > > SECDIR review of draft-ietf-mpls-forwarding-06 > > I reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG.These > comments were written primarily for the benefit of the security area > directors.Document editors, WG chairs and ADs should treat these > comments just like any other last call comments. > > This documentis a candidate Informational RFC. It cites about 25 MPLS > RFCs (normatively) as a basis for guidelines for MPLS router > implementers and network providers, with respect to forwarding of MPLS > traffic. > > The Security Considerations Section is very brief. It correctly states > that it is a review of forwarding behavior specified in numerous MPLS > RFCs, and thus introduces no new security requirements. It makes > specific reference to Section 4.6, which specifies (at a high level) > some tests for DoS susceptibility in MPLS routers. The paragraph that > includes this reference should be extended to include pointers to > Section 2.6.1 (which discusses DoS concerns), and to Section 3.6 (which > includes a list of DoS protection questions to be posed to suppliers). Proposed change: OLD Some advice on hardware support and other equipment hardening against DoS attack can be found in Section 4.6. NEW Discussion of hardware support and other equipment hardening against DoS attack can be found in Section 2.6.1. Section 3.6 provides a list of question regarding DoS to be asked of suppliers. Section 4.6 suggests types of testing that can provide some assurance of the effectiveness of supplier DoS hardening claims. The original reference to 4.6 was intended to refer to 2.6.1 but wrong xml2rfc anchor was used. Thanks for pointing out that DoS is mentioned in three places. > It might be nice to summarize the security considerations > recommendations from the MPLS RFCs that are normative references in this > document. Since this document is a summary of forwarding-relevant > requirements from these documents, plus practical advice, such a summary > would be useful here, and fitting. That would be quite a task and largely out of scope since many of the documents deal with a larger issue that MPLS forwarding. Most security concerns wrt MPLS or most protocols have to do with the control protocols rather than the forwarding requirements. Regardless, here is a suggested addition: NEW The set of normative references each contain security considerations. A brief summarization of MPLS security considerations applicable to forwarding follows: 1. MPLS encapsulation does not support an authentication extension. This is reflected in the security section of [RFC3032]. Documents which clarify MPLS header fields such as TTL [RFC3443], the explicit null label [RFC4182], renaming EXP to TC [RFC5462], ECN for MPLS [RFC5129], MPLS Ethernet encapsulation [RFC5332] make no changes to security considerations in [RFC3032]. 2. Some cited RFCs are related to Diffserv forwarding. [RFC3270] refers to MPLS and Diffserv security. [RFC2474] mentions theft of service and denial of service due to mismarking. [RFC2474] mentions IPsec interaction, but with MPLS, not being carried by IP, this type of interaction in [RFC2474] is not relevant. 3. [RFC3209] is cited here due only to make-before-break forwarding requirements. This is related to resource sharing and the theft of service and denial of service concerns in [RFC2474] apply. 4. [RFC4090] defines FRR which provides protection but does not add security concerns. RFC4201 defines link bundling but raises no additional security concerns. 5. Various OAM control channels are defined in [RFC4385] (PW CW), [RFC5085] (VCCV), [RFC5586] (G-Ach and GAL). These documents describe potential abuse of these OAM control channels. 6. [RFC4950] defines ICMP extensions when MPLS TTL expires and payload is IP. This provides MPLS header information which is of no use to an IP attacker, but sending this information can be suppressed through configuration. 7. GTSM [RFC5082] provides a means to improve protection against high traffic volume spoofing as a form of DoS attack. 8. BFD [RFC5880][RFC5884][RFC5885] provides a form of OAM used in MPLS and MPLS-TP. The security considerations related to the OAM control channel are relevant. The BFD payload supports authentication unlike the MPLS encapsulation or MPLS or PW control channel encapsulation is carried in. Where an IP return OAM path is used IPsec is suggested as a means of securing the return path. 9. Other forms of OAM are supported by [RFC6374][RFC6375] (Loss and Delay Measurement), [RFC6428] (Connectivity Check/Verification based on BFD), and [RFC6427] (Fault Management). The security considerations related to the OAM control channel are relevant. IP return paths, where used, can be secured with IPsec. 10. Linear protection is defined by [RFC6378] and updated by [draft-ietf-mpls-psc-updates]. Security concerns related to MPLS encapsulation and OAM control channels apply. Security concerns reiterate [RFC5920] as applied to protection switching. 11. The PW Flow Label [RFC6391] and MPLS Entropy Label [RFC6790] affect multipath load balancing. Security concerns reiterate [RFC5920]. Security impacts would be limited to load distribution. MPLS security including data plane security is discussed in greater detail in [RFC5920] (MPLS/GMPLS Security Framework). Note: RFC6720 (GTSM for LDP) was misclassified as normative. It is not normative wrt MPLS forwarding. I'll add this if you think it adds value to the document. > Some suggested edits: > > 2.1.2. MPLS Differentiated Services > > > [RFC2474] deprecates the IP Type of Service (TOS) and IP Precedence > (Prec) fields and replaces them with the Differentiated Services > Field more commonly known as the Differentiated Services Code Point > (DSCP) field. [RFC2475] defines the Differentiated Services > architecture, which in other forum is often called a Quality of > Service (QoS) architecture. > > Either use "fora" (correct Latin) or "forums" (common English) OK. forums. > 2.1.8.1. Pseudowire Sequence Number > > > Pseudowire (PW) sequence number support is most important for PW > payload types with a high expectation of lossless and/or in-order > delivery. Identifying lost PW packets and exact amount of lost > payload is critical for PW services which maintain bit timing, such > as Time Division Multiplexing (TDM) services since these services > MUST compensate lost payload on a bit-for-bit basis. > > "the exact amount" OK. > With PW services which maintain bit timing, packets that have been > > received out of order also MUST be identified and may be either > re-ordered or dropped. > > Uppercase MAY? OK. > The term "microflow" does not appear to be defined anywhere in this > document, but is used a number of times. I suggest including the > definition from RFC 2474. The first occurance of microflow is in "within a common microflow SHOULD NOT be reordered [RFC2474]". Since this references RFC2474, I think this is adequate. Other uses refer back to this section and/or cite RFC2474 and/or RFC2475. > 2.4.4. MPLS Entropy Label > > The MPLS entropy label simplifies flow group identification > [RFC6790] at midpoint LSR. Prior to the MPLS entropy label > midpoint LSR needed to inspect the entire label stack and often the > IP headers to provide ... > > Missing an article, or make LSR plural. In both occurances above plus one additional in this paragraph: s/midpoint LSR/midpoint LSRs/ > Many service providers consider it a hard requirement that use of > UDP and TCP ports can be disabled. Therefore there is a stong > incentive for implementations to provide both options. > > "strong" OK > Cryptographic authentication can is some circumstances be subject > to DoS attack by overwhelming the capacity of the decryption with a > high volume of malicious traffic. > > "in" s/can is some/can in some/ Please let me know if these changes address your comments adequately. Thanks, Curtis From loa@pi.nu Tue Feb 4 20:34:51 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E540C1A0021 for ; Tue, 4 Feb 2014 20:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKCrBjNQA7fn for ; Tue, 4 Feb 2014 20:34:48 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 337121A0020 for ; Tue, 4 Feb 2014 20:34:48 -0800 (PST) Received: from [192.168.1.3] (unknown [119.95.156.119]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id DF0751802AAF; Wed, 5 Feb 2014 05:34:43 +0100 (CET) Message-ID: <52F1BF5C.9040604@pi.nu> Date: Wed, 05 Feb 2014 12:34:36 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com, Stephen Kent References: <201402050417.s154HcTt094007@maildrop2.v6ds.occnc.com> In-Reply-To: <201402050417.s154HcTt094007@maildrop2.v6ds.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: swallow@cisco.com, samante@apple.com, cpignata@cisco.com, kireeti@juniper.net, secdir , agmalis@gmail.com, curtis@occnc.com, rcallon@juniper.net, Adrian Farrel , Stewart Bryant Subject: Re: [secdir] SECDIR review of draft-ietf-mpls-forwarding-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 04:34:52 -0000 Curtis, I had started a mail for this thread suggesting that you add a reference to RFC 5920. I thought that that should be enough, but since you have added the 11 bullets (all good) I think this is more than meet what is required for this draft. Now, Stephen's idea to document the security aspects of MPLS forwarding is not bad; but it would require that we had someone sec savvy person to work with someone that understand MPLS forwarding. If Stephen (or one of the security ADs) can help find the security person, we can work to find the forwarding person. /Loa On 2014-02-05 12:17, Curtis Villamizar wrote: > Steve, > > Thanks for providing this review. Responses are inline. > > In message <52F004B7.5080909@bbn.com> > Stephen Kent writes: >> >> SECDIR review of draft-ietf-mpls-forwarding-06 >> >> I reviewed this document as part of the security directorate's ongoing >> effort to review all IETF documents being processed by the IESG.These >> comments were written primarily for the benefit of the security area >> directors.Document editors, WG chairs and ADs should treat these >> comments just like any other last call comments. >> >> This documentis a candidate Informational RFC. It cites about 25 MPLS >> RFCs (normatively) as a basis for guidelines for MPLS router >> implementers and network providers, with respect to forwarding of MPLS >> traffic. >> >> The Security Considerations Section is very brief. It correctly states >> that it is a review of forwarding behavior specified in numerous MPLS >> RFCs, and thus introduces no new security requirements. It makes >> specific reference to Section 4.6, which specifies (at a high level) >> some tests for DoS susceptibility in MPLS routers. The paragraph that >> includes this reference should be extended to include pointers to >> Section 2.6.1 (which discusses DoS concerns), and to Section 3.6 (which >> includes a list of DoS protection questions to be posed to suppliers). > > Proposed change: > > OLD > > Some advice on hardware support and other equipment hardening > against DoS attack can be found in Section 4.6. > > NEW > > Discussion of hardware support and other equipment hardening > against DoS attack can be found in Section 2.6.1. Section 3.6 > provides a list of question regarding DoS to be asked of suppliers. > Section 4.6 suggests types of testing that can provide some > assurance of the effectiveness of supplier DoS hardening claims. > > The original reference to 4.6 was intended to refer to 2.6.1 but wrong > xml2rfc anchor was used. Thanks for pointing out that DoS is > mentioned in three places. > >> It might be nice to summarize the security considerations >> recommendations from the MPLS RFCs that are normative references in this >> document. Since this document is a summary of forwarding-relevant >> requirements from these documents, plus practical advice, such a summary >> would be useful here, and fitting. > > That would be quite a task and largely out of scope since many of the > documents deal with a larger issue that MPLS forwarding. Most > security concerns wrt MPLS or most protocols have to do with the > control protocols rather than the forwarding requirements. > Regardless, here is a suggested addition: > > NEW > > The set of normative references each contain security > considerations. A brief summarization of MPLS security > considerations applicable to forwarding follows: > > 1. MPLS encapsulation does not support an authentication > extension. This is reflected in the security section of > [RFC3032]. Documents which clarify MPLS header fields such as > TTL [RFC3443], the explicit null label [RFC4182], renaming EXP > to TC [RFC5462], ECN for MPLS [RFC5129], MPLS Ethernet > encapsulation [RFC5332] make no changes to security > considerations in [RFC3032]. > > 2. Some cited RFCs are related to Diffserv forwarding. [RFC3270] > refers to MPLS and Diffserv security. [RFC2474] mentions theft > of service and denial of service due to mismarking. [RFC2474] > mentions IPsec interaction, but with MPLS, not being carried by > IP, this type of interaction in [RFC2474] is not relevant. > > 3. [RFC3209] is cited here due only to make-before-break > forwarding requirements. This is related to resource sharing > and the theft of service and denial of service concerns in > [RFC2474] apply. > > 4. [RFC4090] defines FRR which provides protection but does not > add security concerns. RFC4201 defines link bundling but > raises no additional security concerns. > > 5. Various OAM control channels are defined in [RFC4385] (PW CW), > [RFC5085] (VCCV), [RFC5586] (G-Ach and GAL). These documents > describe potential abuse of these OAM control channels. > > 6. [RFC4950] defines ICMP extensions when MPLS TTL expires and > payload is IP. This provides MPLS header information which is > of no use to an IP attacker, but sending this information can > be suppressed through configuration. > > 7. GTSM [RFC5082] provides a means to improve protection against > high traffic volume spoofing as a form of DoS attack. > > 8. BFD [RFC5880][RFC5884][RFC5885] provides a form of OAM used in > MPLS and MPLS-TP. The security considerations related to the > OAM control channel are relevant. The BFD payload supports > authentication unlike the MPLS encapsulation or MPLS or PW > control channel encapsulation is carried in. Where an IP > return OAM path is used IPsec is suggested as a means of > securing the return path. > > 9. Other forms of OAM are supported by [RFC6374][RFC6375] (Loss > and Delay Measurement), [RFC6428] (Connectivity > Check/Verification based on BFD), and [RFC6427] (Fault > Management). The security considerations related to the OAM > control channel are relevant. IP return paths, where used, can > be secured with IPsec. > > 10. Linear protection is defined by [RFC6378] and updated by > [draft-ietf-mpls-psc-updates]. Security concerns related to > MPLS encapsulation and OAM control channels apply. Security > concerns reiterate [RFC5920] as applied to protection > switching. > > 11. The PW Flow Label [RFC6391] and MPLS Entropy Label [RFC6790] > affect multipath load balancing. Security concerns reiterate > [RFC5920]. Security impacts would be limited to load > distribution. > > MPLS security including data plane security is discussed in greater > detail in [RFC5920] (MPLS/GMPLS Security Framework). > > Note: RFC6720 (GTSM for LDP) was misclassified as normative. It is > not normative wrt MPLS forwarding. > > I'll add this if you think it adds value to the document. > >> Some suggested edits: >> >> 2.1.2. MPLS Differentiated Services >> >> >> [RFC2474] deprecates the IP Type of Service (TOS) and IP Precedence >> (Prec) fields and replaces them with the Differentiated Services >> Field more commonly known as the Differentiated Services Code Point >> (DSCP) field. [RFC2475] defines the Differentiated Services >> architecture, which in other forum is often called a Quality of >> Service (QoS) architecture. >> >> Either use "fora" (correct Latin) or "forums" (common English) > > OK. forums. > >> 2.1.8.1. Pseudowire Sequence Number >> >> >> Pseudowire (PW) sequence number support is most important for PW >> payload types with a high expectation of lossless and/or in-order >> delivery. Identifying lost PW packets and exact amount of lost >> payload is critical for PW services which maintain bit timing, such >> as Time Division Multiplexing (TDM) services since these services >> MUST compensate lost payload on a bit-for-bit basis. >> >> "the exact amount" > > OK. > >> With PW services which maintain bit timing, packets that have been >> >> received out of order also MUST be identified and may be either >> re-ordered or dropped. >> >> Uppercase MAY? > > OK. > >> The term "microflow" does not appear to be defined anywhere in this >> document, but is used a number of times. I suggest including the >> definition from RFC 2474. > > The first occurance of microflow is in "within a common microflow > SHOULD NOT be reordered [RFC2474]". Since this references RFC2474, I > think this is adequate. Other uses refer back to this section and/or > cite RFC2474 and/or RFC2475. > >> 2.4.4. MPLS Entropy Label >> >> The MPLS entropy label simplifies flow group identification >> [RFC6790] at midpoint LSR. Prior to the MPLS entropy label >> midpoint LSR needed to inspect the entire label stack and often the >> IP headers to provide ... >> >> Missing an article, or make LSR plural. > > In both occurances above plus one additional in this paragraph: > s/midpoint LSR/midpoint LSRs/ > >> Many service providers consider it a hard requirement that use of >> UDP and TCP ports can be disabled. Therefore there is a stong >> incentive for implementations to provide both options. >> >> "strong" > > OK > >> Cryptographic authentication can is some circumstances be subject >> to DoS attack by overwhelming the capacity of the decryption with a >> high volume of malicious traffic. >> >> "in" > > s/can is some/can in some/ > > Please let me know if these changes address your comments adequately. > > Thanks, > > Curtis > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From kent@bbn.com Wed Feb 5 06:25:01 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FE81A0198 for ; Wed, 5 Feb 2014 06:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVmrZ32oBZrG for ; Wed, 5 Feb 2014 06:25:00 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E98CD1A0193 for ; Wed, 5 Feb 2014 06:24:59 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:40556 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WB3PJ-0003TR-SK; Wed, 05 Feb 2014 09:24:54 -0500 Message-ID: <52F249B4.6020301@bbn.com> Date: Wed, 05 Feb 2014 09:24:52 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com References: <201402050417.s154HcTt094007@maildrop2.v6ds.occnc.com> In-Reply-To: <201402050417.s154HcTt094007@maildrop2.v6ds.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: swallow@cisco.com, samante@apple.com, cpignata@cisco.com, kireeti@juniper.net, secdir , agmalis@gmail.com, curtis@occnc.com, rcallon@juniper.net, Adrian Farrel , Loa Andersson , Stewart Bryant Subject: Re: [secdir] SECDIR review of draft-ietf-mpls-forwarding-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 14:25:01 -0000 Curtis, Thanks for the quick reply. I agree that a thorough summary of the relevant security considerations from the many normative references would be a non-trivial task ;-). The brief summary you assembled is excellent! I am satisfied with the changes/responses. Steve From cpignata@cisco.com Wed Feb 5 07:24:42 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E841A01CB for ; Wed, 5 Feb 2014 07:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcgA0grzYx_5 for ; Wed, 5 Feb 2014 07:24:41 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 050111A01BF for ; Wed, 5 Feb 2014 07:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1072; q=dns/txt; s=iport; t=1391613880; x=1392823480; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Cjzy9XuY5FbM06UgPS3ytVZnoMHhXpzDnhLtSD7leIA=; b=GOwgZRzTnVAwE+T8HCiaujdyUmFzfSHdq6+wFrncD4xCz5CIrrvgtxbR 72wdlztGpQOtQAo1CklvQvVd+mCsF1dWv0y7ucS5Ak5CoAaYxHShZb2Q+ R87nZTDntftzG+Y2pDjvj+71S2e+UhYLQHTqkzd555XuXvnLyhkQ05K5f E=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAOtW8lKtJXHB/2dsb2JhbABZgwyBD75EgQ4WdIIlAQEBAwF5BQsCAQhGMiUCBA4FDodvCM9HF451B4MkgRQBA5A/gTKGOpIhgy2CKg X-IronPort-AV: E=Sophos;i="4.95,786,1384300800"; d="asc'?scan'208";a="18158835" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-3.cisco.com with ESMTP; 05 Feb 2014 15:24:40 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s15FOdu9009642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 15:24:39 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 09:24:38 -0600 From: "Carlos Pignataro (cpignata)" To: Stephen Kent Thread-Topic: SECDIR review of draft-ietf-mpls-forwarding-06 Thread-Index: AQHPIik0BJTL+g8LQkSekGUFX/VJf5qnHFMAgAAQswA= Date: Wed, 5 Feb 2014 15:24:38 +0000 Message-ID: References: <201402050417.s154HcTt094007@maildrop2.v6ds.occnc.com> <52F249B4.6020301@bbn.com> In-Reply-To: <52F249B4.6020301@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.102.157.229] Content-Type: multipart/signed; boundary="Apple-Mail=_95417C50-F131-4861-9AAA-98726A4F32A4"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "George Swallow \(swallow\)" , "samante@apple.com" , secdir , "kireeti@juniper.net" , "agmalis@gmail.com" , Loa Andersson , Curtis Villamizar , Ross Callon , Adrian Farrel , "Stewart Bryant \(stbryant\)" , "" Subject: Re: [secdir] SECDIR review of draft-ietf-mpls-forwarding-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 15:24:42 -0000 --Apple-Mail=_95417C50-F131-4861-9AAA-98726A4F32A4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 Thanks, Stephen! On Feb 5, 2014, at 9:24 AM, Stephen Kent wrote: > Curtis, > > Thanks for the quick reply. > > I agree that a thorough summary of the relevant security considerations > from the many normative references would be a non-trivial task ;-). > The brief summary you assembled is excellent! > > I am satisfied with the changes/responses. > > Steve --Apple-Mail=_95417C50-F131-4861-9AAA-98726A4F32A4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLyV7YACgkQtfDPGTp3USxdUgCg0xFe4YSZRaAuRn7cjbOG/Dbi IbcAn09nBB389MCEQi3m9gKDwFVo2dIX =cFQA -----END PGP SIGNATURE----- --Apple-Mail=_95417C50-F131-4861-9AAA-98726A4F32A4-- From curtis@ipv6.occnc.com Wed Feb 5 12:24:47 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4371A01C1 for ; Wed, 5 Feb 2014 12:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVDHwM0GP05m for ; Wed, 5 Feb 2014 12:24:44 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1936D1A0197 for ; Wed, 5 Feb 2014 12:24:44 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s15KOR0W012286; Wed, 5 Feb 2014 15:24:27 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201402052024.s15KOR0W012286@maildrop2.v6ds.occnc.com> To: Stephen Kent From: Curtis Villamizar In-reply-to: Your message of "Wed, 05 Feb 2014 09:24:52 -0500." <52F249B4.6020301@bbn.com> Date: Wed, 05 Feb 2014 15:24:27 -0500 Cc: swallow@cisco.com, samante@apple.com, secdir , kireeti@juniper.net, cpignata@cisco.com, agmalis@gmail.com, Loa Andersson , curtis@occnc.com, rcallon@juniper.net, Adrian Farrel , Stewart Bryant , curtis@ipv6.occnc.com Subject: Re: [secdir] SECDIR review of draft-ietf-mpls-forwarding-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 20:24:47 -0000 In message <52F249B4.6020301@bbn.com> Stephen Kent writes: > > Curtis, > > Thanks for the quick reply. > > I agree that a thorough summary of the relevant security considerations > from the many normative references would be a non-trivial task ;-). > The brief summary you assembled is excellent! > > I am satisfied with the changes/responses. > > Steve Steve, If you don't mind I'd like to add a little to this. This is the very last paragraph and follows the numbered list. OLD PROPOSED MPLS security including data plane security is discussed in greater detail in [RFC5920] (MPLS/GMPLS Security Framework). NEW PROPOSED MPLS security including data plane security is discussed in greater detail in [RFC5920] (MPLS/GMPLS Security Framework). THe MPLS-TP security framework [RFC6941] build upon this, focusing largely on the MPLS-TP OAM additions and OAM channels with some attention given to using network management in place of control plane setup. In both security framework documents MPLS is assumed to run within a "trusted zuone", defined as being where a single service provider (SP) has total operational control over that part of the network. If control plane security and management plane security are sufficiently robust, compromise of a single network element may result in chaos in the data plane anywhere in the network through denial of service attacks, but not a Byzantine security failure in which other network elements are fully compromised. MPLS security, or lack of, can affect whether traffic can be misrouted and lost, or intercepted, or intercepted and reinserted (a man-in-the-middle attack) or spoofed. End user applications, including control plane and management plane protocols used by the SP, are expected to make use of appropriate end-to-end authentication and where appropriate end-to-end encryption. I think the original, while not incorrect, was too brief. This new text provides a better summary, indicating the underlying "trusted zuone" assumption and the lack of any meaningful data plane security if that underlying assumption proves invalid for any reason, but most likely invalid due to a breach or a physical intercept along transmission media. Please let me know if this further change is an improvement or if we should leave it out (or change it). Curtis From curtis@ipv6.occnc.com Wed Feb 5 13:09:45 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437161A020A for ; Wed, 5 Feb 2014 13:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pgd275PunmuV for ; Wed, 5 Feb 2014 13:09:43 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id A046C1A01FC for ; Wed, 5 Feb 2014 13:09:43 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s15L9R6U012940; Wed, 5 Feb 2014 16:09:27 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201402052109.s15L9R6U012940@maildrop2.v6ds.occnc.com> To: curtis@ipv6.occnc.com From: Curtis Villamizar In-reply-to: Your message of "Wed, 05 Feb 2014 15:24:27 -0500." <201402052024.s15KOR0W012286@maildrop2.v6ds.occnc.com> Date: Wed, 05 Feb 2014 16:09:27 -0500 Cc: swallow@cisco.com, samante@apple.com, secdir , kireeti@juniper.net, cpignata@cisco.com, agmalis@gmail.com, curtis@occnc.com, rcallon@juniper.net, Adrian Farrel , Loa Andersson , Stewart Bryant Subject: Re: [secdir] SECDIR review of draft-ietf-mpls-forwarding-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 21:09:45 -0000 In message <201402052024.s15KOR0W012286@maildrop2.v6ds.occnc.com> Curtis Villamizar writes: > > In message <52F249B4.6020301@bbn.com> > Stephen Kent writes: > > > > Curtis, > > > > Thanks for the quick reply. > > > > I agree that a thorough summary of the relevant security considerations > > from the many normative references would be a non-trivial task ;-). > > The brief summary you assembled is excellent! > > > > I am satisfied with the changes/responses. > > > > Steve > > > Steve, > > If you don't mind I'd like to add a little to this. This is the very > last paragraph and follows the numbered list. > > OLD PROPOSED > > MPLS security including data plane security is discussed in greater > detail in [RFC5920] (MPLS/GMPLS Security Framework). > > NEW PROPOSED > > MPLS security including data plane security is discussed in greater > detail in [RFC5920] (MPLS/GMPLS Security Framework). THe MPLS-TP > security framework [RFC6941] build upon this, focusing largely on > the MPLS-TP OAM additions and OAM channels with some attention > given to using network management in place of control plane setup. > In both security framework documents MPLS is assumed to run within > a "trusted zuone", defined as being where a single service provider > (SP) has total operational control over that part of the network. > > If control plane security and management plane security are > sufficiently robust, compromise of a single network element may > result in chaos in the data plane anywhere in the network through > denial of service attacks, but not a Byzantine security failure in > which other network elements are fully compromised. > > MPLS security, or lack of, can affect whether traffic can be > misrouted and lost, or intercepted, or intercepted and reinserted > (a man-in-the-middle attack) or spoofed. End user applications, > including control plane and management plane protocols used by the > SP, are expected to make use of appropriate end-to-end > authentication and where appropriate end-to-end encryption. > > I think the original, while not incorrect, was too brief. This new > text provides a better summary, indicating the underlying "trusted > zuone" assumption and the lack of any meaningful data plane security > if that underlying assumption proves invalid for any reason, but most > likely invalid due to a breach or a physical intercept along > transmission media. > > Please let me know if this further change is an improvement or if we > should leave it out (or change it). > > Curtis s/THe/The/ s/zuone/zone/ From kent@bbn.com Wed Feb 5 13:30:26 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3811A022B for ; Wed, 5 Feb 2014 13:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaXRqNokf53N for ; Wed, 5 Feb 2014 13:30:25 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2D09F1A01D1 for ; Wed, 5 Feb 2014 13:30:25 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:36404 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WBA32-00080k-Qd; Wed, 05 Feb 2014 16:30:21 -0500 Message-ID: <52F2AD6B.4060702@bbn.com> Date: Wed, 05 Feb 2014 16:30:19 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com References: <201402052024.s15KOR0W012286@maildrop2.v6ds.occnc.com> In-Reply-To: <201402052024.s15KOR0W012286@maildrop2.v6ds.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: swallow@cisco.com, samante@apple.com, cpignata@cisco.com, kireeti@juniper.net, secdir , agmalis@gmail.com, curtis@occnc.com, rcallon@juniper.net, Adrian Farrel , Loa Andersson , Stewart Bryant Subject: Re: [secdir] SECDIR review of draft-ietf-mpls-forwarding-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 21:30:27 -0000 Curtis, I agree; the new text is better. Thanks, Steve > In message <52F249B4.6020301@bbn.com> > Stephen Kent writes: >> Curtis, >> >> Thanks for the quick reply. >> >> I agree that a thorough summary of the relevant security considerations >> from the many normative references would be a non-trivial task ;-). >> The brief summary you assembled is excellent! >> >> I am satisfied with the changes/responses. >> >> Steve > > Steve, > > If you don't mind I'd like to add a little to this. This is the very > last paragraph and follows the numbered list. > > OLD PROPOSED > > MPLS security including data plane security is discussed in greater > detail in [RFC5920] (MPLS/GMPLS Security Framework). > > NEW PROPOSED > > MPLS security including data plane security is discussed in greater > detail in [RFC5920] (MPLS/GMPLS Security Framework). THe MPLS-TP > security framework [RFC6941] build upon this, focusing largely on > the MPLS-TP OAM additions and OAM channels with some attention > given to using network management in place of control plane setup. > In both security framework documents MPLS is assumed to run within > a "trusted zuone", defined as being where a single service provider > (SP) has total operational control over that part of the network. > > If control plane security and management plane security are > sufficiently robust, compromise of a single network element may > result in chaos in the data plane anywhere in the network through > denial of service attacks, but not a Byzantine security failure in > which other network elements are fully compromised. > > MPLS security, or lack of, can affect whether traffic can be > misrouted and lost, or intercepted, or intercepted and reinserted > (a man-in-the-middle attack) or spoofed. End user applications, > including control plane and management plane protocols used by the > SP, are expected to make use of appropriate end-to-end > authentication and where appropriate end-to-end encryption. > > I think the original, while not incorrect, was too brief. This new > text provides a better summary, indicating the underlying "trusted > zuone" assumption and the lack of any meaningful data plane security > if that underlying assumption proves invalid for any reason, but most > likely invalid due to a breach or a physical intercept along > transmission media. > > Please let me know if this further change is an improvement or if we > should leave it out (or change it). > > Curtis > From stpeter@stpeter.im Wed Feb 5 16:00:40 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9281A0280; Wed, 5 Feb 2014 16:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFrtIFLORavu; Wed, 5 Feb 2014 16:00:37 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D91171A0233; Wed, 5 Feb 2014 16:00:36 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 88DC64010C; Wed, 5 Feb 2014 17:00:35 -0700 (MST) Message-ID: <52F2D09C.8000900@stpeter.im> Date: Wed, 05 Feb 2014 17:00:28 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ben Laurie , The IESG , "secdir@ietf.org" , draft-ietf-stox-presence.all@tools.ietf.org References: <52F1ABE1.4000805@stpeter.im> In-Reply-To: <52F1ABE1.4000805@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [secdir] sec-dir review of draft-ietf-stox-presence-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 00:00:40 -0000 On 2/4/14, 8:11 PM, Peter Saint-Andre wrote: > Hi Ben, thanks for the review. Comments inline. > > On 2/3/14, 10:50 AM, Ben Laurie wrote: >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> Summary: ready with nits >> >> Detail: the I-D documents a mapping between two fairly well-matched >> presence protocols, and hence does not introduce much danger. The one >> area of concern is that SIP presence subscriptions are short-lived and >> XMPP's are long-lived, thus opening the possibility of an >> amplification attack against SIP via XMPP. >> >> The suggested mitigation is weak: >> >> "To help prevent such an attack, access to an XMPP- >> SIP gateway that is hosted on the XMPP network SHOULD be restricted >> to XMPP users associated with a single domain or trust realm (e.g., a >> gateway hosted at simple.example.com ought to allow only users within >> the example.com domain to access the gateway, not users within >> example.org, example.net, or any other domain)" >> >> Many XMPP servers allow open registration and so this defence is no >> defence at all in that case. > > Don't allow open registration. :-) > > Further, I think it would be irresponsible to offer a generalized > gateway for use by any domain, so the foregoing text might be misleading. > >> Perhaps some kind of rate limitation >> would be useful? > > All self-respecting XMPP servers include rate limiting, but it's unclear > whether that would really help much in practice since you don't any sort > of amplification in order to attack users at another domain even in the > absence of a gateway (just normal XMPP server-to-server will do). > >> Also, this part: >> >> "Furthermore, whenever an XMPP-SIP gateway seeks to refresh >> an XMPP user's long-lived subscription to a SIP user's presence, it >> MUST first send an XMPP stanza of type "probe" from the >> address of the gateway to the "bare JID" (user@domain.tld) of the >> XMPP user, to which the user's XMPP server MUST respond in accordance >> with [RFC6121]; however, the administrator of an XMPP-SIP gateway MAY >> (based on local service provisioning) exempt "known good" XMPP >> servers from this check (e.g., the XMPP server associated with the >> XMPP-SIP gateway as described above)." >> >> is unclear: how does it help? > > This check at least places a burden on the XMPP server itself and > verifies if the XMPP user has an active presence session before updating > the presence subscription on the SIP side of the gateway. > > I'll think about the matter more deeply and formulate some better text. How is this? The mismatch between long-lived XMPP presence subscriptions and short-lived SIP presence subscriptions introduces the possibility of an amplification attack launched from the XMPP network against a SIP presence server (since each long-lived XMPP presence subscription would typically result in multiple subscription refresh requests on the SIP side of a gateway). Therefore, access to an XMPP-SIP gateway SHOULD be restricted in various ways; among other things, only an XMPP service that carefully controls account provisioning ought to host such a gateway (e.g., not a service that offers open account registration) and a gateway ought to be associated only with a single domain or trust realm (e.g., a gateway hosted at simple.example.com ought to allow only users within the example.com domain to access the gateway, not users within example.org, example.net, or any other domain). If a SIP presence server receives communications through an XMPP-SIP gateway from users who are not associated with a domain that is so related to the hostname of the gateway, it SHOULD (based on local service provisioning) refuse to service such users or refuse to receive traffic from with the gateway. As a futher check, whenever an XMPP-SIP gateway seeks to refresh an XMPP user's long-lived subscription to a SIP user's presence, it MUST first send an XMPP stanza of type "probe" from the address of the gateway to the "bare JID" (user@domain.tld) of the XMPP user, to which the user's XMPP server MUST respond in accordance with [RFC6121]; this puts an equal burden on the XMPP server as on the SIP server. Peter -- Peter Saint-Andre https://stpeter.im/ From kivinen@iki.fi Thu Feb 6 03:31:10 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD6F1A03A5 for ; Thu, 6 Feb 2014 03:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id il3_Fk2jDl51 for ; Thu, 6 Feb 2014 03:31:07 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 913641A00E3 for ; Thu, 6 Feb 2014 03:31:07 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s16BV3kA023709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 6 Feb 2014 13:31:03 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s16BV3pL014292; Thu, 6 Feb 2014 13:31:03 +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: <21235.29303.40564.473077@fireball.kivinen.iki.fi> Date: Thu, 6 Feb 2014 13:31:03 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 7 min X-Total-Time: 7 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 11:31:10 -0000 Some reminders about the reviews. It would be nice if you would classify your reviews with "Ready", "Has nits", "Has Issues", "Has Serious Issues", "Not Ready". That would make it easier for me to put that information in to the database. Also if you are doing rereview (i.e. the assignment has R before the date), that means that you have already reviewed the document earlier, but there has been new version of the document since, and I didn't easily see whether all your issues / nits were fixed, which means I reassigned it for rereview. In that case it is just enough to see if your issues have been fixed. Send the normal email (i.e. start new thread, do not reply to anything) to the normal lists (secdir, authors, iesg, etc) also for the rereviews, so I can mark them down to the database. For the early reviews (marked with E) there usually is some extra information what kind of review is requested sent to you in separate email. For the early reviews it would be nice to get some reviews back, as the WG authors have specially asked for the reviews, so they want to get the reviews back. There is still 4 outstanding early reviews... Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Yoav Nir is next in the rotation. For telechat 2014-02-06 Reviewer LC end Draft Julien Laganier T 2013-12-11 draft-ietf-stox-core-09 Ondrej Sury T 2013-12-27 draft-ietf-tls-applayerprotoneg-04 For telechat 2014-02-20 Dorothy Gellert T 2014-02-11 draft-housley-pkix-test-oids-00 Phillip Hallam-Baker TR2014-02-04 draft-ietf-pcp-description-option-04 Phillip Hallam-Baker T 2014-01-27 draft-ietf-qresync-rfc5162bis-10 Steve Hanna TR2014-02-04 draft-ietf-pcp-nat64-prefix64-05 Steve Hanna T 2014-01-28 draft-ietf-v6ops-nat64-experience-09 Kathleen Moriarty TR2013-12-16 draft-ietf-opsec-vpn-leakages-03 Last calls and special requests: Dave Cridland E 2013-11-21 draft-dunbar-armd-arp-nd-scaling-practices-07 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05 Jeffrey Hutzelman 2014-02-04 draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01 Scott Kelly 2014-02-11 draft-ietf-pwe3-iccp-13 Tero Kivinen 2014-02-07 draft-ietf-manet-nhdp-olsrv2-tlv-extension-01 Warren Kumari 2014-02-12 draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-09 Julien Laganier 2014-02-28 draft-fairhurst-ipdvb-ule-iana-05 Matt Lepinski 2014-02-28 draft-housley-pkix-oids-01 Chris Lonvick 2014-02-18 draft-ietf-dhc-dhcpv6-unknown-msg-05 Catherine Meadows 2014-02-17 draft-ietf-dmm-requirements-14 Alexey Melnikov 2014-02-14 draft-ietf-l2vpn-vpls-mib-14 Adam Montville 2014-02-19 draft-ietf-storm-rdmap-ext-08 Kathleen Moriarty 2014-02-18 draft-ietf-tcpm-1323bis-19 Russ Mundy 2014-03-24 draft-mahalingam-dutt-dcops-vxlan-08 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Sandy Murphy 2014-03-05 draft-melnikov-smime-msa-to-mda-02 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-09 Glen Zorn 2013-08-30 draft-kaplan-insipid-session-id-03 -- kivinen@iki.fi From kwiereng@cisco.com Thu Feb 6 07:34:18 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC2F1A0203; Thu, 6 Feb 2014 07:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckRHscp5_CoD; Thu, 6 Feb 2014 07:34:16 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A0EDE1A013D; Thu, 6 Feb 2014 07:34:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5065; q=dns/txt; s=iport; t=1391700856; x=1392910456; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bXYRTZTyPK20Ku/lMPLqDQbXaGwNo0Op2Eearsm5J90=; b=ZRs9vBp/s9hng96qYIYVewAD/23rThT4Y/0SRDPST7jihdNRWg8kRWdx mieaxNNX0BA03nlUW8mSwvtR5FgXC/edWkT1KeuQKRDhQ8XZ8cfgEqvae vwutQXUAO+Oz4O8jUgy+4VAAK34XKfYhzgdHb/da+M9mkXAallwgqZYVh I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskFAJWq81KtJV2Z/2dsb2JhbABZgw44T71SgQwWAXSDfQEBAQMBOj8FBwQCAQgOAwQBAQEeCQchERQJCAIEDgUJh2cDCQgIvh0NiQwXjH+BMQoBBQIBHDMHBoMdgRMBA5QzgXiBa4xaA4U3gyuBaAEf X-IronPort-AV: E=Sophos;i="4.95,793,1384300800"; d="scan'208";a="299304202" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 06 Feb 2014 15:34:14 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s16FYEVF025294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 15:34:14 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.181]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 09:34:13 -0600 From: "Klaas Wierenga (kwiereng)" To: Roni Even Thread-Topic: Secdir review of draft-ietf-p2psip-rpr-11 Thread-Index: AQHPHZxuadjFPudg1EiEZvef0HUYVpqjhjwQgABr8ICABG1ZgIAABwij Date: Thu, 6 Feb 2014 15:34:12 +0000 Message-ID: <8CFAB866-CCD6-4570-A20C-68F0076853BE@cisco.com> References: <521F1B37-7D82-485C-AA8F-624695BC5797@cisco.com> <760B7D45D1EFF74988DBF5C2122830C23E54F3CF@szxpml507-mbx.exmail.huawei.com> <9FF8C147-4F05-4A56-B36A-615858D46882@cisco.com>, <05bb01cf231b$19a7a4e0$4cf6eea0$@gmail.com> In-Reply-To: <05bb01cf231b$19a7a4e0$4cf6eea0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Roni Even , "iesg@ietf.org" , "draft-ietf-p2psip-rpr.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-p2psip-rpr-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 15:34:18 -0000 Perfect! Sent from my iPhone > On 6 feb. 2014, at 10:09, "Roni Even" wrote: >=20 > Hi Klaas, > We will add the sentence to the security section and can take out the > trusted. > Thanks > Roni >=20 >> -----Original Message----- >> From: Klaas Wierenga (kwiereng) [mailto:kwiereng@cisco.com] >> Sent: 03 February, 2014 3:33 PM >> To: Roni Even >> Cc: draft-ietf-p2psip-rpr.all@tools.ietf.org; secdir@ietf.org; > iesg@ietf.org; >> ron.even.tlv@gmail.com >> Subject: Re: Secdir review of draft-ietf-p2psip-rpr-11 >>=20 >>=20 >> On Feb 3, 2014, at 2:06 PM, Roni Even wrot= e: >>=20 >> Hi Roni, >>=20 >>> Thanks for the comments. >>> In order to use a relay, the peer need to learn who is the relevant >>> relay as described in section 3.1 and 3.2 so they are not arbitrary >>> peers, furthermore section 4.1 says that a relay can limit the number >>> of connections. >>=20 >> So what happens if a relay has reached that maximum? Doesn't that mean > that >> the relay has become effectively unusable? But since my SPOF comment >> doesn't seem to hold this is not much of an issue. >>=20 >>> The relay is used for the response path. The source establish a >>> connection to a relay known to him and if succeed send the information >>> in the outgoing message. The response should come from the target peer. >>>=20 >>> So the general security in RFC6490 will work. The relay is not a point >>> of failure since this is an optional mechanism and if the >>> communication fails the routing will fall back to SRR. >>=20 >> ah ok, the sentence "If peer A knows it is behind a NAT or NATs, and kno= ws > one >> or more >> relay peers with whom they have a prior connections, peer A can try >> RPR. " in 3.1 threw me off. I missed that there was in any case an > established >> connection from A to B. So if I now understand correctly, you are dealin= g > with a >> case in which SRR is in any case also always possible? >>=20 >>>=20 >>> We can add some sentence in the security section about the relay >>> limiting the number of connections and maybe about verifying that the >>> connection request for the response is from the destination peer in >>> the outgoing message if the relay will keep state (not recommended) >>=20 >> I think that is useful >>=20 >>>=20 >>> As for being trusted, I think you are right, the relay need to comply >>> with the security specifications in RFC6490. >>=20 >> ok >>=20 >>>=20 >>> BTW: Sorry for not responding earlier bur this was probably since the >>> email sent to draft-ietf-p2psip-rpr-10.all@tools.ietf.org so it did not > reach us. >>=20 >> arghhh, I need to say sorry here, I clearly was a bit too hasty with my >> copy/paste of the draft name! >>=20 >> Klaas >>=20 >>>=20 >>> Roni Even >>>=20 >>> ________________________________________ >>> From: Klaas Wierenga (kwiereng) [kwiereng@cisco.com] >>> Sent: Thursday, January 30, 2014 11:19 AM >>> To: draft-ietf-p2psip-rpr.all@tools.ietf.org >>> Cc: secdir@ietf.org; iesg@ietf.org >>> Subject: Secdir review of draft-ietf-p2psip-rpr-11 >>>=20 >>> Hi, >>>=20 >>> I reviewed earlier version 10 (http://www.ietf.org/mail- >> archive/web/secdir/current/msg04256.html), I didn't get any response and > the >> security considerations don't seem to address what I wrote at that time, > so I'll >> repeat: >>>=20 >>> -- >>> Hi, >>>=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 >>> This document defines an optional extension to RELOAD to support Relay >> Peer Routing (RPR) mode (as opposed to Symmetric Recursive Routing (SRR)= . >> The document is straightforward and clear, but with respect to the > security >> considerations a few comments: >>>=20 >>> - I am surprised that there is no discussion on the relay peer being th= e > single >> (or few) point of failure, and thus becoming an interesting target for > DoS >> attacks: the relay peer acts as a hub for all traffic coming from the > peers that >> have it as their relay. Especially when there is a limited number of > relays it >> becomes attractive to bring the relay down. >>>=20 >>> - The other thing I wonder about is why there is the need to trust the > relay, >> why is this different from the DRR case (apart from the observation in m= y >> previous comment)? It seems that the system would work just fine without > the >> explicit trust in the relay peer, in fact, the way I understand it every > peer in the >> overlay can in principle act as a relay peer (I imagine a scenario where > the >> relay peer acts as the "established connection"). >>>=20 >>> Cheers, >>>=20 >>> Klaas Wierenga >>> -- >=20 From benl@google.com Thu Feb 6 10:16:50 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBD01A0432 for ; Thu, 6 Feb 2014 10:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0FTixiNd_Tx for ; Thu, 6 Feb 2014 10:16:47 -0800 (PST) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 566DE1A0454 for ; Thu, 6 Feb 2014 10:16:45 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id pa12so1805096veb.16 for ; Thu, 06 Feb 2014 10:16:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DC9KquvgCzHRzNuqVY+ClEjpC8jNLJTxacXxGQck5FM=; b=l199ph8FQeEdUVE7taQh09bSbGa80FgN0Uk2FReYmxhWtFNB3YSHjJylBcaH8N6Azn 4NtiC9r8SUK6uXkeWdCevjchRdK8bdHf/9tfizFrQ1JtS2YmNVRC3kiW3bjOFsvq20at S2d0H3693FxCm91ddlEppJkKqCc6SfspjP5wL3DSNQMs2+mXkVB5np6s2cM3XnLdrpRM bbW9kysaIxUVyoNTiH1ZmcbakYrD6+wvzLYFDXuvLREK+2pPR464NgXoH5/Vo+Rm+kHp adg/ixk9H0XOTqrxI9dbgZtp9mFiymxll6OOAbECrB5YjaLszobyX5LGhvSUpkJ2g9V6 NSgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DC9KquvgCzHRzNuqVY+ClEjpC8jNLJTxacXxGQck5FM=; b=JGtTnSW/xkLG8JiDVzA/vP6N6rGV0p1lxU8bAMQ+/IBY8hxL4PaWcShXTQqyPkkfXd K1akzbBBLJuUJ/TbEuQ483+RatmQDbukYvw0G01hnhLggY0+a5KWP9E3FgTjWRjE+AiA sLrrw7u26GBi5pKYCpqwXItngH0IrUt+Kwppm8h/f77/4JkNQxRMwKOl7BwTgQrG0UHa P1BBpF6KblmVWU7zYXj3ckL19nJ+tDgLvspDUjEablfLJNZDJ10HaIA5CE2QSzyfJAXN XVFxBhySy1ppeHTqjRXSBairZ+kiOek77daOJvh60dME0fNRE9uczJGOmdkhtYW+XMHz Hrng== X-Gm-Message-State: ALoCoQl70xLDiNdtfduUWP7AiFcbN0Yw1uP9r2R0AOe7lHmH30iLXYFo7Kkzt43XitNSJoUm6dCEfTbQx3BMZEM0u+S7Iwy4KjpO7Ph45i842g43kEiqPwKSggh5zhRIru7KQk52xX4Mkdf5FeqBqVDG0USzaXCMlgQDuFSwGyHNXIFPDacHYMM5m0iFZe4lmu66aBznzPIa MIME-Version: 1.0 X-Received: by 10.220.48.194 with SMTP id s2mr363157vcf.43.1391710603815; Thu, 06 Feb 2014 10:16:43 -0800 (PST) Received: by 10.52.230.105 with HTTP; Thu, 6 Feb 2014 10:16:43 -0800 (PST) In-Reply-To: <52F2D09C.8000900@stpeter.im> References: <52F1ABE1.4000805@stpeter.im> <52F2D09C.8000900@stpeter.im> Date: Thu, 6 Feb 2014 18:16:43 +0000 Message-ID: From: Ben Laurie To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: The IESG , draft-ietf-stox-presence.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] sec-dir review of draft-ietf-stox-presence-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 18:16:50 -0000 On 6 February 2014 00:00, Peter Saint-Andre wrote: > On 2/4/14, 8:11 PM, Peter Saint-Andre wrote: >> >> Hi Ben, thanks for the review. Comments inline. >> >> On 2/3/14, 10:50 AM, Ben Laurie wrote: >>> >>> I have reviewed this document as part of the security directorate's >>> ongoing effort to review all IETF documents being processed by the >>> IESG. These comments were written primarily for the benefit of the >>> security area directors. Document editors and WG chairs should treat >>> these comments just like any other last call comments. >>> >>> Summary: ready with nits >>> >>> Detail: the I-D documents a mapping between two fairly well-matched >>> presence protocols, and hence does not introduce much danger. The one >>> area of concern is that SIP presence subscriptions are short-lived and >>> XMPP's are long-lived, thus opening the possibility of an >>> amplification attack against SIP via XMPP. >>> >>> The suggested mitigation is weak: >>> >>> "To help prevent such an attack, access to an XMPP- >>> SIP gateway that is hosted on the XMPP network SHOULD be restricted >>> to XMPP users associated with a single domain or trust realm (e.g., a >>> gateway hosted at simple.example.com ought to allow only users within >>> the example.com domain to access the gateway, not users within >>> example.org, example.net, or any other domain)" >>> >>> Many XMPP servers allow open registration and so this defence is no >>> defence at all in that case. >> >> >> Don't allow open registration. :-) >> >> Further, I think it would be irresponsible to offer a generalized >> gateway for use by any domain, so the foregoing text might be misleading. >> >>> Perhaps some kind of rate limitation >>> would be useful? >> >> >> All self-respecting XMPP servers include rate limiting, but it's unclear >> whether that would really help much in practice since you don't any sort >> of amplification in order to attack users at another domain even in the >> absence of a gateway (just normal XMPP server-to-server will do). >> >>> Also, this part: >>> >>> "Furthermore, whenever an XMPP-SIP gateway seeks to refresh >>> an XMPP user's long-lived subscription to a SIP user's presence, it >>> MUST first send an XMPP stanza of type "probe" from the >>> address of the gateway to the "bare JID" (user@domain.tld) of the >>> XMPP user, to which the user's XMPP server MUST respond in accordance >>> with [RFC6121]; however, the administrator of an XMPP-SIP gateway MAY >>> (based on local service provisioning) exempt "known good" XMPP >>> servers from this check (e.g., the XMPP server associated with the >>> XMPP-SIP gateway as described above)." >>> >>> is unclear: how does it help? >> >> >> This check at least places a burden on the XMPP server itself and >> verifies if the XMPP user has an active presence session before updating >> the presence subscription on the SIP side of the gateway. >> >> I'll think about the matter more deeply and formulate some better text. > > > How is this? Better, but... > > The mismatch between long-lived XMPP presence subscriptions and > short-lived SIP presence subscriptions introduces the possibility of > an amplification attack launched from the XMPP network against a SIP > presence server (since each long-lived XMPP presence subscription > would typically result in multiple subscription refresh requests on > the SIP side of a gateway). Therefore, access to an XMPP-SIP gateway > SHOULD be restricted in various ways; among other things, only an > XMPP service that carefully controls account provisioning ought to > host such a gateway (e.g., not a service that offers open account > registration) and a gateway ought to be associated only with a single > > domain or trust realm (e.g., a gateway hosted at simple.example.com > ought to allow only users within the example.com domain to access the > gateway, not users within example.org, example.net, or any other > domain). ...I suspect the criterion you are really trying to capture is that their should be some kind of administrative link between the XMPP server and its users (i.e. abusers can be permanently kicked off, if needed). Perhaps better to say that directly? > If a SIP presence server receives communications through an > XMPP-SIP gateway from users who are not associated with a domain that > is so related to the hostname of the gateway, it SHOULD (based on > local service provisioning) refuse to service such users or refuse to > receive traffic from with the gateway. As a futher check, whenever > an XMPP-SIP gateway seeks to refresh an XMPP user's long-lived > subscription to a SIP user's presence, it MUST first send an XMPP > stanza of type "probe" from the address of the gateway to > the "bare JID" (user@domain.tld) of the XMPP user, to which the > user's XMPP server MUST respond in accordance with [RFC6121]; this > puts an equal burden on the XMPP server as on the SIP server. > > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ From stpeter@stpeter.im Thu Feb 6 10:56:37 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C94B1A03C0; Thu, 6 Feb 2014 10:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWyRU8yWHyoQ; Thu, 6 Feb 2014 10:56:34 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B1C1B1A00EA; Thu, 6 Feb 2014 10:56:34 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id ADFE64010C; Thu, 6 Feb 2014 11:56:32 -0700 (MST) Message-ID: <52F3DADF.3030708@stpeter.im> Date: Thu, 06 Feb 2014 11:56:31 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ben Laurie References: <52F1ABE1.4000805@stpeter.im> <52F2D09C.8000900@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: The IESG , draft-ietf-stox-presence.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] sec-dir review of draft-ietf-stox-presence-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 18:56:37 -0000 On 2/6/14, 11:16 AM, Ben Laurie wrote: > On 6 February 2014 00:00, Peter Saint-Andre wrote: >> On 2/4/14, 8:11 PM, Peter Saint-Andre wrote: >>> >>> Hi Ben, thanks for the review. Comments inline. >>> >>> On 2/3/14, 10:50 AM, Ben Laurie wrote: >>>> >>>> I have reviewed this document as part of the security directorate's >>>> ongoing effort to review all IETF documents being processed by the >>>> IESG. These comments were written primarily for the benefit of the >>>> security area directors. Document editors and WG chairs should treat >>>> these comments just like any other last call comments. >>>> >>>> Summary: ready with nits >>>> >>>> Detail: the I-D documents a mapping between two fairly well-matched >>>> presence protocols, and hence does not introduce much danger. The one >>>> area of concern is that SIP presence subscriptions are short-lived and >>>> XMPP's are long-lived, thus opening the possibility of an >>>> amplification attack against SIP via XMPP. >>>> >>>> The suggested mitigation is weak: >>>> >>>> "To help prevent such an attack, access to an XMPP- >>>> SIP gateway that is hosted on the XMPP network SHOULD be restricted >>>> to XMPP users associated with a single domain or trust realm (e.g., a >>>> gateway hosted at simple.example.com ought to allow only users within >>>> the example.com domain to access the gateway, not users within >>>> example.org, example.net, or any other domain)" >>>> >>>> Many XMPP servers allow open registration and so this defence is no >>>> defence at all in that case. >>> >>> >>> Don't allow open registration. :-) >>> >>> Further, I think it would be irresponsible to offer a generalized >>> gateway for use by any domain, so the foregoing text might be misleading. >>> >>>> Perhaps some kind of rate limitation >>>> would be useful? >>> >>> >>> All self-respecting XMPP servers include rate limiting, but it's unclear >>> whether that would really help much in practice since you don't any sort >>> of amplification in order to attack users at another domain even in the >>> absence of a gateway (just normal XMPP server-to-server will do). >>> >>>> Also, this part: >>>> >>>> "Furthermore, whenever an XMPP-SIP gateway seeks to refresh >>>> an XMPP user's long-lived subscription to a SIP user's presence, it >>>> MUST first send an XMPP stanza of type "probe" from the >>>> address of the gateway to the "bare JID" (user@domain.tld) of the >>>> XMPP user, to which the user's XMPP server MUST respond in accordance >>>> with [RFC6121]; however, the administrator of an XMPP-SIP gateway MAY >>>> (based on local service provisioning) exempt "known good" XMPP >>>> servers from this check (e.g., the XMPP server associated with the >>>> XMPP-SIP gateway as described above)." >>>> >>>> is unclear: how does it help? >>> >>> >>> This check at least places a burden on the XMPP server itself and >>> verifies if the XMPP user has an active presence session before updating >>> the presence subscription on the SIP side of the gateway. >>> >>> I'll think about the matter more deeply and formulate some better text. >> >> >> How is this? > > Better, but... > >> >> The mismatch between long-lived XMPP presence subscriptions and >> short-lived SIP presence subscriptions introduces the possibility of >> an amplification attack launched from the XMPP network against a SIP >> presence server (since each long-lived XMPP presence subscription >> would typically result in multiple subscription refresh requests on >> the SIP side of a gateway). Therefore, access to an XMPP-SIP gateway >> SHOULD be restricted in various ways; among other things, only an >> XMPP service that carefully controls account provisioning ought to >> host such a gateway (e.g., not a service that offers open account >> registration) and a gateway ought to be associated only with a single >> >> domain or trust realm (e.g., a gateway hosted at simple.example.com >> ought to allow only users within the example.com domain to access the >> gateway, not users within example.org, example.net, or any other >> domain). > > ...I suspect the criterion you are really trying to capture is that > their should be some kind of administrative link between the XMPP > server and its users (i.e. abusers can be permanently kicked off, if > needed). Perhaps better to say that directly? Yes, that's part of it but not all of it. For instance, I run the jabber.org IM service, which has 1.4 million users or so. The other admins and I definitely have the ability to permanently disable user accounts, we have user registration locked down, we have rate limiting in place, etc. -- but there's no way we'd ever offer a gateway of the kind described in this document because we have too many users to know them all or have any truly effective control over them. If I were running an XMPP service at a company (even a company with 100,000 employees) I'd be comfortable offering a gateway, because the company could always fire someone who does something wrong. I'll try again to rework the text to capture some of these ideas. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Feb 6 19:44:16 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4549A1A0354; Thu, 6 Feb 2014 19:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqcq_Wle4Osc; Thu, 6 Feb 2014 19:44:14 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0501A0346; Thu, 6 Feb 2014 19:44:14 -0800 (PST) Received: from [192.168.1.6] (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4696E4010C; Thu, 6 Feb 2014 20:44:12 -0700 (MST) Message-ID: <52F4568B.3010201@stpeter.im> Date: Thu, 06 Feb 2014 20:44:11 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Ben Laurie References: <52F1ABE1.4000805@stpeter.im> <52F2D09C.8000900@stpeter.im> <52F3DADF.3030708@stpeter.im> In-Reply-To: <52F3DADF.3030708@stpeter.im> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: The IESG , draft-ietf-stox-presence.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] sec-dir review of draft-ietf-stox-presence-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 03:44:16 -0000 On 02/06/2014 11:56 AM, Peter Saint-Andre wrote: > On 2/6/14, 11:16 AM, Ben Laurie wrote: >> On 6 February 2014 00:00, Peter Saint-Andre wrote: >>> On 2/4/14, 8:11 PM, Peter Saint-Andre wrote: >>>> >>>> Hi Ben, thanks for the review. Comments inline. >>>> >>>> On 2/3/14, 10:50 AM, Ben Laurie wrote: >>>>> >>>>> I have reviewed this document as part of the security directorate's >>>>> ongoing effort to review all IETF documents being processed by the >>>>> IESG. These comments were written primarily for the benefit of the >>>>> security area directors. Document editors and WG chairs should treat >>>>> these comments just like any other last call comments. >>>>> >>>>> Summary: ready with nits >>>>> >>>>> Detail: the I-D documents a mapping between two fairly well-matched >>>>> presence protocols, and hence does not introduce much danger. The one >>>>> area of concern is that SIP presence subscriptions are short-lived and >>>>> XMPP's are long-lived, thus opening the possibility of an >>>>> amplification attack against SIP via XMPP. >>>>> >>>>> The suggested mitigation is weak: >>>>> >>>>> "To help prevent such an attack, access to an XMPP- >>>>> SIP gateway that is hosted on the XMPP network SHOULD be >>>>> restricted >>>>> to XMPP users associated with a single domain or trust realm >>>>> (e.g., a >>>>> gateway hosted at simple.example.com ought to allow only users >>>>> within >>>>> the example.com domain to access the gateway, not users within >>>>> example.org, example.net, or any other domain)" >>>>> >>>>> Many XMPP servers allow open registration and so this defence is no >>>>> defence at all in that case. >>>> >>>> >>>> Don't allow open registration. :-) >>>> >>>> Further, I think it would be irresponsible to offer a generalized >>>> gateway for use by any domain, so the foregoing text might be >>>> misleading. >>>> >>>>> Perhaps some kind of rate limitation >>>>> would be useful? >>>> >>>> >>>> All self-respecting XMPP servers include rate limiting, but it's >>>> unclear >>>> whether that would really help much in practice since you don't any >>>> sort >>>> of amplification in order to attack users at another domain even in the >>>> absence of a gateway (just normal XMPP server-to-server will do). >>>> >>>>> Also, this part: >>>>> >>>>> "Furthermore, whenever an XMPP-SIP gateway seeks to refresh >>>>> an XMPP user's long-lived subscription to a SIP user's >>>>> presence, it >>>>> MUST first send an XMPP stanza of type "probe" >>>>> from the >>>>> address of the gateway to the "bare JID" (user@domain.tld) of the >>>>> XMPP user, to which the user's XMPP server MUST respond in >>>>> accordance >>>>> with [RFC6121]; however, the administrator of an XMPP-SIP >>>>> gateway MAY >>>>> (based on local service provisioning) exempt "known good" XMPP >>>>> servers from this check (e.g., the XMPP server associated with >>>>> the >>>>> XMPP-SIP gateway as described above)." >>>>> >>>>> is unclear: how does it help? >>>> >>>> >>>> This check at least places a burden on the XMPP server itself and >>>> verifies if the XMPP user has an active presence session before >>>> updating >>>> the presence subscription on the SIP side of the gateway. >>>> >>>> I'll think about the matter more deeply and formulate some better text. >>> >>> >>> How is this? >> >> Better, but... >> >>> >>> The mismatch between long-lived XMPP presence subscriptions and >>> short-lived SIP presence subscriptions introduces the possibility of >>> an amplification attack launched from the XMPP network against a SIP >>> presence server (since each long-lived XMPP presence subscription >>> would typically result in multiple subscription refresh requests on >>> the SIP side of a gateway). Therefore, access to an XMPP-SIP >>> gateway >>> SHOULD be restricted in various ways; among other things, only an >>> XMPP service that carefully controls account provisioning ought to >>> host such a gateway (e.g., not a service that offers open account >>> registration) and a gateway ought to be associated only with a >>> single >>> >>> domain or trust realm (e.g., a gateway hosted at simple.example.com >>> ought to allow only users within the example.com domain to access >>> the >>> gateway, not users within example.org, example.net, or any other >>> domain). >> >> ...I suspect the criterion you are really trying to capture is that >> their should be some kind of administrative link between the XMPP >> server and its users (i.e. abusers can be permanently kicked off, if >> needed). Perhaps better to say that directly? > > Yes, that's part of it but not all of it. For instance, I run the > jabber.org IM service, which has 1.4 million users or so. The other > admins and I definitely have the ability to permanently disable user > accounts, we have user registration locked down, we have rate limiting > in place, etc. -- but there's no way we'd ever offer a gateway of the > kind described in this document because we have too many users to know > them all or have any truly effective control over them. If I were > running an XMPP service at a company (even a company with 100,000 > employees) I'd be comfortable offering a gateway, because the company > could always fire someone who does something wrong. > > I'll try again to rework the text to capture some of these ideas. A further text tweak: The mismatch between long-lived XMPP presence subscriptions and short-lived SIP presence subscriptions introduces the possibility of an amplification attack launched from the XMPP network against a SIP presence server (since each long-lived XMPP presence subscription would typically result in multiple subscription refresh requests on the SIP side of a gateway). Therefore, access to an XMPP-SIP gateway SHOULD be restricted in various ways; among other things, only an XMPP service that carefully controls account provisioning and provides effective methods for the administrators to control the behavior of registered users ought to host such a gateway (e.g., not a service that offers open account registration) and a gateway ought to be associated only with a single domain or trust realm (e.g., a gateway hosted at simple.example.com ought to allow only users within the example.com domain to access the gateway, not users within example.org, example.net, or any other domain). If a SIP presence server receives communications through an XMPP-SIP gateway from users who are not associated with a domain that is so related to the hostname of the gateway, it SHOULD (based on local service provisioning) refuse to service such users or refuse to receive traffic from with the gateway. As a futher check, whenever an XMPP- SIP gateway seeks to refresh an XMPP user's long-lived subscription to a SIP user's presence, it MUST first send an XMPP stanza of type "probe" from the address of the gateway to the "bare JID" (user@domain.tld) of the XMPP user, to which the user's XMPP server MUST respond in accordance with [RFC6121]; this puts an equal burden on the XMPP server as on the SIP server. Peter From benl@google.com Fri Feb 7 06:37:31 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A57E1A1EFE for ; Fri, 7 Feb 2014 06:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVhe7hl28HxR for ; Fri, 7 Feb 2014 06:37:29 -0800 (PST) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7101A1F72 for ; Fri, 7 Feb 2014 06:37:27 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id 11so2659992vbe.38 for ; Fri, 07 Feb 2014 06:37:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=esPCyvAWzksjGTIju7EOsBaVxbzbGZwISB0s6mm212w=; b=S+iHzh83ajcM0kyhjN8viwnJB+2VybcqCJxhmpMz0YAEze2u9PYPPLDi4lYZrxm54S IZ05mwNWaiVOaUN8LFwWwe6CinczIlAv6ZZl7vEwNlUjMa8FFA7hQylCOzyZra2hmu9z S4X9YS+pDvywttTeSS3F110fK8FvjFo5Z5bWsnUF9Ng6Xk7Sa4FEdDQauWcv+Z+1VoP7 +C4JLtF1EjJ/nTirLTYlHz+xq+lGGMVoPGPoXGrqaxSV+Rws20vgnD4mf1/Hhsqld2Nt 8kXx9gJYYVRPTh+G1eKTn2b4Afl/5OjsUG8aL41XFGB4NuzCEQbXdA70BcP0fThSh9gG 6Gdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=esPCyvAWzksjGTIju7EOsBaVxbzbGZwISB0s6mm212w=; b=IIu53JJ6CgyqN/1NTHzIh9PaxhUSsTusle3aXLGSc/805OaYabYUvy0ZGQ+1a7YLaj y++WjV9/poIfjVOfmbWzLgWxC9tFUCVg7PW0JJyRNosNTp6Ldpv1ukJ+DDt1aqr+RSDp Ph2LMkXYbZ7jEkaZ94eXko87oVSbAOmQVrBUk+LZ9ZlOYNsAFVA4vynyoJyQicu1Rrw3 NexZLmoQknIA4y7VZ3/yxywbzKSIRP5qr44SJJ2Jj/GtXvCvP2/jlrqruQdL42KAg43z AoDhE5dYSm0xgvcPy0VfnR0X92zvxKi+lHpxtIvtCH9ygAIwk3n9W7bWbUbyo3ogp74j F2iw== X-Gm-Message-State: ALoCoQnSMP970xbXT0UReAD90likFllmxrj4MMczD8rghfLW/HSrd81aqeQEpiUntHu1sr+n22Hzh0K64GTf0r9RStDOX3OprhVlE4iTQXOmIcHls8QZ2DUv2+WDcHemgz8Zi1GLoUTe7InVQ/BSxF7h9aJWsUPsXWoJQxtARoJDrZ5BRUiQUo5IM4/VBy4QaF5ZqOauvvrJ MIME-Version: 1.0 X-Received: by 10.52.121.113 with SMTP id lj17mr9022314vdb.21.1391783846523; Fri, 07 Feb 2014 06:37:26 -0800 (PST) Received: by 10.52.230.105 with HTTP; Fri, 7 Feb 2014 06:37:26 -0800 (PST) In-Reply-To: <52F4568B.3010201@stpeter.im> References: <52F1ABE1.4000805@stpeter.im> <52F2D09C.8000900@stpeter.im> <52F3DADF.3030708@stpeter.im> <52F4568B.3010201@stpeter.im> Date: Fri, 7 Feb 2014 14:37:26 +0000 Message-ID: From: Ben Laurie To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: The IESG , draft-ietf-stox-presence.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] sec-dir review of draft-ietf-stox-presence-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 14:37:31 -0000 On 7 February 2014 03:44, Peter Saint-Andre wrote: > On 02/06/2014 11:56 AM, Peter Saint-Andre wrote: >> On 2/6/14, 11:16 AM, Ben Laurie wrote: >>> On 6 February 2014 00:00, Peter Saint-Andre wrote: >>>> On 2/4/14, 8:11 PM, Peter Saint-Andre wrote: >>>>> >>>>> Hi Ben, thanks for the review. Comments inline. >>>>> >>>>> On 2/3/14, 10:50 AM, Ben Laurie wrote: >>>>>> >>>>>> I have reviewed this document as part of the security directorate's >>>>>> ongoing effort to review all IETF documents being processed by the >>>>>> IESG. These comments were written primarily for the benefit of the >>>>>> security area directors. Document editors and WG chairs should treat >>>>>> these comments just like any other last call comments. >>>>>> >>>>>> Summary: ready with nits >>>>>> >>>>>> Detail: the I-D documents a mapping between two fairly well-matched >>>>>> presence protocols, and hence does not introduce much danger. The one >>>>>> area of concern is that SIP presence subscriptions are short-lived and >>>>>> XMPP's are long-lived, thus opening the possibility of an >>>>>> amplification attack against SIP via XMPP. >>>>>> >>>>>> The suggested mitigation is weak: >>>>>> >>>>>> "To help prevent such an attack, access to an XMPP- >>>>>> SIP gateway that is hosted on the XMPP network SHOULD be >>>>>> restricted >>>>>> to XMPP users associated with a single domain or trust realm >>>>>> (e.g., a >>>>>> gateway hosted at simple.example.com ought to allow only users >>>>>> within >>>>>> the example.com domain to access the gateway, not users within >>>>>> example.org, example.net, or any other domain)" >>>>>> >>>>>> Many XMPP servers allow open registration and so this defence is no >>>>>> defence at all in that case. >>>>> >>>>> >>>>> Don't allow open registration. :-) >>>>> >>>>> Further, I think it would be irresponsible to offer a generalized >>>>> gateway for use by any domain, so the foregoing text might be >>>>> misleading. >>>>> >>>>>> Perhaps some kind of rate limitation >>>>>> would be useful? >>>>> >>>>> >>>>> All self-respecting XMPP servers include rate limiting, but it's >>>>> unclear >>>>> whether that would really help much in practice since you don't any >>>>> sort >>>>> of amplification in order to attack users at another domain even in the >>>>> absence of a gateway (just normal XMPP server-to-server will do). >>>>> >>>>>> Also, this part: >>>>>> >>>>>> "Furthermore, whenever an XMPP-SIP gateway seeks to refresh >>>>>> an XMPP user's long-lived subscription to a SIP user's >>>>>> presence, it >>>>>> MUST first send an XMPP stanza of type "probe" >>>>>> from the >>>>>> address of the gateway to the "bare JID" (user@domain.tld) of the >>>>>> XMPP user, to which the user's XMPP server MUST respond in >>>>>> accordance >>>>>> with [RFC6121]; however, the administrator of an XMPP-SIP >>>>>> gateway MAY >>>>>> (based on local service provisioning) exempt "known good" XMPP >>>>>> servers from this check (e.g., the XMPP server associated with >>>>>> the >>>>>> XMPP-SIP gateway as described above)." >>>>>> >>>>>> is unclear: how does it help? >>>>> >>>>> >>>>> This check at least places a burden on the XMPP server itself and >>>>> verifies if the XMPP user has an active presence session before >>>>> updating >>>>> the presence subscription on the SIP side of the gateway. >>>>> >>>>> I'll think about the matter more deeply and formulate some better text. >>>> >>>> >>>> How is this? >>> >>> Better, but... >>> >>>> >>>> The mismatch between long-lived XMPP presence subscriptions and >>>> short-lived SIP presence subscriptions introduces the possibility of >>>> an amplification attack launched from the XMPP network against a SIP >>>> presence server (since each long-lived XMPP presence subscription >>>> would typically result in multiple subscription refresh requests on >>>> the SIP side of a gateway). Therefore, access to an XMPP-SIP >>>> gateway >>>> SHOULD be restricted in various ways; among other things, only an >>>> XMPP service that carefully controls account provisioning ought to >>>> host such a gateway (e.g., not a service that offers open account >>>> registration) and a gateway ought to be associated only with a >>>> single >>>> >>>> domain or trust realm (e.g., a gateway hosted at simple.example.com >>>> ought to allow only users within the example.com domain to access >>>> the >>>> gateway, not users within example.org, example.net, or any other >>>> domain). >>> >>> ...I suspect the criterion you are really trying to capture is that >>> their should be some kind of administrative link between the XMPP >>> server and its users (i.e. abusers can be permanently kicked off, if >>> needed). Perhaps better to say that directly? >> >> Yes, that's part of it but not all of it. For instance, I run the >> jabber.org IM service, which has 1.4 million users or so. The other >> admins and I definitely have the ability to permanently disable user >> accounts, we have user registration locked down, we have rate limiting >> in place, etc. -- but there's no way we'd ever offer a gateway of the >> kind described in this document because we have too many users to know >> them all or have any truly effective control over them. If I were >> running an XMPP service at a company (even a company with 100,000 >> employees) I'd be comfortable offering a gateway, because the company >> could always fire someone who does something wrong. >> >> I'll try again to rework the text to capture some of these ideas. > > A further text tweak: > > The mismatch between long-lived XMPP presence subscriptions and > short-lived SIP presence subscriptions introduces the possibility of > an amplification attack launched from the XMPP network against a SIP > presence server (since each long-lived XMPP presence subscription > would typically result in multiple subscription refresh requests on > the SIP side of a gateway). Therefore, access to an XMPP-SIP gateway > SHOULD be restricted in various ways; among other things, only an > XMPP service that carefully controls account provisioning and > provides effective methods for the administrators to control the > behavior of registered users ought to host such a gateway (e.g., not > a service that offers open account registration) and a gateway ought > to be associated only with a single domain or trust realm (e.g., a > gateway hosted at simple.example.com ought to allow only users within > the example.com domain to access the gateway, not users within > example.org, example.net, or any other domain). If a SIP presence > server receives communications through an XMPP-SIP gateway from users > who are not associated with a domain that is so related to the > hostname of the gateway, it SHOULD (based on local service > provisioning) refuse to service such users or refuse to receive > traffic from with the gateway. As a futher check, whenever an XMPP- > SIP gateway seeks to refresh an XMPP user's long-lived subscription > to a SIP user's presence, it MUST first send an XMPP > stanza of type "probe" from the address of the gateway to the "bare > JID" (user@domain.tld) of the XMPP user, to which the user's XMPP > server MUST respond in accordance with [RFC6121]; this puts an equal > burden on the XMPP server as on the SIP server. Sounds good to me. > > Peter > From stpeter@stpeter.im Fri Feb 7 06:45:40 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91711A1F65; Fri, 7 Feb 2014 06:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mh7wIGLXJvst; Fri, 7 Feb 2014 06:45:38 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 592C41A1F78; Fri, 7 Feb 2014 06:45:36 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 369D74010C; Fri, 7 Feb 2014 07:45:36 -0700 (MST) Message-ID: <52F4F18F.8030408@stpeter.im> Date: Fri, 07 Feb 2014 07:45:35 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ben Laurie References: <52F1ABE1.4000805@stpeter.im> <52F2D09C.8000900@stpeter.im> <52F3DADF.3030708@stpeter.im> <52F4568B.3010201@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: The IESG , draft-ietf-stox-presence.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] sec-dir review of draft-ietf-stox-presence-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 14:45:40 -0000 On 2/7/14, 7:37 AM, Ben Laurie wrote: > On 7 February 2014 03:44, Peter Saint-Andre wrote: >> On 02/06/2014 11:56 AM, Peter Saint-Andre wrote: >>> On 2/6/14, 11:16 AM, Ben Laurie wrote: >>>> On 6 February 2014 00:00, Peter Saint-Andre wrote: >>>>> On 2/4/14, 8:11 PM, Peter Saint-Andre wrote: >>>>>> >>>>>> Hi Ben, thanks for the review. Comments inline. >>>>>> >>>>>> On 2/3/14, 10:50 AM, Ben Laurie wrote: >>>>>>> >>>>>>> I have reviewed this document as part of the security directorate's >>>>>>> ongoing effort to review all IETF documents being processed by the >>>>>>> IESG. These comments were written primarily for the benefit of the >>>>>>> security area directors. Document editors and WG chairs should treat >>>>>>> these comments just like any other last call comments. >>>>>>> >>>>>>> Summary: ready with nits >>>>>>> >>>>>>> Detail: the I-D documents a mapping between two fairly well-matched >>>>>>> presence protocols, and hence does not introduce much danger. The one >>>>>>> area of concern is that SIP presence subscriptions are short-lived and >>>>>>> XMPP's are long-lived, thus opening the possibility of an >>>>>>> amplification attack against SIP via XMPP. >>>>>>> >>>>>>> The suggested mitigation is weak: >>>>>>> >>>>>>> "To help prevent such an attack, access to an XMPP- >>>>>>> SIP gateway that is hosted on the XMPP network SHOULD be >>>>>>> restricted >>>>>>> to XMPP users associated with a single domain or trust realm >>>>>>> (e.g., a >>>>>>> gateway hosted at simple.example.com ought to allow only users >>>>>>> within >>>>>>> the example.com domain to access the gateway, not users within >>>>>>> example.org, example.net, or any other domain)" >>>>>>> >>>>>>> Many XMPP servers allow open registration and so this defence is no >>>>>>> defence at all in that case. >>>>>> >>>>>> >>>>>> Don't allow open registration. :-) >>>>>> >>>>>> Further, I think it would be irresponsible to offer a generalized >>>>>> gateway for use by any domain, so the foregoing text might be >>>>>> misleading. >>>>>> >>>>>>> Perhaps some kind of rate limitation >>>>>>> would be useful? >>>>>> >>>>>> >>>>>> All self-respecting XMPP servers include rate limiting, but it's >>>>>> unclear >>>>>> whether that would really help much in practice since you don't any >>>>>> sort >>>>>> of amplification in order to attack users at another domain even in the >>>>>> absence of a gateway (just normal XMPP server-to-server will do). >>>>>> >>>>>>> Also, this part: >>>>>>> >>>>>>> "Furthermore, whenever an XMPP-SIP gateway seeks to refresh >>>>>>> an XMPP user's long-lived subscription to a SIP user's >>>>>>> presence, it >>>>>>> MUST first send an XMPP stanza of type "probe" >>>>>>> from the >>>>>>> address of the gateway to the "bare JID" (user@domain.tld) of the >>>>>>> XMPP user, to which the user's XMPP server MUST respond in >>>>>>> accordance >>>>>>> with [RFC6121]; however, the administrator of an XMPP-SIP >>>>>>> gateway MAY >>>>>>> (based on local service provisioning) exempt "known good" XMPP >>>>>>> servers from this check (e.g., the XMPP server associated with >>>>>>> the >>>>>>> XMPP-SIP gateway as described above)." >>>>>>> >>>>>>> is unclear: how does it help? >>>>>> >>>>>> >>>>>> This check at least places a burden on the XMPP server itself and >>>>>> verifies if the XMPP user has an active presence session before >>>>>> updating >>>>>> the presence subscription on the SIP side of the gateway. >>>>>> >>>>>> I'll think about the matter more deeply and formulate some better text. >>>>> >>>>> >>>>> How is this? >>>> >>>> Better, but... >>>> >>>>> >>>>> The mismatch between long-lived XMPP presence subscriptions and >>>>> short-lived SIP presence subscriptions introduces the possibility of >>>>> an amplification attack launched from the XMPP network against a SIP >>>>> presence server (since each long-lived XMPP presence subscription >>>>> would typically result in multiple subscription refresh requests on >>>>> the SIP side of a gateway). Therefore, access to an XMPP-SIP >>>>> gateway >>>>> SHOULD be restricted in various ways; among other things, only an >>>>> XMPP service that carefully controls account provisioning ought to >>>>> host such a gateway (e.g., not a service that offers open account >>>>> registration) and a gateway ought to be associated only with a >>>>> single >>>>> >>>>> domain or trust realm (e.g., a gateway hosted at simple.example.com >>>>> ought to allow only users within the example.com domain to access >>>>> the >>>>> gateway, not users within example.org, example.net, or any other >>>>> domain). >>>> >>>> ...I suspect the criterion you are really trying to capture is that >>>> their should be some kind of administrative link between the XMPP >>>> server and its users (i.e. abusers can be permanently kicked off, if >>>> needed). Perhaps better to say that directly? >>> >>> Yes, that's part of it but not all of it. For instance, I run the >>> jabber.org IM service, which has 1.4 million users or so. The other >>> admins and I definitely have the ability to permanently disable user >>> accounts, we have user registration locked down, we have rate limiting >>> in place, etc. -- but there's no way we'd ever offer a gateway of the >>> kind described in this document because we have too many users to know >>> them all or have any truly effective control over them. If I were >>> running an XMPP service at a company (even a company with 100,000 >>> employees) I'd be comfortable offering a gateway, because the company >>> could always fire someone who does something wrong. >>> >>> I'll try again to rework the text to capture some of these ideas. >> >> A further text tweak: >> >> The mismatch between long-lived XMPP presence subscriptions and >> short-lived SIP presence subscriptions introduces the possibility of >> an amplification attack launched from the XMPP network against a SIP >> presence server (since each long-lived XMPP presence subscription >> would typically result in multiple subscription refresh requests on >> the SIP side of a gateway). Therefore, access to an XMPP-SIP gateway >> SHOULD be restricted in various ways; among other things, only an >> XMPP service that carefully controls account provisioning and >> provides effective methods for the administrators to control the >> behavior of registered users ought to host such a gateway (e.g., not >> a service that offers open account registration) and a gateway ought >> to be associated only with a single domain or trust realm (e.g., a >> gateway hosted at simple.example.com ought to allow only users within >> the example.com domain to access the gateway, not users within >> example.org, example.net, or any other domain). If a SIP presence >> server receives communications through an XMPP-SIP gateway from users >> who are not associated with a domain that is so related to the >> hostname of the gateway, it SHOULD (based on local service >> provisioning) refuse to service such users or refuse to receive >> traffic from with the gateway. As a futher check, whenever an XMPP- >> SIP gateway seeks to refresh an XMPP user's long-lived subscription >> to a SIP user's presence, it MUST first send an XMPP >> stanza of type "probe" from the address of the gateway to the "bare >> JID" (user@domain.tld) of the XMPP user, to which the user's XMPP >> server MUST respond in accordance with [RFC6121]; this puts an equal >> burden on the XMPP server as on the SIP server. > > Sounds good to me. Great. As soon as Pete tells me he likes the other changes I made to address the issues he raised in his DISCUSS, I'll submit a revised I-D. Peter -- Peter Saint-Andre https://stpeter.im/ From ron.even.tlv@gmail.com Thu Feb 6 01:09:19 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B70D1A00A3; Thu, 6 Feb 2014 01:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gF1U92bJvpx; Thu, 6 Feb 2014 01:09:15 -0800 (PST) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 03C3E1A01FB; Thu, 6 Feb 2014 01:09:14 -0800 (PST) Received: by mail-ea0-f174.google.com with SMTP id b10so742974eae.19 for ; Thu, 06 Feb 2014 01:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=AyyRiyFnJe9NOYgu2stfuIhnhOh15nuMN+q9/Z+n+js=; b=h8/95moC9+6tFhsSJWL1gBUUxdE+02SXfY++9xfsiiS9xEcFnpP6Ky6GLIzTQMRQEs +GNuFSG1PMm1gVNmg8fSVT7+OWmSyMGKqPiR9b0eHKGvyqxsaIVReGe3zmkCVtMDOQlR qgXrDMEutReOiBs9DRpKRtyRZoGF0dJsxlAlO/BQO5ptlAp3GYZPlIhcTX5uTWd9n77H vLX5nNJSuN9Xy9oGwmkSPPVr2jey9JgWODDs1rMSQeAAMBx6L0h3j5G0kLNu6kjX3112 gSvdkmEoTN+O/mK6G4dGx2G4AhttoirevicONxu+PtL/mMRX82kkLY0sdmxKYqOlxFP+ TNiA== X-Received: by 10.14.210.130 with SMTP id u2mr4746673eeo.108.1391677753563; Thu, 06 Feb 2014 01:09:13 -0800 (PST) Received: from RoniE (bzq-79-177-0-245.red.bezeqint.net. [79.177.0.245]) by mx.google.com with ESMTPSA id u6sm1121347eep.11.2014.02.06.01.09.09 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 06 Feb 2014 01:09:12 -0800 (PST) From: "Roni Even" To: "'Klaas Wierenga \(kwiereng\)'" , "'Roni Even'" References: <521F1B37-7D82-485C-AA8F-624695BC5797@cisco.com> <760B7D45D1EFF74988DBF5C2122830C23E54F3CF@szxpml507-mbx.exmail.huawei.com> <9FF8C147-4F05-4A56-B36A-615858D46882@cisco.com> In-Reply-To: <9FF8C147-4F05-4A56-B36A-615858D46882@cisco.com> Date: Thu, 6 Feb 2014 11:09:03 +0200 Message-ID: <05bb01cf231b$19a7a4e0$4cf6eea0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJF/Ua/hsN4gdd2jLS/6a+vCQ3VggJl8p41Anh73vaZk0fmgA== Content-Language: en-us X-Mailman-Approved-At: Fri, 07 Feb 2014 10:21:18 -0800 Cc: iesg@ietf.org, draft-ietf-p2psip-rpr.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-p2psip-rpr-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 09:09:19 -0000 Hi Klaas, We will add the sentence to the security section and can take out the trusted. Thanks Roni > -----Original Message----- > From: Klaas Wierenga (kwiereng) [mailto:kwiereng@cisco.com] > Sent: 03 February, 2014 3:33 PM > To: Roni Even > Cc: draft-ietf-p2psip-rpr.all@tools.ietf.org; secdir@ietf.org; iesg@ietf.org; > ron.even.tlv@gmail.com > Subject: Re: Secdir review of draft-ietf-p2psip-rpr-11 > > > On Feb 3, 2014, at 2:06 PM, Roni Even wrote: > > Hi Roni, > > > Thanks for the comments. > > In order to use a relay, the peer need to learn who is the relevant > > relay as described in section 3.1 and 3.2 so they are not arbitrary > > peers, furthermore section 4.1 says that a relay can limit the number > > of connections. > > So what happens if a relay has reached that maximum? Doesn't that mean that > the relay has become effectively unusable? But since my SPOF comment > doesn't seem to hold this is not much of an issue. > > > The relay is used for the response path. The source establish a > > connection to a relay known to him and if succeed send the information > > in the outgoing message. The response should come from the target peer. > > > > So the general security in RFC6490 will work. The relay is not a point > > of failure since this is an optional mechanism and if the > > communication fails the routing will fall back to SRR. > > ah ok, the sentence "If peer A knows it is behind a NAT or NATs, and knows one > or more > relay peers with whom they have a prior connections, peer A can try > RPR. " in 3.1 threw me off. I missed that there was in any case an established > connection from A to B. So if I now understand correctly, you are dealing with a > case in which SRR is in any case also always possible? > > > > > We can add some sentence in the security section about the relay > > limiting the number of connections and maybe about verifying that the > > connection request for the response is from the destination peer in > > the outgoing message if the relay will keep state (not recommended) > > I think that is useful > > > > > As for being trusted, I think you are right, the relay need to comply > > with the security specifications in RFC6490. > > ok > > > > > BTW: Sorry for not responding earlier bur this was probably since the > > email sent to draft-ietf-p2psip-rpr-10.all@tools.ietf.org so it did not reach us. > > arghhh, I need to say sorry here, I clearly was a bit too hasty with my > copy/paste of the draft name! > > Klaas > > > > > Roni Even > > > > ________________________________________ > > From: Klaas Wierenga (kwiereng) [kwiereng@cisco.com] > > Sent: Thursday, January 30, 2014 11:19 AM > > To: draft-ietf-p2psip-rpr.all@tools.ietf.org > > Cc: secdir@ietf.org; iesg@ietf.org > > Subject: Secdir review of draft-ietf-p2psip-rpr-11 > > > > Hi, > > > > I reviewed earlier version 10 (http://www.ietf.org/mail- > archive/web/secdir/current/msg04256.html), I didn't get any response and the > security considerations don't seem to address what I wrote at that time, so I'll > repeat: > > > > -- > > Hi, > > > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area directors. > Document editors and WG chairs should treat these comments just like any > other last call comments. > > > > This document defines an optional extension to RELOAD to support Relay > Peer Routing (RPR) mode (as opposed to Symmetric Recursive Routing (SRR). > The document is straightforward and clear, but with respect to the security > considerations a few comments: > > > > - I am surprised that there is no discussion on the relay peer being the single > (or few) point of failure, and thus becoming an interesting target for DoS > attacks: the relay peer acts as a hub for all traffic coming from the peers that > have it as their relay. Especially when there is a limited number of relays it > becomes attractive to bring the relay down. > > > > - The other thing I wonder about is why there is the need to trust the relay, > why is this different from the DRR case (apart from the observation in my > previous comment)? It seems that the system would work just fine without the > explicit trust in the relay peer, in fact, the way I understand it every peer in the > overlay can in principle act as a relay peer (I imagine a scenario where the > relay peer acts as the "established connection"). > > > > Cheers, > > > > Klaas Wierenga > > -- > > From new-work-bounces@ietf.org Fri Feb 7 09:20:49 2014 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6501A1ACCE3; Fri, 7 Feb 2014 09:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1391793649; bh=uwpc7C4/L2Ce+BoIilft0CcPk0gQRpUgjVV0UnJAtO8=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=XSz+Tf+BQLxBlzwnLVB33Q5QcWqCMzBw+6dPa4jzEujTftMNdq/b/pB02bea5CtTS NGUGLJEqJ5sk1XPgVBhupkH8qq6NyhO0IN6/CKjY116C0rfR68gfxZ4VrYvu4X6/TT 8zxrij023Pe3/e+CLZdrIg7JfW4zzW+lAWjBi3iQ= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9A51AC7F2 for ; Fri, 7 Feb 2014 09:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWI4z5k9E3UU for ; Fri, 7 Feb 2014 09:20:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BC11A0416 for ; Fri, 7 Feb 2014 09:20:28 -0800 (PST) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140207172027.3534.40473.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2014 09:20:27 -0800 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" X-Mailman-Approved-At: Fri, 07 Feb 2014 10:21:18 -0800 Subject: [secdir] [new-work] WG Review: TURN Revised and Modernized (tram) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 17:20:49 -0000 A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-02-17. TURN Revised and Modernized (tram) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Spencer Dawkins Mailing list Address: tram@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tram Archive: http://www.ietf.org/mail-archive/web/tram/current/maillist.html Charter: Traversal Using Relays around NAT (TURN) was published as RFC 5766 in April 2010. Until recently the protocol had seen rather limited deployment. This is largely because its primary use case is as one of the NAT traversal methods of the Interactive Connectivity Establishment (ICE) framework (RFC 5245), and ICE itself was slow to achieve widespread adoption, as other mechanisms were already being used by the VoIP industry. This situation has changed drastically as ICE, and consequently TURN, are mandatory to implement in WebRTC, a set of technologies developed at the IETF and W3C to standardize Real Time Communication on the Web. Together with the arrival of WebRTC, there is a renewed interest in TURN and ICE, as evidenced by recent work updating the ICE framework (still in progress), and standardizing the URIs used to access a STUN (RFC 7064) or TURN (RFC 7065) server. The goal of the TRAM Working Group is to consolidate the various initiatives to update TURN and STUN to make them more suitable for the WebRTC environment. The work will include the addition of DTLS as an additional transport, authentication mechanisms, and extensions to TURN and STUN. The Working Group will closely coordinate with the appropriate Working Groups, including RTCWEB, MMUSIC, and HTTPBIS. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Fri Feb 7 09:34:20 2014 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57FB31ACCE2; Fri, 7 Feb 2014 09:34:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1391794460; bh=uIKTc+JLKzmwTj/Qv0suuLg/XIQgjAjBRMknbOgx4zc=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=yz7xO6zzdPw/wyX4Cl+qaxZTMsB0p2Uw7Oe0SIyDbDKoN1/C8HskJqQT5aPe7T9Cy sNlRxpKAgTtuLjw9tNySh/VuM5Rt6uiNBRYMUldTuC9vA427LWg7zSTIgnW6XErhXs uQATG2JZvlTttnLQpcdA4EdezSqwA54HeK42xQ08= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7211A0425; Fri, 7 Feb 2014 09:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkNLxMubE5W2; Fri, 7 Feb 2014 09:34:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2851AC421; Fri, 7 Feb 2014 09:34:08 -0800 (PST) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140207173408.24258.44182.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2014 09:34:08 -0800 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" X-Mailman-Approved-At: Fri, 07 Feb 2014 10:21:19 -0800 Subject: [secdir] [new-work] WG Review: Network Configuration (netconf) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 17:34:20 -0000 The Network Configuration (netconf) working group in the Operations and Management Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-02-17. Network Configuration (netconf) ------------------------------------------------ Current Status: Active WG Chairs: Bert Wijnen Mehmet Ersue Assigned Area Director: Benoit Claise Mailing list Address: netconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netconf Archive: http://www.ietf.org/mail-archive/web/netconf/ Charter: Configuration of networks of devices has become a critical requirement for operators in today's highly interconnected networks. Large and small operators alike have developed their own mechanisms or have used vendor specific mechanisms to transfer configuration data to and from a device and to examine device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF protocol (RFC 6241) provides mechanisms to install, manipulate, and delete the configuration of network devices. NETCONF is based on the secure transport (SSH is mandatory to implement while TLS is an optional transport) and uses an XML-based data representation. The NETCONF protocol is data modeling language independent, but YANG (RFC 6020) is the recommended NETCONF modeling language, which introduces advanced language features for configuration management. Based on the implementation, deployment experience and interoperability testing, the WG aims to produce a NETCONF status report in a later stage. The result may be clarifications for RFC6241 and RFC6242 and addressing any reported errata. In the current phase of NETCONF's incremental development the workgroup will focus on following items: 1. Develop the call home mechanism for the mandatory SSH binding (Reverse SSH) providing a server-initiated session establishment. 2. Develop a zero touch configuration document (a technique to establish a secure network management relationship between a newly delivered network device configured with just its factory default settings, and the Network Management System), specific to the NETCONF use case. 3. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., update RFC 5539) and add the call home mechanism to provide a server-initiated session establishment. 4. Combine the server configuration data models from Reverse SSH and RFC5539bis drafts in a separate call home YANG module. 5. Develop RESTCONF, a protocol based on NETCONF in terms of capabilities, but over HTTP and with some REST characteristics, for accessing YANG data using the datastores defined in NETCONF. An "ordered edit list" approach is needed (the YANG patch) to provide client developers with a simpler edit request format that can be more efficient and also allow more precise client control of the transaction procedure than existing mechanisms. The YANG patch operation, based on the HTTP PATCH method, will be prepared in a separate draft. RESTCONF should not deviate from the NETCONF capabilities unless proper justification is provided and documented. The RESTCONF work will consider requirements suggested by the other working groups (for example I2RS). Milestones: Feb 2014 - Submit initial WG draft for call home YANG module as WG item Feb 2014 - Submit initial WG draft for zero touch configuration as WG item Feb 2014 - Submit initial WG drafts for RESTCONF and patch operation as WG items Apr 2014 - WGLC for Reverse SSH Apr 2014 - WGLC for NETCONF server configuration data model Apr 2014 - WGLC for zero touch configuration Apr 2014 - WGLC for call home YANG module Apr 2014 - WGLC for RFC5539bis May 2014 - Submit call home YANG module to AD/IESG for consideration as Proposed Standard May 2014 - Submit zero touch configuration to AD/IESG for consideration as Proposed Standard May 2014 - Submit RFC5539bis to AD/IESG for consideration as Proposed Standard May 2014 - Submit Reverse SSH and and zero touch configuration to AD/IESG for consideration as Proposed Standard Jun 2014 - WGLC for RESTCONF and patch operation drafts Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From ralimi@google.com Sun Feb 9 22:58:49 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07311A07B7 for ; Sun, 9 Feb 2014 22:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKIen1Hi3TXe for ; Sun, 9 Feb 2014 22:58:46 -0800 (PST) Received: from mail-vb0-x22a.google.com (mail-vb0-x22a.google.com [IPv6:2607:f8b0:400c:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEC01A07B3 for ; Sun, 9 Feb 2014 22:58:45 -0800 (PST) Received: by mail-vb0-f42.google.com with SMTP id i11so1341278vbh.1 for ; Sun, 09 Feb 2014 22:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=upisA1uX4yVAyscGeUuvnOR4GISZtAlorVvDfy+q72Q=; b=d/oC1VfyBcC2WTQuNOdlBQTB13JPv4AUfoND+a39uvFnErpm+3UOjRlF9IfljYgzH8 Quqf5zELXltgPu6G7+dUs6JcE8GkDuPnzPNNb+Ie2jo2+W80lWVEWGUVwcmdZFo+zgJo GKCZOxE9puKsjOg7vPPzZGdnGi8ZkUzX7pnYGtLsJZIcaZn4UriUBwJAuYJleWy9V28B iWu7e7odSo4I//yThbTcQb/N9Zwp2SKDlgueebo4n9twrd3SSp9KVdi++UUOY4q/hIYn Nj/oW9sm3o1KZVteJpiOGzIk31qOsHIPZJ6nMQVhdXrK2yjCFFxIurez0ggWPvlhpsXv GPsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=upisA1uX4yVAyscGeUuvnOR4GISZtAlorVvDfy+q72Q=; b=fBdxEZjR4FqGpwzPIEOZDdH+xTmGlMI5T0/BOf3MBv2+Szm6Mwvy1ESGeByw4Q9u8W OkT81B5xbK5wFBa9pN/KaQQohMsuQsPEyjeqML00ev1dZ/NLtEaLq4++tIcjAsozBM6n mm/20w3vX6nvkRl4P1pflhHoCW7cWsHPk8mSPoTb5HbVhrkpnNpjqFdfWn1Fwrw2va+R MutVwTikiBzqt16xT3XrAVZtfzvTe2ofN68L8fiIUfErfzPTip/0slO2wETjXeRF9IAt l/wN0vZke70/O69iDAsssavIBTKlE9RQsg4A7dzPyTLbdQzP1kH7uwysSGOx9mhDXNm2 i/PA== X-Gm-Message-State: ALoCoQno2bhGx+5D1S47FR9InOQGnq1Y2RU/UKzdLN7ocQ3B8zAtyQTATa0jR0HOwvalJIaOAWku3uFwSKtxxdU7SpZQvdeYV+bpKZYTtq+hwQxflEl/HzApgAOVoKIdLzjm/PptNQQcx3gAR649aBTXY/dFrCjAGO+PLJ2A0v/dtC8mlt+Dl8M4YvNvvhv2/7rhrqbQDDAX X-Received: by 10.52.171.39 with SMTP id ar7mr18779470vdc.5.1392015525104; Sun, 09 Feb 2014 22:58:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.38.193 with HTTP; Sun, 9 Feb 2014 22:58:15 -0800 (PST) In-Reply-To: References: From: Richard Alimi Date: Sun, 9 Feb 2014 22:58:15 -0800 Message-ID: To: Dan Harkins Content-Type: multipart/alternative; boundary=047d7bacb738e56c6904f207de98 X-Mailman-Approved-At: Mon, 10 Feb 2014 03:02:41 -0800 Cc: "draft-ietf-alto-protocol.all@tools.ietf.org" , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-alto-protocol X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 06:58:49 -0000 --047d7bacb738e56c6904f207de98 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you very much for the review! Responses inline... On Sat, Feb 1, 2014 at 10:54 AM, Dan Harkins wrote: > > 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 defines a protocol that allows a server to provide network > location information, network structure and network cost/preference > to a client which then can build an abstract view of the network in > order to determine how best to use it. > > This draft is "ready with nits" (per secdir review instructions). And > those nits are: > > - 6.1.1.1 mixes the idea of "cost" and "preference". While it's > natural for people to prefer lower cost I think it would be better > to say so explicitly: "A lower value indicates a lower cost" or > this field "conveys a generic measure indicating preference for > routing traffic from source to destination" or something like > that. > Agreed. We can clarify this section. > > - 6.1.2, while a particular Cost Map may contain only one of the > two cost modes, servers MUST implement support for both, > right? It's not clear from the text. > Servers only need to implement at least one, but not necessarily both. Section 6.1.2 states the following: An ALTO Server MUST support at least one of 'numerical' and 'ordinal' modes. Can you suggest which text was misleading so that we can address it? > - 6.3, since the tag must not contain ASCII characters below > 0x21 or above 0x7e you can't really construct one from the > hash of the contents of a Network Map. Also, given those > restrictions and the fact that a tag just has to be less than > or equal to 64 octets, the probability of identical tags being > used is not zero. I think the probability of the tag from > example 11.3.1.7 is 0.5 to collide with one of just 460 > other Network Maps. > > I suggest requiring a tag to be 64 octets. That will make > even money probability of collision among nearly 3000 > other Network Maps, which is safer. > [will reply to this later in the thread] > > - 8.3.5, encryption and integrity protection go hand-in-hand, > they cannot be "and/or". Suggest changing the sentence to > "When confidentiality and data integrity between client and > server are required, and server and/or client authentication > is required=E2=80=A6." This section should refer to section 15 (Secu= rity > Considerations). > We'll resolve this by rewording to "integrity protection and/or encryption" as you suggest below. > > - 11.3.2.6, what does it mean for a Version Tag to be > "consistent with" another Version Tag? Do you mean that > they are "identical"? Same length and same value? Or would > "0004579342" be "consistent" with "4579342"? > We will reword to say "equal to" instead of "consistent with". Section 10.3 defines equality as: Two values of the VersionTag are equal if and only if both the the 'resource-id' attributes are byte-for-byte equal and the 'tag' attributes are byte-for-byte equal. > > - 15.3.1, the ALTO data can be sensitive since it includes > things like endpoint addresses (useful for those who like > to monitor the Internet). I think risk (2) here should include > mention of that. There may be classes of ALTO data for > which certain clients are authorized to receive and others > are not. > That sounds good. Does the following sound reasonable? ... Disclosure of the ALTO service provider's data (e.g., network topology information or endpoint addresses) to an unauthorized third party ... > > - 15.3.2, the Security Considerations section seems an odd > place for normative language-- "HTTP Digest authentication > MUST be supported". I suggest finding a more appropriate > place, perhaps 8.3.5, to spell out normative requirements. > Also, authenticating the client in the TLS exchange would > be much preferable and I think mention should be made > on that option. I think differentiated authorization (see > my previous comment) would be easier this way too. > Good point - we will move the normative requirement for HTTP digest authentication to 8.3.5. The existing text in 8.3.5 states When server and/or client authentication, encryption, and/or integrity protection are required, an ALTO Server MUST support SSL/ TLS [RFC5246 ] as a mechanism. Should I interpret your comment to say that we should suggest TLS client authentication over HTTP digest authentication, or to reword to make it more explicit that TLS client authentication is an option? > - 15.4.2, authorization of an authenticated client is another > useful protection strategy here-- some client's may get > obfuscated data, and some may get the raw data. > Good point. We will explicitly mention authorization here as well. > > I think the Security Considerations are well done. > Thanks! > > regards, > > Dan. > > > > > --047d7bacb738e56c6904f207de98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you very much for the review!

Res= ponses inline...


On Sat, Feb 1, 2014 at 10:54 AM, Dan Harkins <= ;dharkins@lounge.o= rg> wrote:

=C2=A0 Hello,

=C2=A0 I have reviewed this document as part of the security directorate= 9;s
ongoing effort to review all IETF documents being processed by the
IESG. =C2=A0These comments were written primarily for the benefit of the security area directors. =C2=A0Document editors and WG chairs should treat<= br> these comments just like any other last call comments.

=C2=A0 This draft defines a protocol that allows a server to provide networ= k
location information, network structure and network cost/preference
to a client which then can build an abstract view of the network in
order to determine how best to use it.

=C2=A0 This draft is "ready with nits" (per secdir review instruc= tions). And
those nits are:

=C2=A0 - 6.1.1.1 mixes the idea of "cost" and "preference&qu= ot;. While it's
=C2=A0 =C2=A0 natural for people to prefer lower cost I think it would be b= etter
=C2=A0 =C2=A0 to say so explicitly: "A lower value indicates a lower c= ost" or
=C2=A0 =C2=A0 this field "conveys a generic measure indicating prefere= nce for
=C2=A0 =C2=A0 routing traffic from source to destination" or something= like
=C2=A0 =C2=A0 that.

Agreed. We can clar= ify this section.
=C2=A0

=C2=A0 - 6.1.2, while a particular Cost Map may contain only one of the
=C2=A0 =C2=A0 =C2=A0two cost modes, servers MUST implement support for both= ,
=C2=A0 =C2=A0 =C2=A0right? It's not clear from the text.

Servers only need to implement at least one, but not = necessarily both. =C2=A0Section 6.1.2 states the following:
<= br>

   An ALTO Server MUST support at least one of 'numerical' and '=
;ordinal'
   modes.
=C2=A0
Can you suggest which text was m= isleading so that we can address it?


=C2=A0 - 6.3, since the tag must not contain ASCII characters below
=C2=A0 =C2=A0 =C2=A00x21 or above 0x7e you can't really construct one f= rom the
=C2=A0 =C2=A0 =C2=A0hash of the contents of a Network Map. Also, given thos= e
=C2=A0 =C2=A0 =C2=A0restrictions and the fact that a tag just has to be les= s than
=C2=A0 =C2=A0 =C2=A0or equal to 64 octets, the probability of identical tag= s being
=C2=A0 =C2=A0 =C2=A0used is not zero. I think the probability of the tag fr= om
=C2=A0 =C2=A0 =C2=A0example 11.3.1.7 is 0.5 to collide with one of just 460=
=C2=A0 =C2=A0 =C2=A0other Network Maps.

=C2=A0 =C2=A0 =C2=A0I suggest requiring a tag to be 64 octets. That will ma= ke
=C2=A0 =C2=A0 =C2=A0even money probability of collision among nearly 3000 =C2=A0 =C2=A0 =C2=A0other Network Maps, which is safer.

[will reply to this later in the thread]
=C2=A0<= /div>

=C2=A0 - 8.3.5, encryption and integrity protection go hand-in-hand,
=C2=A0 =C2=A0 =C2=A0they cannot be "and/or". Suggest changing the= sentence to
=C2=A0 =C2=A0 =C2=A0"When confidentiality and data integrity between c= lient and
=C2=A0 =C2=A0 =C2=A0server are required, and server and/or client authentic= ation
=C2=A0 =C2=A0 =C2=A0is required=E2=80=A6." This section should refer t= o section 15 (Security
=C2=A0 =C2=A0 =C2=A0Considerations).

We= 'll resolve this by rewording to "integrity=C2=A0protection and/or encryption" as yo= u suggest below.
=C2=A0

=C2=A0 - 11.3.2.6, what does it mean for a Version Tag to be
=C2=A0 =C2=A0 =C2=A0"consistent with" another Version Tag? Do you= mean that
=C2=A0 =C2=A0 =C2=A0they are "identical"? Same length and same va= lue? Or would
=C2=A0 =C2=A0 =C2=A0"0004579342" be "consistent" with &= quot;4579342"?

We will reword to s= ay "equal to" instead of "consistent with".
<= br>
Section 10.3 defines equality as:

 =
  Two values of the VersionTag are equal if and only if both the the
   'resource-id' attributes are byte-for-byte equal and the 'ta=
g'
   attributes are byte-for-byte equal.
=C2=A0

=C2=A0 - 15.3.1, the ALTO data can be sensitive since it includes
=C2=A0 =C2=A0 =C2=A0things like endpoint addresses (useful for those who li= ke
=C2=A0 =C2=A0 =C2=A0to monitor the Internet). I think risk (2) here should = include
=C2=A0 =C2=A0 =C2=A0mention of that. There may be classes of ALTO data for<= br> =C2=A0 =C2=A0 =C2=A0which certain clients are authorized to receive and oth= ers
=C2=A0 =C2=A0 =C2=A0are not.

That sound= s good. Does the following sound reasonable?

...= =C2=A0Disclosure of the ALTO= service=C2=A0provide= r's data (e.g., network topology information or endpoint addresses) to = an=C2=A0unauthorized = third party ...
=C2=A0

=C2=A0 - 15.3.2, the Security Considerations section seems an odd
=C2=A0 =C2=A0 =C2=A0place for normative language-- "HTTP Digest authen= tication
=C2=A0 =C2=A0 =C2=A0MUST be supported". I suggest finding a more appro= priate
=C2=A0 =C2=A0 =C2=A0place, perhaps 8.3.5, to spell out normative requiremen= ts.
=C2=A0 =C2=A0 =C2=A0Also, authenticating the client in the TLS exchange wou= ld
=C2=A0 =C2=A0 =C2=A0be much preferable and I think mention should be made =C2=A0 =C2=A0 =C2=A0on that option. I think differentiated authorization (s= ee
=C2=A0 =C2=A0 =C2=A0my previous comment) would be easier this way too.
<= /blockquote>

Good point - we will move the normative req= uirement for HTTP digest authentication to 8.3.5. =C2=A0The existing text i= n 8.3.5 states

   When server and/or client authenticat=
ion, encryption, and/or
   integrity protection are required, an ALTO Server MUST support SSL/
   TLS [RFC5246] as a=
 mechanism.
Should I interpret your comment to say that we should suggest TLS= client authentication over HTTP digest authentication, or to reword to mak= e it more explicit that TLS client authentication is an option?


<=
/span>

=C2=A0 - 15.4.2, authorization of an authenticated client is another
=C2=A0 =C2=A0 =C2=A0useful protection strategy here-- some client's may= get
=C2=A0 =C2=A0 =C2=A0obfuscated data, and some may get the raw data.

Good point. We will explicitly mention authori= zation here as well.
=C2=A0

=C2=A0 I think the Security Considerations are well done.
<= div>
Thanks!
=C2=A0

=C2=A0 regards,

=C2=A0 Dan.





--047d7bacb738e56c6904f207de98-- From ralimi@google.com Sun Feb 9 23:03:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0F11A07B5 for ; Sun, 9 Feb 2014 23:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeI1vSu7FfwR for ; Sun, 9 Feb 2014 23:03:52 -0800 (PST) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 97F001A069C for ; Sun, 9 Feb 2014 23:03:52 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id ik5so4449400vcb.37 for ; Sun, 09 Feb 2014 23:03:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9oVx4jIprHP/3+E0JdI/D76PG5ksc3WqaORJUXrXKFQ=; b=miaZTiuMChJqEWjcU4Qjd2BMwJS128j5t5ZKIiInOqp1LWDL0WLt46BcwFtBrjRjL5 IEIC+x1y2OLU/dLK7Bpw4uVaUegTA0vvC7XriWW294/KeP7G7rFcA7wCYOuLVUZ/sPbo jWfmAFHstBYaY6lhf7j9IsfkD7xW6xf5oYTtoFjCsAKrgzAyBJ/iDeDDpyXUKz+UfKJ8 V6Du3EhMFcb+QA8ZwYcBpZh4oY3jLvV+K1LKJBVao9kemA5QeSRILYB+gEPolKT18VxH sWBOy+B3GSpcYY0bkSGELlyBjhtnInR+v3FetMA8aB8iNxo/GSMQrAL20JlfJDHdjy+4 1wsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9oVx4jIprHP/3+E0JdI/D76PG5ksc3WqaORJUXrXKFQ=; b=WdhNjELZIKax6IlSZPU2KPz+oN8LpB6sHnhAe0UADmUbi2mBfIA1FnVm4sZrVxoFk4 1FFjmLciCvjBdJ/UGm2ZjXR2oI1sk4fMbgB1Fv3UylCs3eU3H+YLeYknbTP/0QRxfhpK 05f+lOQt8fEUeyEDeTMGCRMUd24BsLyhNlZXhMtTKW/Nqt/kxG6xvUaOHWsr6nlvR990 F9/0Z9KtLau6lORWi6oHanPnlNkgNRTu+N9xXaV3jceR98wAVS79VVroBj+pjU2A7/ES g5j32XZRQTT+3VKx377pkRY9e81H5g1L6XkIH9XESRFrC5L3iF6sT9fgJ6emU1XJMk5b PiGQ== X-Gm-Message-State: ALoCoQlKey589QU/HiZdvDA3cXllu1y8x0rSnsU8n1Tn8i3UZYJHBh6X3saOQk5F9CM/bVfQ95HnPE3pRnIRXbI9XWR6BwTqaKKFMv8DLwjzWM2Q78ttaL0jjJllrdloLSpEtP7wCCC/clbQbYRkdxihWVOnxzDsrreRMnUejtfZgZpFcxoRvWhs5KqjFderWD1111TyxSYM X-Received: by 10.58.207.13 with SMTP id ls13mr23062162vec.13.1392015832419; Sun, 09 Feb 2014 23:03:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.38.193 with HTTP; Sun, 9 Feb 2014 23:03:22 -0800 (PST) In-Reply-To: <943e83dcb64a8666ea82900f013b2b9b.squirrel@www.trepanning.net> References: <23845_1391280851_s11IsAD0008772_cd3fb9f2748d08183af6652c0d58f61a.squirrel@www.trepanning.net> <1391369584.4360.72.camel@destiny.pc.cs.cmu.edu> <943e83dcb64a8666ea82900f013b2b9b.squirrel@www.trepanning.net> From: Richard Alimi Date: Sun, 9 Feb 2014 23:03:22 -0800 Message-ID: To: Dan Harkins Content-Type: multipart/alternative; boundary=047d7b676bf836ad0d04f207f125 X-Mailman-Approved-At: Mon, 10 Feb 2014 03:02:41 -0800 Cc: secdir@ietf.org, "draft-ietf-alto-protocol.all@tools.ietf.org" , iesg@ietf.org, Jeffrey Hutzelman Subject: Re: [secdir] secdir review of draft-ietf-alto-protocol X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 07:03:55 -0000 --047d7b676bf836ad0d04f207f125 Content-Type: text/plain; charset=UTF-8 On Sun, Feb 2, 2014 at 7:08 PM, Dan Harkins wrote: > > On Sun, February 2, 2014 11:33 am, Jeffrey Hutzelman wrote: > > On Sat, 2014-02-01 at 10:54 -0800, Dan Harkins wrote: > > > >> Also, given those > >> restrictions and the fact that a tag just has to be less than > >> or equal to 64 octets, the probability of identical tags being > >> used is not zero. I think the probability of the tag from > >> example 11.3.1.7 is 0.5 to collide with one of just 460 > >> other Network Maps. > >> > >> I suggest requiring a tag to be 64 octets. That will make > >> even money probability of collision among nearly 3000 > >> other Network Maps, which is safer. > > > > OK, maybe I'm confused and reading out of context here. But I once had > > someone tell me I needed to change my 5-character username because they > > were requiring all usernames to be at least 6 characters, _in order to > > increase the number of possible usernames_. That is, they claimed they > > were increasing the size of a namespace by eliminating possible names. > > Well that's a hair brained policy, but username selection is not a good > analogy. I was at a company that had no strict requirements on a username > so there should have been a near infinite size of the namespace. But we had > a collision when the company had less than 10 employees because there > was another "dan" at the company. > > > The point is, if a tag is required to be exactly 64 octets, you get > > 0x5e^64 possible tags. But if it is required to be up to 64 octets, you > > get Sum(i=0..64) 0x5e^i possible tags, which is strictly greater than > > 0x5e^64. So, requiring a tag to be 64 octets _reduces_ the number of > > possible tags, thereby increasing the chance of collision. > > That would be the case if all tags in the Sum(i=1..64) 0x5e^i tagspace > were equally probable of being chosen. Which implies implementations > choosing a random tag length for each tag generated in addition to a > random tag selection scheme for the randomly chosen length. I suspect, > though, that in practice the tag length will be fixed for a particular > implementation and the tag selection scheme will not necessarily be > random. So the herd mentality, plus the proliferation of one or two > companies' ALTO servers, will result in a severely reduced size of the > effective tagspace and the increased possibility of collisions. > > A tag generated as SHA256(NetworkMap) represented in 64 hex > characters would basically guarantee you'd never have a collision. > Saying, "it can be anything you want as long as it's less than 64 > octets" would not. > Should I interpret your comment to say that we should to require particular mechanisms for generating version tags, or be more explicit about suggesting mechanisms that have a low collision probability? To help steer readers towards better implementation practices, we'll change the examples to use hashes in the version tags. Thank you again for the review! > > Dan. > > > > --047d7b676bf836ad0d04f207f125 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sun, Feb 2, 2014 at 7:08 PM, Dan Harkins <dharkins@lounge.org&g= t; wrote:

On Sun, February 2, 2014 11:33 am, Jeffrey Hutzelman wrote:
> On Sat, 2014-02-01 at 10:54 -0800, Dan Harkins= wrote:
>
>> =C2=A0Also, given those
>> =C2=A0 =C2=A0 =C2=A0restrictions and the fact that a tag just has = to be less than
>> =C2=A0 =C2=A0 =C2=A0or equal to 64 octets, the probability of iden= tical tags being
>> =C2=A0 =C2=A0 =C2=A0used is not zero. I think the probability of t= he tag from
>> =C2=A0 =C2=A0 =C2=A0example 11.3.1.7 is 0.5 to collide with one of= just 460
>> =C2=A0 =C2=A0 =C2=A0other Network Maps.
>>
>> =C2=A0 =C2=A0 =C2=A0I suggest requiring a tag to be 64 octets. Tha= t will make
>> =C2=A0 =C2=A0 =C2=A0even money probability of collision among near= ly 3000
>> =C2=A0 =C2=A0 =C2=A0other Network Maps, which is safer.
>
> OK, maybe I'm confused and reading out of context here. =C2=A0But = I once had
> someone tell me I needed to change my 5-character username because the= y
> were requiring all usernames to be at least 6 characters, _in order to=
> increase the number of possible usernames_. =C2=A0That is, they claime= d they
> were increasing the size of a namespace by eliminating possible names.=

=C2=A0 Well that's a hair brained policy, but username selection = is not a good
analogy. I was at a company that had no strict requirements on a username so there should have been a near infinite size of the namespace. But we had=
a collision when the company had less than 10 employees because there
was another "dan" at the company.

> The point is, if a tag is required to be exactly 64 octets, you get > 0x5e^64 possible tags. =C2=A0But if it is required to be up to 64 octe= ts, you
> get Sum(i=3D0..64) 0x5e^i possible tags, which is strictly greater tha= n
> 0x5e^64. =C2=A0So, requiring a tag to be 64 octets _reduces_ the numbe= r of
> possible tags, thereby increasing the chance of collision.

=C2=A0 That would be the case if all tags in the Sum(i=3D1..64) 0x5e^= i tagspace
were equally probable of being chosen. Which implies implementations
choosing a random tag length for each tag generated in addition to a
random tag selection scheme for the randomly chosen length. I suspect,
though, that in practice the tag length will be fixed for a particular
implementation and the tag selection scheme will not necessarily be
random. So the herd mentality, plus the proliferation of one or two
companies' ALTO servers, will result in a severely reduced size of the<= br> effective tagspace and the increased possibility of collisions.

=C2=A0 A tag generated as SHA256(NetworkMap) represented in 64 hex
characters would basically guarantee you'd never have a collision.
Saying, "it can be anything you want as long as it's less than 64<= br> octets" would not.

Should I interp= ret your comment to say that we should to require particular mechanisms for= generating version tags, or be more explicit about suggesting mechanisms t= hat have a low collision probability?

To help steer readers towards better implementation pra= ctices, we'll change the examples to use hashes in the version tags.

Thank you again for the review!
=C2=A0

=C2=A0 Dan.




--047d7b676bf836ad0d04f207f125-- From kivinen@iki.fi Mon Feb 10 06:20:10 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4861A085F; Mon, 10 Feb 2014 06:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_qh2zTegMGt; Mon, 10 Feb 2014 06:20:03 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7793D1A0863; Mon, 10 Feb 2014 06:05:35 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s1AE5X1D003080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 10 Feb 2014 16:05:33 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s1AE5WJ2014785; Mon, 10 Feb 2014 16:05:32 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21240.56492.25650.629460@fireball.kivinen.iki.fi> Date: Mon, 10 Feb 2014 16:05:32 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-manet-nhdp-olsrv2-tlv-extension.all@tools.ietf.org X-Edit-Time: 8 min X-Total-Time: 8 min Subject: [secdir] Secdir review of draft-ietf-manet-nhdp-olsrv2-tlv-extension-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 14:20:11 -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 seems to fix some cases in the NHDP and OLSRv2 TLVs where the original document might have been considered saying that unknown values in the TLVs can be used as a reason to reject message. This document makes it clear how unknown values in the TLVs needs to be processed. This document also creates several IANA registries for the TLV values and changes couple of the TLV values from numbers to bitfields (the existing values were already allocated so that the numbers can be parsed as bitfield). Security considerations section mentions that as this does not really change the current implementations, it more or less describes how new extensions should be processed with implementations it does not add any new security considerations. New extensions might of course add new security considerations but those should be addressed in the documents which make those extensions. The document is ready with nits. Some nits: In the IANA considerations section the IANA is used both in singular and plural, i.e. it says both "IANA is requested" and "IANA are requested". This should be fixed to say "IANA is requested". -- kivinen@iki.fi From thomas@thomasclausen.org Mon Feb 10 06:22:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9DD1A083F; Mon, 10 Feb 2014 06:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvUUE72bKDp0; Mon, 10 Feb 2014 06:22:53 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id B84021A0814; Mon, 10 Feb 2014 06:22:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id EABD61BD3844; Mon, 10 Feb 2014 06:22:53 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id E8A8D1BD383C; Mon, 10 Feb 2014 06:22:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: <21240.56492.25650.629460@fireball.kivinen.iki.fi> Date: Mon, 10 Feb 2014 15:22:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7B913257-5B91-40DE-B196-ACFFEB3C5CAD@thomasclausen.org> References: <21240.56492.25650.629460@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1827) Cc: draft-ietf-manet-nhdp-olsrv2-tlv-extension.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-manet-nhdp-olsrv2-tlv-extension-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 14:22:55 -0000 Thank you, Tero, for your review.=20 As the non-native English speaker among the authors, thank you for your = catch on the is/are in the IANA section...I am afraid that I have to = assume that the fault there lies with me.... Respectfully, Thomas On 10 Feb 2014, at 15:05, 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. >=20 > This document seems to fix some cases in the NHDP and OLSRv2 TLVs > where the original document might have been considered saying that > unknown values in the TLVs can be used as a reason to reject message. > This document makes it clear how unknown values in the TLVs needs to > be processed. This document also creates several IANA registries for > the TLV values and changes couple of the TLV values from numbers to > bitfields (the existing values were already allocated so that the > numbers can be parsed as bitfield). >=20 > Security considerations section mentions that as this does not really > change the current implementations, it more or less describes how new > extensions should be processed with implementations it does not add > any new security considerations. New extensions might of course add > new security considerations but those should be addressed in the > documents which make those extensions. >=20 > The document is ready with nits. >=20 > Some nits: >=20 > In the IANA considerations section the IANA is used both in singular > and plural, i.e. it says both "IANA is requested" and "IANA are > requested". This should be fixed to say "IANA is requested".=20 > --=20 > kivinen@iki.fi From Chris.Dearlove@baesystems.com Mon Feb 10 08:07:21 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382CB1A086D; Mon, 10 Feb 2014 08:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Da0WqClUw4u; Mon, 10 Feb 2014 08:07:19 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id C21EB1A0694; Mon, 10 Feb 2014 08:07:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,818,1384300800"; d="scan'208";a="348072460" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 10 Feb 2014 16:07:17 +0000 From: "Dearlove, Christopher (UK)" X-IronPort-AV: E=Sophos;i="4.95,818,1384300800"; d="scan'208";a="45726033" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 10 Feb 2014 16:07:17 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.106]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 16:07:17 +0000 To: Tero Kivinen , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-manet-nhdp-olsrv2-tlv-extension.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-manet-nhdp-olsrv2-tlv-extension-01 Thread-Index: AQHPJmk7TLKBdzx/bk2glfOcmVHZWJqupw1Q Date: Mon, 10 Feb 2014 16:07:16 +0000 Message-ID: References: <21240.56492.25650.629460@fireball.kivinen.iki.fi> In-Reply-To: <21240.56492.25650.629460@fireball.kivinen.iki.fi> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [secdir] Secdir review of draft-ietf-manet-nhdp-olsrv2-tlv-extension-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:07:21 -0000 Thanks you for your review and comments. IANA want a bit more clarity in th= eir section, so we'll roll your nit in with that. -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] = Sent: 10 February 2014 14:06 To: iesg@ietf.org; secdir@ietf.org; draft-ietf-manet-nhdp-olsrv2-tlv-extens= ion.all@tools.ietf.org Subject: Secdir review of draft-ietf-manet-nhdp-olsrv2-tlv-extension-01 ----------------------! WARNING ! ---------------------- This message origi= nates from outside our organisation, either from an external partner or fro= m the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. Follow the 'Report Suspicious Emails' link on IT matters for instructions o= n reporting suspicious email messages. -------------------------------------------------------- I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document seems to fix some cases in the NHDP and OLSRv2 TLVs where the= original document might have been considered saying that unknown values in= the TLVs can be used as a reason to reject message. This document makes it clear how unknown values in the TLVs needs to be pro= cessed. This document also creates several IANA registries for the TLV valu= es and changes couple of the TLV values from numbers to bitfields (the exis= ting values were already allocated so that the numbers can be parsed as bit= field). Security considerations section mentions that as this does not really chang= e the current implementations, it more or less describes how new extensions= should be processed with implementations it does not add any new security = considerations. New extensions might of course add new security considerati= ons but those should be addressed in the documents which make those extensi= ons. The document is ready with nits. Some nits: In the IANA considerations section the IANA is used both in singular and pl= ural, i.e. it says both "IANA is requested" and "IANA are requested". This = should be fixed to say "IANA is requested". = -- kivinen@iki.fi ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From kivinen@iki.fi Thu Feb 13 01:50:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DC11A012D for ; Thu, 13 Feb 2014 01:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdYm5TefMm0p for ; Thu, 13 Feb 2014 01:50:51 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 39FB51A0117 for ; Thu, 13 Feb 2014 01:50:50 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s1D9okKo006335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 13 Feb 2014 11:50:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s1D9okvZ023192; Thu, 13 Feb 2014 11:50:46 +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: <21244.38262.16549.550119@fireball.kivinen.iki.fi> Date: Thu, 13 Feb 2014 11:50:46 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 2 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 09:50:55 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Ondrej Sury is next in the rotation. For telechat 2014-02-20 Reviewer LC end Draft Dorothy Gellert T 2014-02-11 draft-housley-pkix-test-oids-00 Phillip Hallam-Baker TR2014-02-04 draft-ietf-pcp-description-option-04 Phillip Hallam-Baker T 2014-01-27 draft-ietf-qresync-rfc5162bis-10 Steve Hanna TR2014-02-04 draft-ietf-pcp-nat64-prefix64-05 Steve Hanna T 2014-01-28 draft-ietf-v6ops-nat64-experience-09 Scott Kelly T 2014-02-11 draft-ietf-pwe3-iccp-13 Stephen Kent TR2014-02-12 draft-ietf-mpls-forwarding-08 Alexey Melnikov T 2014-02-14 draft-ietf-l2vpn-vpls-mib-14 Kathleen Moriarty TR2013-12-16 draft-ietf-opsec-vpn-leakages-03 For telechat 2014-03-20 Julien Laganier T 2014-02-28 draft-fairhurst-ipdvb-ule-iana-05 Last calls and special requests: Dave Cridland E 2013-11-21 draft-dunbar-armd-arp-nd-scaling-practices-07 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05 Jeffrey Hutzelman 2014-02-04 draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01 Warren Kumari 2014-02-12 draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-11 Matt Lepinski 2014-02-28 draft-housley-pkix-oids-01 Chris Lonvick 2014-02-18 draft-ietf-dhc-dhcpv6-unknown-msg-05 Catherine Meadows 2014-02-17 draft-ietf-dmm-requirements-14 Adam Montville 2014-02-19 draft-ietf-storm-rdmap-ext-08 Kathleen Moriarty 2014-02-18 draft-ietf-tcpm-1323bis-19 Russ Mundy 2014-03-24 draft-mahalingam-dutt-dcops-vxlan-08 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Sandy Murphy 2014-03-05 draft-melnikov-smime-msa-to-mda-02 Yoav Nir 2014-02-24 draft-ietf-eman-framework-15 Magnus Nystrom 2014-02-24 draft-ietf-mpls-ldp-applicability-label-adv-02 Hilarie Orman 2014-02-24 draft-ietf-mpls-tp-psc-itu-02 Radia Perlman 2014-02-24 draft-ietf-multimob-pmipv6-source-07 Vincent Roca 2014-02-25 draft-ietf-sidr-policy-qualifiers-01 Joe Salowey 2014-02-20 draft-ietf-stir-problem-statement-03 Yaron Sheffer 2014-02-21 draft-ietf-v6ops-64share-09 Zach Shelby 2013-08-30 draft-kaplan-insipid-session-id-03 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-09 -- kivinen@iki.fi From kent@bbn.com Thu Feb 13 07:26:33 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A5E1A0273 for ; Thu, 13 Feb 2014 07:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_BIG_TO_CC=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FnygqwnuabP for ; Thu, 13 Feb 2014 07:26:31 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF5A1A0209 for ; Thu, 13 Feb 2014 07:26:31 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:38155 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WDyBB-0003C8-Lm; Thu, 13 Feb 2014 10:26:21 -0500 Message-ID: <52FCE41B.8050607@bbn.com> Date: Thu, 13 Feb 2014 10:26:19 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com References: <201402052024.s15KOR0W012286@maildrop2.v6ds.occnc.com> <52F2AD6B.4060702@bbn.com> In-Reply-To: <52F2AD6B.4060702@bbn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: swallow@cisco.com, samante@apple.com, secdir , kireeti@juniper.net, cpignata@cisco.com, agmalis@gmail.com, curtis@occnc.com, rcallon@juniper.net, Adrian Farrel , Stewart Bryant , Loa Andersson Subject: [secdir] SECDIR review of draft-ietf-mpls-forwarding-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:26:33 -0000 I skimmed the 08 version of the doc and I am comfortable (actually, very happy) with the changes that have been made since I reviewed the 06 version. My thanks to Curtis for his quick responses and for a great job in making the requested revisions, and more. Steve From scott@hyperthought.com Thu Feb 13 08:53:53 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1EC1A0318 for ; Thu, 13 Feb 2014 08:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpIj8gsNafcu for ; Thu, 13 Feb 2014 08:53:51 -0800 (PST) Received: from smtp66.iad3a.emailsrvr.com (smtp66.iad3a.emailsrvr.com [173.203.187.66]) by ietfa.amsl.com (Postfix) with ESMTP id 261FC1A0336 for ; Thu, 13 Feb 2014 08:53:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp17.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C1ACA2A04EB; Thu, 13 Feb 2014 11:53:48 -0500 (EST) X-Virus-Scanned: OK Received: from app48.wa-webapps.iad3a (relay.iad3a.rsapps.net [172.27.255.110]) by smtp17.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1569B2A04F8; Thu, 13 Feb 2014 11:53:33 -0500 (EST) Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app48.wa-webapps.iad3a (Postfix) with ESMTP id 03332381BBB; Thu, 13 Feb 2014 11:53:33 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Thu, 13 Feb 2014 08:53:33 -0800 (PST) Date: Thu, 13 Feb 2014 08:53:33 -0800 (PST) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-pwe3-iccp.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: <1392310413.011331048@apps.rackspace.com> X-Mailer: webmail7.0 Subject: [secdir] secdir review of draft-ietf-pwe3-iccp-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:53:53 -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=0AI'm sorry that this review is a few days l= ate. From the abstract:=0A=0A This document specifies an inter-chassis co= mmunication protocol=0A (ICCP) that enables Provider Edge (PE) device red= undancy for Virtual=0A Private Wire Service (VPWS) and Virtual Private LA= N Service (VPLS)=0A applications. The protocol runs within a set of two o= r more PEs,=0A forming a redundancy group, for the purpose of synchronizi= ng data=0A amongst the systems. It accommodates multi-chassis attachment = circuit=0A as well as pseudowire redundancy mechanisms.=0A =0ASo, it's a = redundancy protocol between provider edge devices. The document is long (81= pages), and not having been a participant in the wg, I encountered a lot o= f unfamiliar territory.=0A=0AThe document presents 4 different interconnect= scenarios for PEs (provider edge devices), as they are called. The securit= y considerations section says that the security considerations in RFC5036 (= LDP) and RFC4447 (Pseudowire Setup and Maintenance Using LDP) apply, and go= es on to say that the ICCP protocol (which runs between the PEs) is intende= d to be restricted to a single administrative domain.=0A=0AThe security con= siderations section goes on to talk about the need for policy configuration= , and recommends that implementations provide control-plane policing to mit= igate various attacks.=0A=0AI have to admit that I only have a limited unde= rstanding of this protocol, and this review should be taken accordingly. Zo= oming up to a 20000` level, I see that there is a group, and that this prot= ocol allows a device to join and participate the group. =0A=0AThe 4 differe= nt interconnect scenarios have different security properties/considerations= . The first one (co-located dedicated interconnect) allows assumptions abou= t physical security. The second and fourth have the PEs communicating via s= hared fabric ("Core Network"). The third has a dedicated interconnect which= may allow assumptions about connection security.=0A=0ASo, the questions I = think of are these:=0A=0A- what are the potential consequences of an unauth= orized join?=0A=0A- if any of these are a concern, then how do I prevent un= authorized joins?=0A=0A- assuming unauthorized joins are prevented, what ar= e the potential consequences of interfering with traffic?=0A=0A- if any of = these are a concern, then how do I detect/prevent these?=0A=0AIn the case r= elying on physical security and/or a dedicated link (first/third), these ca= n all be addressed by securing the physical link. In the other two cases, w= e either need protocol mechanisms, or we need assumptions/methods relating = to the core network.=0A=0ASince the security considerations section points = at RFCs 5036 and 4447, I went and looked at those. They talk about LDP and = MPLS security, but the mechanisms they are using are ip address filtering a= nd MD5 authentication. Under some assumptions for the core network, these m= ay be fine, but under others (e.g. a potentially hostile core network), the= y are not.=0A=0AThese are the things that occurred to me, as an outside obs= erver who read the draft once. =0A=0A--Scott=0A From nobody Thu Feb 13 10:52:34 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339CA1A03FF; Thu, 13 Feb 2014 10:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogHwk8k_DeAK; Thu, 13 Feb 2014 10:52:26 -0800 (PST) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 62B801A03E7; Thu, 13 Feb 2014 10:52:25 -0800 (PST) Received: by mail-ea0-f177.google.com with SMTP id m10so2687168eaj.8 for ; Thu, 13 Feb 2014 10:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GEV55a52yq5yDmR1kRci3GSyx44mSspX+bvPmOZ19Jc=; b=Q6Ok48SLorPIss6E91zhAyaSKk+JvvSBJhqpcfFxFHRA0V1llGywseg6xRxiZ/vN6B IREi7+ms0ZI05ffjXhW8Lvgoq35gxAzhqhwcmerEa4uDZeNr8XfwDC2ibd3l4ujSGI4/ DSBj66U149UYEQK2l1Jxmo8VTW4rc6PC02AfoZ3lUGe8U3H02W3wSUP+CVq3/lNJq9rT efZg8kKMusoJxCgmKeLzxVJCmX/AHoG5Czdkt0hOdlqwrUuSgXZWEfn56p4AHqcdI31Y LCAupJdMFjf6z0KUH949MnYPmV7Re+QJNrhHcEkFFYzB7paCBd/mnAWmiJyIcVWBWwy0 e/jg== MIME-Version: 1.0 X-Received: by 10.15.26.8 with SMTP id m8mr3732595eeu.25.1392317543706; Thu, 13 Feb 2014 10:52:23 -0800 (PST) Received: by 10.14.105.69 with HTTP; Thu, 13 Feb 2014 10:52:23 -0800 (PST) Date: Thu, 13 Feb 2014 13:52:23 -0500 Message-ID: From: Matthew Lepinski To: "secdir@ietf.org" , "iesg@ietf.org" , draft-housley-pkix-oids.all@tools.ietf.org Content-Type: multipart/alternative; boundary=089e0160c9a09b75e204f24e3022 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/V-_K-2fg2yF4p68r2_G9dZzW0Ys Subject: [secdir] SECDIR review of draft-housley-pkix-oids X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:52:28 -0000 --089e0160c9a09b75e204f24e3022 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and working group chairs should treat these comments just like any other last call comments. This document returns control of the PKIX object identifier arc to IANA. That is, it establishes a new IANA registry for OIDs in the PKIX arc and populates that registry with the existing OID assignments. Finally, the document establishes expert review as the criteria for future additions to the registry and includes guidance that for review. After reviewing the document, I agree with the author that this document introduces no new security concerns. I found no issues in the document and I believe it is ready for publication. ------------------------------- Nits The author should consider including an expansion of the acronym SMI, which is used frequently in the document. (I believe in this context SMI = Structure of Management Information) In Section 3: s/be related to X.509 certificate/be related to X.509 certificates/ In Section 3.1: s/to points to this document/to point to this document/ --089e0160c9a09b75e204f24e3022 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dir= ectorate's ongoing effort to review all IETF documents being processed = by the IESG. =A0These comments were written primarily for the benefit of th= e security area directors. =A0Document editors and working group chairs sho= uld treat these comments just like any other last call comments.

This document = returns control of the PKIX object identifier arc to IANA. That is, it esta= blishes a new IANA registry for OIDs in the PKIX arc and populates that reg= istry with the existing OID assignments. Finally, the document establishes = expert review as the=A0criteria=A0for=A0future additions to the registry an= d includes=A0guidance=A0that for review.

After reviewing the document, I agree with the author tha= t this document introduces no new security concerns.=A0

I found no issues in the= document and I believe it is ready for publication.

-------------------------------

Nits
The author should cons= ider including an expansion of the=A0acronym=A0SMI, which is used frequentl= y in the document. (I believe in this context SMI =3D Structure of Manageme= nt Information)

In Section 3:
s/be related t= o X.509 certificate/be related to X.509 certificates/

In Section 3.1:=A0
s/to poin= ts to this document/to point to this document/

<= span style=3D"color:rgb(0,0,0);font-size:1em">

--089e0160c9a09b75e204f24e3022-- From nobody Thu Feb 13 14:18:02 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2E61A0009; Thu, 13 Feb 2014 14:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3eXe7LZ1CB4; Thu, 13 Feb 2014 14:17:55 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 11FBC1A0469; Thu, 13 Feb 2014 14:17:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7896; q=dns/txt; s=iport; t=1392329874; x=1393539474; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=G9uqXDO+588HMFtlQdbmnCuOrPySBjjIU4fJreHa+qg=; b=chNRsaWUa73CMfZYfeyglLvDXfIDddNewtFxZZ2nvGE/MyDhhpoFGuLu keckEUQ6sPl/9KFcwCl/i/vGFcUPRQ/Z5M7KbVq2veb9fsWtg1lCiaMwB nM71x7F/WS3jblTb/J8ejckhHTAHbRf6AUhaR5WpoXrMcVPWgFUymMyAj 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAL1D/VKrRDoI/2dsb2JhbABWA4MGOL9VT4EaFnSCJQEBAQMBAQEBawQHBQsLDgouJzAGEwmHdAcBDcElhxgXjhcRAQIbIxAHEYMTgRQEiUiOZIEykHGDToFQ X-IronPort-AV: E=Sophos;i="4.95,841,1384300800"; d="scan'208";a="102407661" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 13 Feb 2014 22:17:53 +0000 Received: from dhcp-128-107-147-105.cisco.com (dhcp-128-107-147-105.cisco.com [128.107.147.105]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1DMHrs2000758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Feb 2014 22:17:53 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Weis In-Reply-To: Date: Thu, 13 Feb 2014 14:17:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2183EB9D-A87B-4737-89AD-D9A653EF5FF7@cisco.com> References: To: Yoav Nir X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Fgb-22yvPDrqiLaSObFy1rEy1J8 Cc: draft-weis-gdoi-iec62351-9@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] SecDir-ish Review of draft-weis-gdoi-iec62351-9-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 22:18:01 -0000 Hi Yoav, A new version has been posted that we believe address each of your = comments. Let us know if you have further questions or suggestions. Significant changes: - Clarification that DER encoding is required - Added a bit more text describing the relationship between IEC = standards - Moved a normative reference to be informative - Small corrections to the example in Appendix A - Added Appendix B (Implementation Considerations) to provide guidance = in case some of your questions come up again Thanks, Brian On Nov 4, 2013, at 2:04 AM, Brian Weis wrote: > Hi Yoav, >=20 > Many thanks for your review. >=20 > On Nov 3, 2013, at 10:54 AM, Yoav Nir wrote: >=20 >> Hi there. >>=20 >> At Sean's request, I've done a SecDir-ish review of = draft-weis-gdoi-iec62351-9-02. I think it is in pretty good shape, but I = do have some concerns. >>=20 >> First, an apology: the draft embeds OIDs in IKE packets. Throughout = this review I use the term "ASN.1" for both the objects and the = encoding. I do realize that ASN means abstract syntax notation, and that = the correct term to use for the encoding ia BER, but this is a very = common misuse. The draft does get this correct. >=20 > The draft actually uses DER encoding, which I believe is the case for = most ASN.1 encoding in RFCs. This should be stated to avoid confusion.=20= >=20 >> I am somewhat confused by the IEC standards numbers. The abstract and = introduction mostly discuss IEC 61850, which is the "power utility = automation" family of standards. On the other hand, the number in the = title of the draft is IEC 62351. There is a reference to a document = called "IEC 62351 Part 9 - Key Management". I can see how this draft = relates to key management, but "part 9" of what? >=20 > For the benefit of the secdir audience here's Herb's reply from the = original email thread and your reply: >=20 >>> [Herb]: I don=92t understand the question. So I will try to = explain. IEC 61850 is a set of communication standards developed under = IEC Technical Committee 57. IEC TC57 has WG15 that was formed to = address security for the breadth of standards that are developed under = TC57, including IEC 61850. In IEC, the designations within a family of = standards (e.g. 61850 or 62351) are called parts. IEC 61850 has over 10 = standards that are 61850-1 through 61850-10 (e.g. 10 parts). = Chapters/sub-chapters are called =93clauses=94 in IEC. So when it = mentions IEC 62351 Part 9 =96 Key Management, the official reference is = =93IEC 62351-9 Ed. 1.0 Power systems management and associated = information exchange - Data and communications security - Part 9: Cyber = security key management for power system equipment (Future IEC 62351-9 = TS Ed.1)=94. When IEC removes the ED 1.0, it means refer to the current = revisions (ED.2 has almost been completed). The =93Power systems = management and associated information exchange - Data and communications = security=94 is the charter of WG15 and the overall scope of 62351 (they = all have that in their title). Therefore, =93IEC 62351 Part 9 =96 Key = Management=94 could be referred to as =93IEC 62351-9=94, =93IEC 62351-9 = : Cyber security key management for power system equipment=94, or in = presentations =93IEC 62351-9=96 Key Management=94. So, I would change = to IEC 62351-9 (and give the full name). Sorry for the long = explanation. >>>=20 >> [Yoav] OK. I guess the IEC standards have a more complicated naming = convention than RFCs .I'm just missing an overall title for 62351.=20 >=20 > We can summarize Herb's description above in the Introduction, if that = would help. >=20 >> Another thing that's missing for me, as one uninitiated in the ways = of the IEC, is what are we negotiating keys for? I get that it's not = IPsec, but at the end of the protocol, we have keys that are distributed = to group members. Now, what is this data layer that can now use them. A = reference to some standard ("IEC-61850-9-2" would be OK), but since = these are not widely available, some short description of what this = protocol looks like would be great. >=20 > OK. >=20 >> Another generic comment is about the IANA considerations as well as = parts of section 2.2. Why do we need to establish new registries, that = are duplicates of IPsec registries with one additional value? I know = there has been some resistance to adding things there for stuff that's = "not IKE", but with this already done in RFC 6932 ([1],[2]), that ship = has left the station after the horses had bolted. >=20 > This is a different situation from RFC 6932. (In fact, since GDOI is = IKEv1-based what you're asking for will add to the RFC 2409 registries, = which RFC 6932 says is discouraged.) >=20 > I have some sympathy for saying we should have one list of algorithms = that all protocols should use, but in fact every protocol (in this case = the IEC set of protocols) would have to declare which subset of the = algorithm list they support in a normative fashion. That complexity does = not belong in the notes section of [1], IMO. Non-IPsec protocol-specific = subsets will change over time and have to be maintained somewhere ... a = new protocol-specific registry is the right place to do that. >=20 > By the way, the IEC standards defines truncation values for = HMAC-SHA256 that are not duplicates. >=20 >>=20 >> Why is there an OID_LENGTH field? All ASN.1 structures are = self-describing in terms of length. There can be a good reason: so that = you can implement with a bitwise comparison rather than implementing an = ASN.1 parser. Please say so if that's the reason. >=20 > The OID_LENGTH field is not strictly required, since the DER includes = the length. Maintaining the length outside of the DER is valuable for = payload manipulation where parsing the DER is not otherwise necessary = (e.g., copying the DER into the payload, payload length sanity checks, = etc.). We'll add that. >>=20 >> I didn't quite get where each of the OIDs in the ID payload (figure = 2) and the TEK payload (figure 4) come from. Are they the same? Appendix = A suggests that they're not. So, >=20 > The OID in the ID payload will match the OID in the TEK payload if the = group represented by the ID payload has only one multicast sender. This = is shown in Appendix A (modulo a typo, see below). Sorry for the = confusion. >=20 > To answer the broader question, there could be multiple multicast = senders represented by the OID, so the group key server would return = multiple TEKs, each with unique OID & OID specific payload. This can be = made clearer in the draft. >=20 >> - what does "type of traffic" mean? >=20 > The IEC documents list several OID types, each of which is a "type of = traffic". This can be expanded. >=20 >>=20 >> - Appendix A says "OID=3D" in the TEK payload. What is = k? >=20 > That is a typo. It should be "OID=3D" matching the ID payload. >=20 > Thanks, > Brian >=20 >>=20 >>=20 >> Yoav >>=20 >> [1] = http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-= registry-10 >> [2] http://tools.ietf.org/html/rfc6932=09 >>=20 >>=20 >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >=20 > --=20 > Brian Weis > Security, Enterprise Networking Group, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com >=20 --=20 Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From nobody Thu Feb 13 16:31:11 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DEE1A0007 for ; Thu, 13 Feb 2014 16:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id salGnkecZzfd for ; Thu, 13 Feb 2014 16:31:04 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 92AE71A0006 for ; Thu, 13 Feb 2014 16:31:03 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id y1so8876746lam.13 for ; Thu, 13 Feb 2014 16:31:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=V4aWjvTPZ+rCrAICl4aVKIKvWgHemOpn6kEsEZKQ4dk=; b=r93HsHEGijeKY9fciQjh8yPBGdY+iC2rOxS6fORfEkBJRftQP3VoQqkwBCs8U2DomD idQQ8enAO+h4KtRN/q0kWLAf2mgPhU8U/TtqVWVtKzUNd8r667TrOXVYfvXZiQwdCbjD x3WINpsEXEEUV1QfxjClOzC+Wwtzn9uKZ5yYa0Y3S8ZZ1eYkI54uaSEQKEbLJ/8VQf2e kKAdNE71RkHphet1gpQSWd1AGtEWvOS2u/i0F6qpwLNmqQ3S5WF2Rzt+jwgLQOyMvzQv YwAmufZA1PyfS3JgPIdlwTDXBja58MCr4Yd1mst3ZUFEhWikplSZmZ60EL2q3O9o0tqn 94Tg== MIME-Version: 1.0 X-Received: by 10.152.234.36 with SMTP id ub4mr2858376lac.13.1392337861606; Thu, 13 Feb 2014 16:31:01 -0800 (PST) Received: by 10.112.37.168 with HTTP; Thu, 13 Feb 2014 16:31:01 -0800 (PST) Date: Thu, 13 Feb 2014 19:31:01 -0500 Message-ID: From: Phillip Hallam-Baker To: "secdir@ietf.org" Content-Type: multipart/alternative; boundary=001a11344e5aa6009104f252ebc0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/0mdYPg_XbuBCTkGATO4-3N8UdGg Subject: [secdir] SECDIR Review of draft-ietf-qresync-rfc5162bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 00:31:06 -0000 --001a11344e5aa6009104f252ebc0 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. We have a problem here, the security considerations in the draft are a back reference to the original protocol. This is the security references section of IMAP, a core Internet protocol in their entirety: 11 . Security Considerations IMAP4rev1 protocol transactions, including electronic mail data, are sent in the clear over the network unless protection from snooping is negotiated. This can be accomplished either by the use of STARTTLS, negotiated privacy protection in the AUTHENTICATE command, or some other protection mechanism. -- Website: http://hallambaker.com/ --001a11344e5aa6009104f252ebc0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=A0 I have reviewed this document as part of the secu= rity directorate's
ongoing effort to review all IETF documents being processed by the<= br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">I= ESG. =A0These comments were written primarily for the benefit of the=
security area directors. =A0Document editors and WG chairs should treat
these comments just like any other last call comments.

We have a problem here, the security considerations in t= he draft are=A0
a back reference to the original protocol= . This is the security references
section of IMAP, a core Internet protocol in their entirety:

11.     Security=
 Considerations



   IMAP4rev1 protocol transactions, including electronic mail data, are
   sent in the clear over the network unless protection from snooping is
   negotiated.  This can be accomplished either by the use of STARTTLS,
   negotiated privacy protection in the AUTHENTICATE command, or some
   other protection mechanism.



=

--
Website: ht= tp://hallambaker.com/
--001a11344e5aa6009104f252ebc0-- From nobody Thu Feb 13 16:46:46 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B74A1A0007 for ; Thu, 13 Feb 2014 16:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oe34oH-KHCAP for ; Thu, 13 Feb 2014 16:46:41 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 17CDC1A0006 for ; Thu, 13 Feb 2014 16:46:40 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id u14so8824704lbd.15 for ; Thu, 13 Feb 2014 16:46:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=h33hTDpLf9vLKLLkf2lkm5jF7BniY+Ib3MpSSvEQsFU=; b=sPIjxIIWFqFHJbQCHoULWS1c/mzZlbJKkYJMoMwSkmsZsYa2BDO0K8svAW6QuHIsWt LNFC6e4x4fDS/ZpEBzGgWrXnOvslIXbmb7ip/RXTMg5WB2U2ZIFWHDNTgxa1hmSWG7XB kL3kjfS5prCfbASHn1XySIotGHi+3TupqCXR+ibfr+/wWznXPNuYYFdANwsgIKiyGcJ/ eXrcWgMSjNjtdPizgbAUn+vXVO/ZXcCd2geBVmBveHKn/42mydqvpqmMqxmQ27cE+mL8 7sSRn4T34IMBrW8bRucOLamtPS/VxPYDeaIJKY81umLHx2M6YGnr6HHz2x4TMiuwhLRY h11Q== MIME-Version: 1.0 X-Received: by 10.112.125.225 with SMTP id mt1mr2706115lbb.35.1392338799029; Thu, 13 Feb 2014 16:46:39 -0800 (PST) Received: by 10.112.37.168 with HTTP; Thu, 13 Feb 2014 16:46:38 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Feb 2014 19:46:38 -0500 Message-ID: From: Phillip Hallam-Baker To: "secdir@ietf.org" Content-Type: multipart/alternative; boundary=089e0112bfb885f2d704f2532385 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/DZt5x2Y8OZ8r60NPgltjC8tgekQ Subject: Re: [secdir] SECDIR Review of draft-ietf-qresync-rfc5162bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 00:46:44 -0000 --089e0112bfb885f2d704f2532385 Content-Type: text/plain; charset=ISO-8859-1 Hit send prematurely On Thu, Feb 13, 2014 at 7:31 PM, Phillip Hallam-Baker wrote: > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. 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. > > We have a problem here, the security considerations in the draft are > a back reference to the original protocol. This is the security references > section of IMAP, a core Internet protocol in their entirety: > > 11 . Security Considerations > > IMAP4rev1 protocol transactions, including electronic mail data, are > sent in the clear over the network unless protection from snooping is > negotiated. This can be accomplished either by the use of STARTTLS, > negotiated privacy protection in the AUTHENTICATE command, or some > other protection mechanism. > > > Such an important protocol needs a full security review. Commenting on how an extension might affect the protocol seems rather pointless/ineffective when the original protocol has not been reviewed and raises serious security concerns. -- Website: http://hallambaker.com/ --089e0112bfb885f2d704f2532385 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hit send prematurely

On Thu, Feb 13, 2014 at 7:31 PM, Phillip Hallam= -Baker <hallam@gmail.com> wrote:

=A0 I have reviewed th= is document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the<= br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">I= ESG. =A0These comments were written primarily for the benefit of the=
security area directors. =A0Document editors and WG chairs should treat
these comments just like any other last call comments.

We have a problem here, the security considerations in t= he draft are=A0
a back reference to the original protocol= . This is the security references
section of IMAP, a core Internet protocol in their entirety:

11.     Securit=
y Considerations




   IMAP4rev1 protocol transactions, including electronic mail data, are
   sent in the clear over the network unless protection from snooping is
   negotiated.  This can be accomplished either by the use of STARTTLS,
   negotiated privacy protection in the AUTHENTICATE command, or some
   other protection mechanism.


Such an important protocol needs a full security review. Commenting on how=
an extension might affect the protocol seems rather pointless/ineffect= ive
when the original protocol has not been reviewed and raises s= erious security
concerns.

--
Websit= e: http://hallambaker.com/
--089e0112bfb885f2d704f2532385-- From nobody Thu Feb 13 17:37:17 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12541A001E for ; Thu, 13 Feb 2014 17:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBr8_FnniWGL for ; Thu, 13 Feb 2014 17:37:13 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (smtp02.srv.cs.cmu.edu [128.2.217.201]) by ietfa.amsl.com (Postfix) with ESMTP id B91591A0016 for ; Thu, 13 Feb 2014 17:37:13 -0800 (PST) Received: from [128.237.246.30] ([128.237.246.30]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s1E1b6KV008175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 13 Feb 2014 20:37:10 -0500 (EST) Message-ID: <1392341826.4569.14.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: Phillip Hallam-Baker Date: Thu, 13 Feb 2014 20:37:06 -0500 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.201 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/5WqptnUvRXFFJuQJ1O1Je5m_SbI Cc: "secdir@ietf.org" , jhutz@cmu.edu Subject: Re: [secdir] SECDIR Review of draft-ietf-qresync-rfc5162bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 01:37:16 -0000 On Thu, 2014-02-13 at 19:31 -0500, Phillip Hallam-Baker wrote: > We have a problem here, the security considerations in the draft are > a back reference to the original protocol. This is the security references > section of IMAP, a core Internet protocol in their entirety: > > 11 . Security Considerations > > IMAP4rev1 protocol transactions, including electronic mail data, are > sent in the clear over the network unless protection from snooping is > negotiated. This can be accomplished either by the use of STARTTLS, > negotiated privacy protection in the AUTHENTICATE command, or some > other protection mechanism. Nope. That's the entirety of the _introduction_ to the security considerations section in RFC33501. It is followed by two subsections which give a fairly detailed treatment of issues related to authentication, connection security, and handling of passwords. That's not to say the security considerations in the IMAP spec are complete and perfect; they're certainly not. For example, there is no discussion of authorization and access control. However, incomplete is not the same as nonexistent, and there is no need here to be alarmist. -- Jeff From nobody Thu Feb 13 18:20:29 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15BD1A004C for ; Thu, 13 Feb 2014 18:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOIGTg1t5ZSL for ; Thu, 13 Feb 2014 18:20:20 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 73A411A0016 for ; Thu, 13 Feb 2014 18:20:20 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id c11so8827601lbj.16 for ; Thu, 13 Feb 2014 18:20:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tmM2ao+lZHlEfoM/A93fbyAaN+Ctwg3bKTFMZuUml+c=; b=dhJctR7oK7/mmsKQrWlaDbPq/sIx8LAWcT2iYec2hEHzFfOYOluW+DIW+lwCH/ISYD HZO+IMwUX7oKuQM9yaDrdsR9C7bhXbfbKH70s34yBsCoV3s6ZErUJCjOtkS0AFqHpCjB VdTGHmIVEm2CfQViJXBGG8PCgKtiUnKIfRwkq5QSpSTjswGkBE4zEeBfkwpG5mctfS3d 9k8Zv/UvtpA2fSKYIcyiITPlE6zeP1Hr7xhpGzsVNxtVBJG4Ewv6Dgtlb4/tmcYu/0eO jOF4N+fU0n8QsA5JOotLRdtPtvW/QEZICLA+ZzOOdKIiSeSN5YJWvds9t8ljQaNGPM79 v5WA== MIME-Version: 1.0 X-Received: by 10.152.28.7 with SMTP id x7mr17369lag.57.1392344418377; Thu, 13 Feb 2014 18:20:18 -0800 (PST) Received: by 10.112.37.168 with HTTP; Thu, 13 Feb 2014 18:20:18 -0800 (PST) In-Reply-To: <1392341826.4569.14.camel@destiny.pc.cs.cmu.edu> References: <1392341826.4569.14.camel@destiny.pc.cs.cmu.edu> Date: Thu, 13 Feb 2014 21:20:18 -0500 Message-ID: From: Phillip Hallam-Baker To: Jeffrey Hutzelman Content-Type: multipart/alternative; boundary=089e0160bf7076650404f2547265 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/HYyr0myLj_V3Vl8LoE7a-iqNJ20 Cc: "secdir@ietf.org" Subject: Re: [secdir] SECDIR Review of draft-ietf-qresync-rfc5162bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 02:20:27 -0000 --089e0160bf7076650404f2547265 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 13, 2014 at 8:37 PM, Jeffrey Hutzelman wrote: > On Thu, 2014-02-13 at 19:31 -0500, Phillip Hallam-Baker wrote: > > > > We have a problem here, the security considerations in the draft are > > a back reference to the original protocol. This is the security > references > > section of IMAP, a core Internet protocol in their entirety: > > > > 11 . Security > Considerations > > > > IMAP4rev1 protocol transactions, including electronic mail data, are > > sent in the clear over the network unless protection from snooping is > > negotiated. This can be accomplished either by the use of STARTTLS, > > negotiated privacy protection in the AUTHENTICATE command, or some > > other protection mechanism. > > Nope. That's the entirety of the _introduction_ to the security > considerations section in RFC33501. It is followed by two subsections > which give a fairly detailed treatment of issues related to > authentication, connection security, and handling of passwords. > > That's not to say the security considerations in the IMAP spec are > complete and perfect; they're certainly not. For example, there is no > discussion of authorization and access control. However, incomplete is > not the same as nonexistent, and there is no need here to be alarmist. > Weird and I was looking for it.. There is a problem in that it does not state what the attack model is. It seems as if the attack model is limited to a passive attack. If there is an active MITM attack, SSL will only provide protection if the server certificate is authenticated. Otherwise, passing the username and password enclair is problematic. -- Website: http://hallambaker.com/ --089e0160bf7076650404f2547265 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Feb 13, 2014 at 8:37 PM, Jeffrey Hutzelman <jhutz@cmu.edu&= gt; wrote:
On Thu, 2014-02-13 at 19:31 = -0500, Phillip Hallam-Baker wrote:


> We have a problem here, the security considerations in the draft are > a back reference to the original protocol. This is the security refere= nces
> section of IMAP, a core Internet protocol in their entirety:
>
> 11 <http://tools.ietf.org/html/rfc3501#section-11>. = =A0 =A0 Security Considerations
>
> =A0 =A0IMAP4rev1 protocol transactions, including electronic mail data= , are
> =A0 =A0sent in the clear over the network unless protection from snoop= ing is
> =A0 =A0negotiated. =A0This can be accomplished either by the use of ST= ARTTLS,
> =A0 =A0negotiated privacy protection in the AUTHENTICATE command, or s= ome
> =A0 =A0other protection mechanism.

Nope. =A0That's the entirety of the _introduction_ to the securit= y
considerations section in RFC33501. =A0It is followed by two subsections which give a fairly detailed treatment of issues related to
authentication, connection security, and handling of passwords.

That's not to say the security considerations in the IMAP spec are
complete and perfect; they're certainly not. =A0For example, there is n= o
discussion of authorization and access control. =A0However, incomplete is not the same as nonexistent, and there is no need here to be alarmist.
<= /blockquote>

Weird and I was looking for it..
=
There is a problem in that it does not state what the attack= model is. It seems as if the attack model is limited to a passive attack.<= /div>

If there is an active MITM attack, SSL will only provid= e protection if the server certificate is authenticated. Otherwise, passing= the username and password enclair is problematic.
=A0


--
Website: http://hallambaker.com/
--089e0160bf7076650404f2547265-- From nobody Thu Feb 13 18:30:56 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86721A0040 for ; Thu, 13 Feb 2014 18:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gC374qIywTa7 for ; Thu, 13 Feb 2014 18:30:53 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (smtp03.srv.cs.cmu.edu [128.2.217.202]) by ietfa.amsl.com (Postfix) with ESMTP id F2B311A0016 for ; Thu, 13 Feb 2014 18:30:52 -0800 (PST) Received: from [128.237.246.30] ([128.237.246.30]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s1E2UnR8009326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 13 Feb 2014 21:30:49 -0500 (EST) Message-ID: <1392345049.4569.20.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: Phillip Hallam-Baker Date: Thu, 13 Feb 2014 21:30:49 -0500 In-Reply-To: References: <1392341826.4569.14.camel@destiny.pc.cs.cmu.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.202 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ZbXNHahW3GzxkVP74RZlfqSzDh8 Cc: "secdir@ietf.org" , jhutz@cmu.edu Subject: Re: [secdir] SECDIR Review of draft-ietf-qresync-rfc5162bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 02:30:55 -0000 On Thu, 2014-02-13 at 21:20 -0500, Phillip Hallam-Baker wrote: > There is a problem in that it does not state what the attack model is. It > seems as if the attack model is limited to a passive attack. Not at all. It's just a 10+ year old document that doesn't spell things out very well. > If there is an active MITM attack, SSL will only provide protection if the > server certificate is authenticated. Otherwise, passing the username and > password enclair is problematic. Indeed. Section 11.1 goes into a fair amount of detail about verifying the server hostname found in the certificate, but says nothing about validation of the certificate itself. This is an omission which I like to think the IETF has been more careful about in more recent documents. At the time, I think it was somehow assumed that if you used TLS then _of course_ you would do certificate validation, and in fact probably your TLS library would do it for you. Again, these days I like to think we know better. In any case, if you think it's worth spending time on a better treatment of security considerations for IMAP, feel free. I have no time for that, and Tero is breathing down my neck about old reviews I still haven't done. :-( -- Jeff From nobody Fri Feb 14 08:33:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD171A046D; Thu, 13 Feb 2014 12:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUpxY-TfFC_l; Thu, 13 Feb 2014 12:03:19 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1578B1A046E; Thu, 13 Feb 2014 12:03:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1961; q=dns/txt; s=iport; t=1392321798; x=1393531398; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=e/32CnAs7Mv4f40lOmYarncP7/uisV/0++o7TLEvp9M=; b=iuZ9EaJ4D+enW2FCt0YBTNKO8WX0shraOMCf00Gg0bM5KXNPES/UFpCC oNn+0D5akGlKmROUhmmkCNieApRNIX0mZQc/KS1kUWC+0R1Otw2+tem4c NzMrdZB3wIb6VK7V7L1DksTqlA6v31ccbMQXHCRSqo85zm5Eme5y123cF 8=; X-IronPort-AV: E=Sophos;i="4.95,840,1384300800"; d="scan'208";a="20283864" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-4.cisco.com with ESMTP; 13 Feb 2014 20:03:17 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1DK3H31028174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 20:03:17 GMT Received: from [10.61.163.205] (10.61.163.205) by xhc-rcd-x13.cisco.com (173.37.183.87) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 13 Feb 2014 14:03:17 -0600 Date: Thu, 13 Feb 2014 21:02:57 +0100 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Charlie Kaufman In-Reply-To: <5d469d015350423b83a782a78a5527b5@CH1PR03MB599.namprd03.prod.outlook.com> Message-ID: References: <5d469d015350423b83a782a78a5527b5@CH1PR03MB599.namprd03.prod.outlook.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Originating-IP: [10.61.163.205] Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Yofspk0uptOuHIBGsd9kg8uOrac X-Mailman-Approved-At: Fri, 14 Feb 2014 08:33:51 -0800 Cc: draft-alias-bounces@tools.ietf.org, "secdir@ietf.org" , "draft-yourtchenko-cisco-ies.all@tools.ietf.org" , "iesg@ietf.org" , bclaise@cisco.com, jjaeggli@zynga.com, paitken@cisco.com Subject: Re: [secdir] secdir review of draft-yourtchenko-cisco-ies-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:03:21 -0000 Hello Charlie, I've published the http://tools.ietf.org/html/draft-yourtchenko-cisco-ies-10 today, which hopefully took care of the first part of the comments. The formatting in the Appendix A is a result of xml2rfc way of treating the longer URLs. Unfortunately I can not control it, so could not take care of it. On the other hand, hopefully the unusual style of truncation makes it understandable that these URLs need concatenating from the pieces, and this might be taken care of by the potential users of the XML. Thanks a lot for the review ! --a On Sat, 25 Jan 2014, 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. > > This document is a mechanism to bring an IANA registry of log event types up to date to correspond with existing practice based on updates to the protocol defined in RFC3954. There are no security considerations other than vague concerns over what a buggy existing implementations might do if they see new event types that they don't recognize. This should not be controversial. > > Formatting nits: > > At the bottom of page 2 and the top of page 3, there are question marks that seem to have a pre-pended space that looks out of place, but it may have been required by some formatting requirement around the bracketed reference that precedes it. > > The formatter that translated the XML in appendix A into text for the RFC seems to have strange taste in where to place line breaks. For example, in the middle of page 13, there appears: > > > http://www > .cisco.com > /en/US/pro > ducts/hw/s > witches/ps > 700/products_configuration_example... > > --Charlie > From nobody Fri Feb 14 08:33:57 2014 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B6E1A02AF; Fri, 14 Feb 2014 07:38:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1392392335; bh=ryWoo5Extg1H//utLyDbYVjXoO2BBBL2jsMD8aNq1F0=; h=Date:To:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=oVy/uyXAsDsH68FAkaXhsBpWU9RvrnIaNzmqeVhycq0i8Apq5x4M/HW4SKPHw5jHh BYFXRxC7QltJlsR2bf9gyC5lm6T/wrH7JR2mXLz7YIZBmU7R7SHr5klwv7FMNi+6lN HF3vAyvJMQo+zHZ9t6hd2IyjbVG+3aO5Y25/sIlk= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330871A0299 for ; Fri, 14 Feb 2014 07:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.75 X-Spam-Level: X-Spam-Status: No, score=-4.75 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33m8WyuVHxq4 for ; Fri, 14 Feb 2014 07:38:51 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 079C81A02AC for ; Fri, 14 Feb 2014 07:38:50 -0800 (PST) Received: from bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1WEKqm-0004SN-Rp; Fri, 14 Feb 2014 10:38:49 -0500 Date: Fri, 14 Feb 2014 16:38:47 +0100 To: new-work@ietf.org MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/o9sYQb6RrNJIrJOUnc3uZDf7yNk X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/sYCyd2Tq-2QPwZCJi0Vf-vlY1WA X-Mailman-Approved-At: Fri, 14 Feb 2014 08:33:51 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Geolocation Working Group (until 2014-03-15) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:38:56 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbCB0byByZXZpc2UgIAp0aGUgVWJpcXVpdG91cyBXZWIgQXBwbGljYXRp b25zIEFjdGl2aXR5LCBbMF0gKHNlZSB0aGUgVzNDIFByb2Nlc3MgIApEb2N1bWVudCBkZXNjcmlw dGlvbiBvZiBBY3Rpdml0eSBQcm9wb3NhbHMgWzFdKS4gVGhpcyBwcm9wb3NhbCBpbmNsdWRlcyBh ICAKZHJhZnQgY2hhcnRlciBmb3IgdGhlIEdlb2xvY2F0aW9uIFdvcmtpbmcgR3JvdXA6CiAgIGh0 dHA6Ly93d3cudzMub3JnLzIwMTQvMDIvZ2VvLWNoYXJ0ZXIuaHRtbAoKQXMgcGFydCBvZiBlbnN1 cmluZyB0aGF0IHRoZSBjb21tdW5pdHkgaXMgYXdhcmUgb2YgcHJvcG9zZWQgd29yayBhdCBXM0Ms ICAKdGhpcyBkcmFmdCBjaGFydGVyIGlzIHB1YmxpYyBkdXJpbmcgdGhlIEFkdmlzb3J5IENvbW1p dHRlZSByZXZpZXcgcGVyaW9kLgoKVzNDIGludml0ZXMgcHVibGljIGNvbW1lbnRzIHRocm91Z2gg MjAxNC0wMy0xNSBvbiB0aGUgcHJvcG9zZWQgY2hhcnRlci4gIApQbGVhc2Ugc2VuZCBjb21tZW50 cyB0byBwdWJsaWMtbmV3LXdvcmtAdzMub3JnLCB3aGljaCBoYXMgYSBwdWJsaWMgYXJjaGl2ZToK ICAgaHR0cDovL2xpc3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwoK T3RoZXIgdGhhbiBjb21tZW50cyBzZW50IGluIGZvcm1hbCByZXNwb25zZXMgYnkgVzNDIEFkdmlz b3J5IENvbW1pdHRlZSAgClJlcHJlc2VudGF0aXZlcywgVzNDIGNhbm5vdCBndWFyYW50ZWUgYSBy ZXNwb25zZSB0byBjb21tZW50cy4gSWYgeW91IHdvcmsgIApmb3IgYSBXM0MgTWVtYmVyIFsyXSwg cGxlYXNlIGNvb3JkaW5hdGUgeW91ciBjb21tZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgIApDb21t aXR0ZWUgUmVwcmVzZW50YXRpdmUuIEZvciBleGFtcGxlLCB5b3UgbWF5IHdpc2ggdG8gbWFrZSBw dWJsaWMgIApjb21tZW50cyB2aWEgdGhpcyBsaXN0IGFuZCBoYXZlIHlvdXIgQWR2aXNvcnkgQ29t bWl0dGVlIFJlcHJlc2VudGF0aXZlICAKcmVmZXIgdG8gaXQgZnJvbSBoaXMgb3IgaGVyIGZvcm1h bCByZXZpZXcgY29tbWVudHMuCgpJZiB5b3Ugc2hvdWxkIGhhdmUgYW55IHF1ZXN0aW9ucyBvciBu ZWVkIGZ1cnRoZXIgaW5mb3JtYXRpb24sIHBsZWFzZSAgCmNvbnRhY3QgRG9taW5pcXVlIEhhemHD q2wtTWFzc2lldXggPGRvbUB3My5vcmc+IGFuZCBKaW5zb25nIFdhbmcgIAo8d2pzQHczLm9yZz4s IFN0YWZmIENvbnRhY3RzLgoKVGhhbmsgeW91LAoKQ29yYWxpZSBNZXJjaWVyLCBXM0MgQ29tbXVu aWNhdGlvbnMKClswXSBodHRwOi8vd3d3LnczLm9yZy8yMDA3L3V3YS8KWzFdIGh0dHA6Ly93d3cu dzMub3JnLzIwMDUvMTAvUHJvY2Vzcy0yMDA1MTAxNC9hY3Rpdml0aWVzI0FjdGl2aXR5Q3JlYXRp b24KWzJdIGh0dHA6Ly93d3cudzMub3JnL0NvbnNvcnRpdW0vTWVtYmVyL0xpc3QKCi0tIAogIENv cmFsaWUgTWVyY2llciAgLSAgVzNDIENvbW11bmljYXRpb25zIFRlYW0gIC0gIGh0dHA6Ly93d3cu dzMub3JnCm1haWx0bzpjb3JhbGllQHczLm9yZyArMzM2IDQzMjIgMDAwMSBodHRwOi8vd3d3Lncz Lm9yZy9QZW9wbGUvQ01lcmNpZXIvCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwpuZXctd29yayBtYWlsaW5nIGxpc3QKbmV3LXdvcmtAaWV0Zi5vcmcKaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXctd29yawo= From nobody Fri Feb 14 10:14:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F671A0345 for ; Fri, 14 Feb 2014 10:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2UBVLXvIH-P for ; Fri, 14 Feb 2014 10:14:48 -0800 (PST) Received: from smtp122.ord1c.emailsrvr.com (smtp122.ord1c.emailsrvr.com [108.166.43.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5224E1A02CF for ; Fri, 14 Feb 2014 10:14:48 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp8.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id B1CD11A013E; Fri, 14 Feb 2014 13:14:46 -0500 (EST) X-Virus-Scanned: OK Received: by smtp8.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 42D5E1A0107; Fri, 14 Feb 2014 13:14:45 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_EC78EBE6-7F7B-41C2-941D-46FD2DD081DE" From: Olafur Gudmundsson X-Priority: 4 (Low) In-Reply-To: <52E93A6B.9020400@gondrom.org> Date: Fri, 14 Feb 2014 13:14:45 -0500 Message-Id: <19D1C94B-B284-45D6-AFDE-A1781B633F72@ogud.com> References: <52101187.2060409@gondrom.org> <5293E22B.90705@gondrom.org> <52E93A6B.9020400@gondrom.org> To: Tobias Gondrom X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/GxOvMw0XXzf2n0MhLnpcqf1Seas Cc: iesg@ietf.org, draft-ietf-dane-registry-acronyms.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dane-registry-acronyms-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:14:53 -0000 --Apple-Mail=_EC78EBE6-7F7B-41C2-941D-46FD2DD081DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks Tobias for the review=20 On Jan 29, 2014, at 12:29 PM, Tobias Gondrom = wrote: > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >=20 >=20 > The document is basically just about acronyms to simplify DANE = conversations=20 > The document appears ready for publication.=20 >=20 > The security consideration section is sufficient and there are no = security issues with this document.=20 >=20 > There are only two small nits / spelling issues:=20 > in section "Abstract": > - s/Experience has show that/Experience has shown that Fixed > - speaking of acronyms, the first mention of TLSA should spell it out.=20= I added:=20 (TLSA is not an acronym but a name ) > Thank you and best regards.=20 >=20 > Tobias Hope this addresses your concerns Olafur --Apple-Mail=_EC78EBE6-7F7B-41C2-941D-46FD2DD081DE Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Thanks Tobias for the review 

On Jan 29, 2014, at 12:29 PM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:

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


The document is basically just about acronyms to simplify DANE conversations
The document appears ready for publication.

The security consideration section is sufficient and there are no security issues with this document.

There are only two small nits / spelling issues:
in section "Abstract":
- s/Experience has show that/Experience has shown that

Fixed
- speaking of acronyms, the first mention of TLSA should spell it out.

I added: 
(TLSA is not an acronym but a name )

Thank you and best regards.

Tobias

Hope this addresses your concerns

Olafur

--Apple-Mail=_EC78EBE6-7F7B-41C2-941D-46FD2DD081DE-- From nobody Fri Feb 14 10:28:48 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B33B1A03DB; Fri, 14 Feb 2014 10:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JI-YfCqYq7C; Fri, 14 Feb 2014 10:28:41 -0800 (PST) Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6A21A03D3; Fri, 14 Feb 2014 10:28:41 -0800 (PST) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=c9nI/1DNZ46On3cdTiz4zR2k22F+AG8vhyRYC55XfCcKfhAcAtJ9AhHt5zl10qt/ExBJykNxiGemLPsU9v7IQrCITbcBk968J8osZVz6kw/xAttR5h4uXTew+LmuqIR54Lh31a5B24y1jVZW1GZ41UA17h7IAk6J6uLk1oAw03w=; h=X-No-Relay:X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Priority:References:In-Reply-To:X-Enigmail-Version:Content-Type; X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.6] (2e40e8bc.skybroadband.com [46.64.232.188]) by www.gondrom.org (Postfix) with ESMTPSA id D9A0315390014; Fri, 14 Feb 2014 19:28:36 +0100 (CET) Message-ID: <52FE6054.3050705@gondrom.org> Date: Fri, 14 Feb 2014 18:28:36 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ogud@ogud.com X-Priority: 4 (Low) References: <52101187.2060409@gondrom.org> <5293E22B.90705@gondrom.org> <52E93A6B.9020400@gondrom.org> <19D1C94B-B284-45D6-AFDE-A1781B633F72@ogud.com> In-Reply-To: <19D1C94B-B284-45D6-AFDE-A1781B633F72@ogud.com> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------040108020603080208040102" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/2jJTt3MwtWUBQNsslFhasKVD3lo Cc: iesg@ietf.org, draft-ietf-dane-registry-acronyms.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dane-registry-acronyms-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:28:44 -0000 This is a multi-part message in MIME format. --------------040108020603080208040102 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thank you. Yes, your reply answers all my questions. Thanks and all the best, Tobias On 14/02/14 18:14, Olafur Gudmundsson wrote: > Thanks Tobias for the review > > On Jan 29, 2014, at 12:29 PM, Tobias Gondrom > > wrote: > >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> >> The document is basically just about acronyms to simplify DANE >> conversations >> The document appears ready for publication. >> >> The security consideration section is sufficient and there are no >> security issues with this document. >> >> There are only two small nits / spelling issues: >> in section "Abstract": >> - s/Experience has show that/Experience has shown that > > Fixed >> - speaking of acronyms, the first mention of TLSA should spell it out. > > I added: > (TLSA is not an acronym but a name ) > >> Thank you and best regards. >> >> Tobias > > Hope this addresses your concerns > > Olafur > --------------040108020603080208040102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Thank you.
Yes, your reply answers all my questions.
Thanks and all the best, Tobias


On 14/02/14 18:14, Olafur Gudmundsson wrote:
Thanks Tobias for the review 

On Jan 29, 2014, at 12:29 PM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:

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


The document is basically just about acronyms to simplify DANE conversations
The document appears ready for publication.

The security consideration section is sufficient and there are no security issues with this document.

There are only two small nits / spelling issues:
in section "Abstract":
- s/Experience has show that/Experience has shown that

Fixed
- speaking of acronyms, the first mention of TLSA should spell it out.

I added: 
(TLSA is not an acronym but a name )

Thank you and best regards.

Tobias

Hope this addresses your concerns

Olafur


--------------040108020603080208040102-- From nobody Fri Feb 14 19:08:09 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479371A0035; Fri, 14 Feb 2014 19:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_261O076idQ; Fri, 14 Feb 2014 19:08:02 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC501A001E; Fri, 14 Feb 2014 19:08:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBD63210; Sat, 15 Feb 2014 03:07:57 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 03:07:33 +0000 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 03:07:54 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.63]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.03.0158.001; Sat, 15 Feb 2014 11:07:50 +0800 From: Tina TSOU To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-dunbar-armd-arp-nd-scaling-practices@tools.ietf.org" Thread-Topic: SECDIR early review of draft-dunbar-armd-arp-nd-scaling-practices-07 Thread-Index: AQHPKfsc65F4O1ntVkqzN1q05nHFcA== Date: Sat, 15 Feb 2014 03:07:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.87.91] Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A818119BA2szxeml557mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Yo2yDjcuJbfLDaYVP0Byb9rZFlA Subject: [secdir] SECDIR early review of draft-dunbar-armd-arp-nd-scaling-practices-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 03:08:05 -0000 --_000_C0E0A32284495243BDE0AC8A066631A818119BA2szxeml557mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I have reviewed this document as part of the security directorate's ongoing= effort to for early review of WG drafts. These comments were written prim= arily for the benefit of the security area directors. Document editors and= working group chairs should treat these comments just like any other comme= nts. Section 1: Please expand ToR upon first occurrence. Section 2, page 3/4: Could you please clarify the difference between "node" and "end station"? A= re they synonyms? Section 5.1.1: Shouldn't it be possible to avoid ND load by proper setting of the Reachabl= eTime variable? -- This wouldn't require any protocol changes. Section 5.1.1: Snooping ARP packets probably means increased load (a disadvantage you didn= 't mention). Section 5.1.1: When address resolution is needed to deliver a packet, some routers just dr= op the packet when they engage in ARP (see http://tools.ietf.org/html/rfc62= 74#section-4.2.3). The same is true for IPv6 ND. Section 8: While this document does not introduce new issues itself, it should at leas= t mention how the same ARP/ND issues may be intentionally triggered by an a= ttacker. For example, you may reference RFC 6583 * Nits Section 4, page 4: > There are no address > resolution issue in this design. Replace "issue" with "issues" Section 5.1.1, page 5: "Ipv6" -> "IPv6" Section 5.1.2: Please expand UNA (possibly in the terminology section) -- you probably mea= n "Unsolicited..", but this should be explicit. Thank you, Tina From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Matthew Lepinski Sent: Friday, February 14, 2014 2:52 AM To: secdir@ietf.org; iesg@ietf.org; draft-housley-pkix-oids.all@tools.ietf.= org Subject: [secdir] SECDIR review of draft-housley-pkix-oids 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 working group chairs should treat these comments j= ust like any other last call comments. This document returns control of the PKIX object identifier arc to IANA. Th= at is, it establishes a new IANA registry for OIDs in the PKIX arc and popu= lates that registry with the existing OID assignments. Finally, the documen= t establishes expert review as the criteria for future additions to the reg= istry and includes guidance that for review. After reviewing the document, I agree with the author that this document in= troduces no new security concerns. I found no issues in the document and I believe it is ready for publication= . ------------------------------- Nits The author should consider including an expansion of the acronym SMI, which= is used frequently in the document. (I believe in this context SMI =3D Str= ucture of Management Information) In Section 3: s/be related to X.509 certificate/be related to X.509 certificates/ In Section 3.1: s/to points to this document/to point to this document/ --_000_C0E0A32284495243BDE0AC8A066631A818119BA2szxeml557mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear  all,<= /span>

I have reviewed this docume= nt as part of the security directorate's ongoing effort to for early review of WG drafts.  These comments were written primarily for= the benefit of the security area directors.  Document editors and wor= king group chairs should treat these comments just like any other comments.=

 

Section 1:

Please expand ToR upon firs= t occurrence.

 

Section 2, page 3/4:

Could you please clarify th= e difference between "node" and "end station"? Are they= synonyms?

 

 

Section 5.1.1:

 

Shouldn't it be possible to= avoid ND load by proper setting of the ReachableTime variable? -- This wouldn't require any protocol changes.

 

 

Section 5.1.1:

 

Snooping ARP packets probab= ly means increased load (a disadvantage you didn't mention).

 

 

Section 5.1.1:

 

When address resolution is = needed to deliver a packet, some routers just drop the packet when they engage in ARP (see http://tools.ietf.org/html/rfc6274#section-4.2.3). The same is true for=

IPv6 ND.<= /p>

 

 

Section 8:

 

While this document does no= t introduce new issues itself, it should at least mention how the same ARP/ND issues may be intentionally triggered by an attacker. For = example, you may reference RFC 6583

 

 

* Nits

 

Section 4, page 4:

> There are no address

>    reso= lution issue in this design.

 

Replace "issue" w= ith "issues"

 

 

Section 5.1.1, page 5:=

 

"Ipv6" -> &quo= t;IPv6"

 

 

Section 5.1.2:

 

Please expand UNA (possibly= in the terminology section) -- you probably mean "Unsolicited.."= , but this should be explicit.

 

 

Thank you,

Tina

<= o:p> 

From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Matthew Lepinski
Sent: Friday, February 14, 2014 2:52 AM
To: secdir@ietf.org; iesg@ietf.org; draft-housley-pkix-oids.all@tool= s.ietf.org
Subject: [secdir] SECDIR review of draft-housley-pkix-oids

 

I have reviewed this docume= nt 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.  Do= cument editors and working group chairs should treat these comments just li= ke any other last call comments.

 

This document returns control of the PKIX o= bject identifier arc to IANA. That is, it establishes a new IANA registry f= or OIDs in the PKIX arc and populates that registry with the existing OID assignments. Finally, the document establishes expert review = as the criteria for future additions to the registry and inc= ludes guidance that for review.<= /o:p>

 

After reviewing the document, I agree with = the author that this document introduces no new security concerns. 

 

I found no issues in the document and I bel= ieve it is ready for publication.

 

-------------------------------

 

Nits=

 

The author should consider including an exp= ansion of the acronym SMI, which is used frequently in the docume= nt. (I believe in this context SMI =3D Structure of Management Information)=

 

In Section 3:

s/be related to X.509 certificate/be related to X.509 certificates/<= /span>

 

In Section 3.1: 

s/to points to this document/to point to this document/

 

 

 

--_000_C0E0A32284495243BDE0AC8A066631A818119BA2szxeml557mbschi_-- From nobody Mon Feb 17 06:26:09 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796991A01FA; Mon, 17 Feb 2014 06:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKVtf17RKp_0; Mon, 17 Feb 2014 06:26:05 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDC21A01D8; Mon, 17 Feb 2014 06:26:05 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C232710224008; Mon, 17 Feb 2014 06:26:02 -0800 (PST) Received: from 129.192.185.164 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 17 Feb 2014 06:26:03 -0800 (PST) Message-ID: <2910582168899709b7211d3cea87c29d.squirrel@www.trepanning.net> In-Reply-To: References: Date: Mon, 17 Feb 2014 06:26:03 -0800 (PST) From: "Dan Harkins" To: "Richard Alimi" 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 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/k_jR1JWpFTJVew6RbEU7YCFZkK8 Cc: secdir@ietf.org, "draft-ietf-alto-protocol.all@tools.ietf.org" , iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-alto-protocol X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 14:26:07 -0000 Hi Richard, On Sun, February 9, 2014 10:58 pm, Richard Alimi wrote: > Thank you very much for the review! > > Responses inline... > > > On Sat, Feb 1, 2014 at 10:54 AM, Dan Harkins wrote: > >> [snip] >> - 6.1.2, while a particular Cost Map may contain only one of the >> two cost modes, servers MUST implement support for both, >> right? It's not clear from the text. >> > > Servers only need to implement at least one, but not necessarily both. > Section 6.1.2 states the following: > > > An ALTO Server MUST support at least one of 'numerical' and 'ordinal' > modes. > > > Can you suggest which text was misleading so that we can address it? It's not clear to me how this interoperates unless it's possible to infer one from the other and if that's the case then why are there two things to choose to support? [snip] >> >> - 15.3.2, the Security Considerations section seems an odd >> place for normative language-- "HTTP Digest authentication >> MUST be supported". I suggest finding a more appropriate >> place, perhaps 8.3.5, to spell out normative requirements. >> Also, authenticating the client in the TLS exchange would >> be much preferable and I think mention should be made >> on that option. I think differentiated authorization (see >> my previous comment) would be easier this way too. >> > > Good point - we will move the normative requirement for HTTP digest > authentication to 8.3.5. The existing text in 8.3.5 states > > When server and/or client authentication, encryption, and/or > integrity protection are required, an ALTO Server MUST support SSL/ > TLS [RFC5246 ] as a mechanism. > > > Should I interpret your comment to say that we should suggest TLS client > authentication over HTTP digest authentication, or to reword to make it > more explicit that TLS client authentication is an option? Well I think client authentication is mandatory, it's just whether it's provided as part of the TLS exchange or using HTTP digest auth. And yes I suggest making TLS client auth preferred over HTTP digest auth. regards, Dan. From nobody Mon Feb 17 06:38:43 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED531A0212; Mon, 17 Feb 2014 06:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3rO-7RPqfYH; Mon, 17 Feb 2014 06:38:37 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3077A1A0211; Mon, 17 Feb 2014 06:38:37 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 5808C10224008; Mon, 17 Feb 2014 06:38:34 -0800 (PST) Received: from 129.192.185.164 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 17 Feb 2014 06:38:34 -0800 (PST) Message-ID: In-Reply-To: References: <23845_1391280851_s11IsAD0008772_cd3fb9f2748d08183af6652c0d58f61a.squirrel@www.trepanning.net> <1391369584.4360.72.camel@destiny.pc.cs.cmu.edu> <943e83dcb64a8666ea82900f013b2b9b.squirrel@www.trepanning.net> Date: Mon, 17 Feb 2014 06:38:34 -0800 (PST) From: "Dan Harkins" To: "Richard Alimi" 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 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/HuvbaYTNWsgoE5EFYhqRSHMOPlI Cc: iesg@ietf.org, "draft-ietf-alto-protocol.all@tools.ietf.org" , secdir@ietf.org, Jeffrey Hutzelman Subject: Re: [secdir] secdir review of draft-ietf-alto-protocol X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 14:38:39 -0000 Hi RIchard, On Sun, February 9, 2014 11:03 pm, Richard Alimi wrote: > On Sun, Feb 2, 2014 at 7:08 PM, Dan Harkins wrote: > >> >> On Sun, February 2, 2014 11:33 am, Jeffrey Hutzelman wrote: >> > On Sat, 2014-02-01 at 10:54 -0800, Dan Harkins wrote: >> > >> >> Also, given those >> >> restrictions and the fact that a tag just has to be less than >> >> or equal to 64 octets, the probability of identical tags being >> >> used is not zero. I think the probability of the tag from >> >> example 11.3.1.7 is 0.5 to collide with one of just 460 >> >> other Network Maps. >> >> >> >> I suggest requiring a tag to be 64 octets. That will make >> >> even money probability of collision among nearly 3000 >> >> other Network Maps, which is safer. >> > >> > OK, maybe I'm confused and reading out of context here. But I once >> had >> > someone tell me I needed to change my 5-character username because >> they >> > were requiring all usernames to be at least 6 characters, _in order to >> > increase the number of possible usernames_. That is, they claimed >> they >> > were increasing the size of a namespace by eliminating possible names. >> >> Well that's a hair brained policy, but username selection is not a >> good >> analogy. I was at a company that had no strict requirements on a >> username >> so there should have been a near infinite size of the namespace. But we >> had >> a collision when the company had less than 10 employees because there >> was another "dan" at the company. >> >> > The point is, if a tag is required to be exactly 64 octets, you get >> > 0x5e^64 possible tags. But if it is required to be up to 64 octets, >> you >> > get Sum(i=0..64) 0x5e^i possible tags, which is strictly greater than >> > 0x5e^64. So, requiring a tag to be 64 octets _reduces_ the number of >> > possible tags, thereby increasing the chance of collision. >> >> That would be the case if all tags in the Sum(i=1..64) 0x5e^i tagspace >> were equally probable of being chosen. Which implies implementations >> choosing a random tag length for each tag generated in addition to a >> random tag selection scheme for the randomly chosen length. I suspect, >> though, that in practice the tag length will be fixed for a particular >> implementation and the tag selection scheme will not necessarily be >> random. So the herd mentality, plus the proliferation of one or two >> companies' ALTO servers, will result in a severely reduced size of the >> effective tagspace and the increased possibility of collisions. >> >> A tag generated as SHA256(NetworkMap) represented in 64 hex >> characters would basically guarantee you'd never have a collision. >> Saying, "it can be anything you want as long as it's less than 64 >> octets" would not. >> > > Should I interpret your comment to say that we should to require > particular > mechanisms for generating version tags, or be more explicit about > suggesting mechanisms that have a low collision probability? Yes, I think you should. Suggestions on how to ensure a low probability of collision would be helpful. > To help steer readers towards better implementation practices, we'll > change > the examples to use hashes in the version tags. That's a great idea. So people who implement ALTO and check the example will use hashes themselves and that will help ensure a low probability of collision. > Thank you again for the review! You're very welcome! regards, Dan. From nobody Mon Feb 17 07:57:51 2014 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C029C1A03DD; Sun, 16 Feb 2014 03:43:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1392550985; bh=vUav5bpEqXU32tRJJgMccGKHVyIh9POmzPfKsb49eEY=; h=From:To:Date:Message-ID:MIME-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=i+xLUVg56dTUoxFCPDGzD6Jdy7c6FYjVkyTyRubvaLycujAumWbsrz/u1KvdMQhNK mHXPBco6TBeJ05dTvr3Uucb6NyKNodpBgWOnVq7CsDnaKCYdenvL4EiusbMnUHKtNJ 4NZDk6g7VTDshbTzdy3IOPmHcV2cyvg3Jgtv/rPc= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80891A03DB for ; Sun, 16 Feb 2014 03:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9B26DbMuQlls for ; Sun, 16 Feb 2014 03:43:01 -0800 (PST) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) by ietfa.amsl.com (Postfix) with ESMTP id D4AB31A01BC for ; Sun, 16 Feb 2014 03:43:00 -0800 (PST) X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos;i="4.95,855,1384322400"; d="scan'208,217";a="540409471" From: To: Date: Sun, 16 Feb 2014 05:42:56 -0600 Thread-Topic: IEEE 802 New Work Under Consideration @ Mar 2014 Plenary Thread-Index: Ac8rCs7pcMvdmEJ8QJ+DB/MNCqnPUw== Message-ID: <28616F4740DDF542AA1DB7C9F597963907A89E8B28@AUSX7MCPS301.AMER.DELL.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/01CYhVeRDkNM3JljUWOUqx7XgmU X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Type: multipart/mixed; boundary="===============1891188158559840693==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/RIxF_W2bVrEW3gbaUF33uO6E2kg X-Mailman-Approved-At: Mon, 17 Feb 2014 07:57:49 -0800 Cc: paul.nikolich@att.net Subject: [secdir] [new-work] IEEE 802 New Work Under Consideration @ Mar 2014 Plenary X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 11:43:06 -0000 --===============1891188158559840693== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_28616F4740DDF542AA1DB7C9F597963907A89E8B28AUSX7MCPS301A_" --_000_28616F4740DDF542AA1DB7C9F597963907A89E8B28AUSX7MCPS301A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, The following Project Authorization Requests (PARs) will be considered at t= he March 2014 IEEE 802 Plenary: * 802.3bp - amendment: 1 Gb/s Operation over Single Twisted Pair Copper = Cable, PAR modification request and unmodified CSD responses (grandfathered 5 Criteria responses) * 802.3bs - amendment: 400 Gb/s Ethernet, PAR and CSD * 802.11 HEW (High Efficiency WLAN), PAR and CSD * 802.15d 100Gbps wireless switched point-to-point physical layer, PAR and CSD * 802.15r Radio based Distance Measurement Techniques , PAR and CSD * 802.22 Revision PAR for 802.22-2011, PAR and CSD The PARs can be found at http://www.ieee802.org/PARs.shtml#PAR_1403 along w= ith the supporting IEEE 802 Criteria for Standards Development, or CSD, (wh= ich includes the 5 criteria, i.e. the explanations of how they fit the IEEE= 802 criteria for initiating new work). Any comments on a proposed PAR should be sent to the Working Group chair id= entified on the PAR to be received by 5:00 PM (CST), Tuesday, Mar 18, 2014 = (9:00am UTC Mar 18, 2014). Regards, John D'Ambrosia IEEE 802 LMSC Recording Secretary --_000_28616F4740DDF542AA1DB7C9F597963907A89E8B28AUSX7MCPS301A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

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

The PARs can be found at http://www.ieee802.org/PARs.shtml#PAR_1403 along with the suppor= ting IEEE 802 Criteria for Standards Development, or CSD, (which includes t= he 5 criteria, i.e. the explanations of how they fit the IEEE 802 criteria = for initiating new work).

Any comments on a proposed PAR should be sent to the Worki= ng Group chair identified on the PAR to be received by 5:00 PM (CST), Tuesd= ay, Mar 18, 2014 (9:00am UTC Mar 18, 2014).

Regards,

John D’Ambrosia

IEEE 802 LMSC = Recording Secretary

 

= --_000_28616F4740DDF542AA1DB7C9F597963907A89E8B28AUSX7MCPS301A_-- --===============1891188158559840693== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============1891188158559840693==-- From nobody Mon Feb 17 13:10:58 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06CD1A029B for ; Mon, 17 Feb 2014 13:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipYACaInLEr0 for ; Mon, 17 Feb 2014 13:10:51 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id D09891A028F for ; Mon, 17 Feb 2014 13:10:50 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id tp5so765049ieb.27 for ; Mon, 17 Feb 2014 13:10:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wH5LQIaamuy14n4pE9v0MFD/z5Gyn5o11NYfjLsEoo4=; b=ft6fr5H22sJZ6OUf7HX1Q8kz//7F+SkfpF8K18RF2E5rB0jdl+sinNxpQz7Vyt1BLk pLVxEabBIdFLSbzm06lwZT1fF1f+/4MHwEWMCAvJIV/PIvmljDyJpJppJjKHu4BG5zsK xi9nrJ1zkk0mkG8o8pF6vAZcL/KebNsM6Jo719aerFCo+IONtSldOJGQSuFgxOUUjAIH yWeDLKYyAhpzo9Z9u2SHmNsvW3f+7/QPU5h8B8aoZWtpwW4GsKiHVurD4k/njr6s8sUC Tf4288WUvJMo/iM2zcg7AMyHzMV1P7OAsJ5Lk0WiCguAiBgLK+1J1ujOKQY50CqaMt5Q bMkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wH5LQIaamuy14n4pE9v0MFD/z5Gyn5o11NYfjLsEoo4=; b=VSbwym8V8Vnck7+As9i9ilY/VWKLZXQuDwp5R2cOUtwODvyfReDknT8cnyZ3VzF6N0 20wT88JTaICt4UTuCgxOZuv+y9ZkbiI9Xv0nq6jVRc4pU3zXSnKgZvjdIHnwsQLROwTP /6vggec/CzD9kQC0iCE8X9rV+j9cX/ww5J9iNHROMkI5ZJU3QSt8D74XZ7wwB1zV4yKk 3391CHEsGjKnnfzg/ssCXebbU/A4CmwVOBvwcVB0rmEbI5T+uh1YmmRSjEhtHmbvw4+j zzDakk8ht76OcfG1pSp9Lzm0GE5VnLStiPM7GSE4Z0j1s7ABz2WQivfA/B3nErHUX4pv Ppfg== X-Gm-Message-State: ALoCoQlIDeRaK5ue+Y1wgISWloikc97sbPugQfdqQ2CTDrJ8F5tRaozl3BJ839Rxq6MvKJRkTQJR4ysxP8HX8vC9FiPn65HwA9LHLanUwe5LbVKdyYsDwsQXnAKE7VxwuRVigXzicFxPSVYPWmAqbHXaXEOMWifOrlomHPk0EYbDyICtHBNZ930QiSbBqubT03r7bClFQYI9 X-Received: by 10.42.97.193 with SMTP id p1mr19494186icn.32.1392671448012; Mon, 17 Feb 2014 13:10:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.56.228 with HTTP; Mon, 17 Feb 2014 13:10:17 -0800 (PST) In-Reply-To: <2910582168899709b7211d3cea87c29d.squirrel@www.trepanning.net> References: <2910582168899709b7211d3cea87c29d.squirrel@www.trepanning.net> From: Richard Alimi Date: Mon, 17 Feb 2014 13:10:17 -0800 Message-ID: To: Dan Harkins Content-Type: multipart/alternative; boundary=20cf30363965f2d3fb04f2a0964f Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8MSLcmcHoLXkp_EwKbaMQEH27ZQ Cc: "draft-ietf-alto-protocol.all@tools.ietf.org" , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-alto-protocol X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 21:10:54 -0000 --20cf30363965f2d3fb04f2a0964f Content-Type: text/plain; charset=UTF-8 On Mon, Feb 17, 2014 at 6:26 AM, Dan Harkins wrote: > > Hi Richard, > > On Sun, February 9, 2014 10:58 pm, Richard Alimi wrote: > > Thank you very much for the review! > > > > Responses inline... > > > > > > On Sat, Feb 1, 2014 at 10:54 AM, Dan Harkins > wrote: > > > >> > [snip] > >> - 6.1.2, while a particular Cost Map may contain only one of the > >> two cost modes, servers MUST implement support for both, > >> right? It's not clear from the text. > >> > > > > Servers only need to implement at least one, but not necessarily both. > > Section 6.1.2 states the following: > > > > > > An ALTO Server MUST support at least one of 'numerical' and 'ordinal' > > modes. > > > > > > Can you suggest which text was misleading so that we can address it? > > It's not clear to me how this interoperates unless it's possible to infer > one from the other and if that's the case then why are there two things > to choose to support? > The key is that the client needs to handle both types, not the server. During working group discussions, it was not clear that a server would always wish to provide both and may opt to expose one or the other. For example, one cited reason for a server not exposing numerical costs was concerns over revealing too many details of internal network topology. It is possible to derive ordinal costs from numerical costs. Thus, we could require servers to provide ordinal costs and optionally provide numerical costs. We opted to put this logic in the client-side, though, in the interest of keeping the server simpler. Richard/Reinaldo: do you believe this is still a reasonable tradeoff and am I missing any other rationale for this? I'm typically on the side of keeping servers simpler, but we could reconsider if necessary. > > [snip] > >> > >> - 15.3.2, the Security Considerations section seems an odd > >> place for normative language-- "HTTP Digest authentication > >> MUST be supported". I suggest finding a more appropriate > >> place, perhaps 8.3.5, to spell out normative requirements. > >> Also, authenticating the client in the TLS exchange would > >> be much preferable and I think mention should be made > >> on that option. I think differentiated authorization (see > >> my previous comment) would be easier this way too. > >> > > > > Good point - we will move the normative requirement for HTTP digest > > authentication to 8.3.5. The existing text in 8.3.5 states > > > > When server and/or client authentication, encryption, and/or > > integrity protection are required, an ALTO Server MUST support SSL/ > > TLS [RFC5246 ] as a mechanism. > > > > > > Should I interpret your comment to say that we should suggest TLS client > > authentication over HTTP digest authentication, or to reword to make it > > more explicit that TLS client authentication is an option? > > Well I think client authentication is mandatory, it's just whether it's > provided as part of the TLS exchange or using HTTP digest auth. And > yes I suggest making TLS client auth preferred over HTTP digest auth. > I've added the following text to Section 8.3.5: For deployment scenarios where client authentication is desired, HTTP Digest Authentication MUST be supported. TLS Client Authentication is the preferred mechanism if it is available. There was extensive discussion at an earlier point on the list about whether or not we should require TLS in all implementations, so unless you feel it is absolutely necessary I'd prefer to not revisit that and add a requirement that TLS client authentication be supported. I've also made the language in 15.3.2 non-normative. > regards, > > Dan. > > > --20cf30363965f2d3fb04f2a0964f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 17, 2014 at 6:26 AM, Dan Harkins <= dharkins@lounge.or= g> wrote:

=C2=A0 Hi Richard,

On Sun, February 9, 2014 10:58 pm, Richard Alimi wrote:
> Thank you very much for the review!
>
> Responses inline...
>
>
> On Sat, Feb 1, 2014 at 10:54 AM, Dan Harkins <dharkins@lounge.org> wrote:
>
>>
[snip]
>> =C2=A0 - 6.1.2, while a particular Cost Map may co= ntain only one of the
>> =C2=A0 =C2=A0 =C2=A0two cost modes, servers MUST implement support= for both,
>> =C2=A0 =C2=A0 =C2=A0right? It's not clear from the text.
>>
>
> Servers only need to implement at least one, but not necessarily both.=
> =C2=A0Section 6.1.2 states the following:
>
>
> =C2=A0 =C2=A0An ALTO Server MUST support at least one of 'numerica= l' and 'ordinal'
> =C2=A0 =C2=A0modes.
>
>
> Can you suggest which text was misleading so that we can address it?
=C2=A0 It's not clear to me how this interoperates unless it'= s possible to infer
one from the other and if that's the case then why are there two things=
to choose to support?

The key is that t= he client needs to handle both types, not the server. =C2=A0During working = group discussions, it was not clear that a server would always wish to prov= ide both and may opt to expose one or the other.

For example, one cited reason for a server not exposing= numerical costs was concerns over revealing too many details of internal n= etwork topology.

It is possible to derive ordinal = costs from numerical costs. =C2=A0Thus, we could require servers to provide= ordinal costs and optionally provide numerical costs. =C2=A0We opted to pu= t this logic in the client-side, though, in the interest of keeping the ser= ver simpler.

Richard/Reinaldo: do you believe this is still a reason= able tradeoff and am I missing any other rationale for this? =C2=A0I'm = typically on the side of keeping servers simpler, but we could reconsider i= f necessary.
=C2=A0

[snip]
>>
>> =C2=A0 - 15.3.2, the Security Considerations section seems an odd<= br> >> =C2=A0 =C2=A0 =C2=A0place for normative language-- "HTTP Dige= st authentication
>> =C2=A0 =C2=A0 =C2=A0MUST be supported". I suggest finding a m= ore appropriate
>> =C2=A0 =C2=A0 =C2=A0place, perhaps 8.3.5, to spell out normative r= equirements.
>> =C2=A0 =C2=A0 =C2=A0Also, authenticating the client in the TLS exc= hange would
>> =C2=A0 =C2=A0 =C2=A0be much preferable and I think mention should = be made
>> =C2=A0 =C2=A0 =C2=A0on that option. I think differentiated authori= zation (see
>> =C2=A0 =C2=A0 =C2=A0my previous comment) would be easier this way = too.
>>
>
> Good point - we will move the normative requirement for HTTP digest > authentication to 8.3.5. =C2=A0The existing text in 8.3.5 states
>
> =C2=A0 =C2=A0When server and/or client authentication, encryption, and= /or
> =C2=A0 =C2=A0integrity protection are required, an ALTO Server MUST su= pport SSL/
> =C2=A0 =C2=A0TLS [RFC5246 <http://tools.ietf.org/html/rfc5246>] = as a mechanism.
>
>
> Should I interpret your comment to say that we should suggest TLS clie= nt
> authentication over HTTP digest authentication, or to reword to make i= t
> more explicit that TLS client authentication is an option?

=C2=A0 Well I think client authentication is mandatory, it's just= whether it's
provided as part of the TLS exchange or using HTTP digest auth. And
yes I suggest making TLS client auth preferred over HTTP digest auth.

I've added the following text to Section= 8.3.5:

=C2=A0 For deployment scenarios where clie= nt authentication is desired,
=C2=A0 HTTP Digest Authentication MUST be supported. =C2=A0TLS C= lient Authentication
=C2=A0 is the preferred mechanism if it = is available.

There was extensive discussion at an= earlier point on the list about whether or not we should require TLS in al= l implementations, so unless you feel it is absolutely necessary I'd pr= efer to not revisit that and add a requirement that TLS client authenticati= on be supported.

I've also made the language in 15.3.2 non-normative= .


=C2=A0 regards,

=C2=A0 Dan.



--20cf30363965f2d3fb04f2a0964f-- From nobody Mon Feb 17 13:47:03 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384171A0408 for ; Mon, 17 Feb 2014 13:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMKxtHEkM8nX for ; Mon, 17 Feb 2014 13:46:55 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 25BAC1A02A3 for ; Mon, 17 Feb 2014 13:46:55 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id c10so5947550igq.0 for ; Mon, 17 Feb 2014 13:46:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eFhdpKWqleT/XkGbBV15e06LTO9SJ4S+hbqexX4+Yfc=; b=FbznMSEBvR2kTMH/8CMWl1L1fpuIjqB4Xd5mFEwKK6KQobRbO1o3ohF6DiKsJMHB9o Vp4ULfHdJQjC3RMAyokxKocT64IEeD18ssQuH61JabvT2HYMiAotpa60gRheqaix+rAJ KF4GRx1RuErILWialE+bSLOhOrP0ALoFysuDfuavAbbAiohQFSAT8F3taMNDyxD6AK8I 83rZztNmPPF0CQ+RkWNINSZTOFCwEnGqz3VwVrCzSXl0EV+mN++ffS282h0UtZ/Rs/Hr BPSrY+GOb3ZNHv+ye6d2F84OXtLkVSN1/47/Sp8txRV1oOFkADcGhUiJ6n6TNgo6o3M0 VwiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eFhdpKWqleT/XkGbBV15e06LTO9SJ4S+hbqexX4+Yfc=; b=cb5OMp95+vFEIVRf5WxmxUExpkQwoTf0rCUK48oo8gxxaSVG6YogUJD7ARvbZhky2S /xk6o/9jMpgCLqquz26w6nCuI6gAC4rwdPutLQeTSMX1UOUhwsl3QOIzZy4WyexXn6/S T1mnbr+9AHtbyBurNnFmcdIdKN9XRrwvhaFE85kJMETbebbpfHXkyDg66idiEZ6KOGNT BbDTdHFcb611vU9cLz/Zv/WjzFpv8dAKDH2YWSAewuhQr62PlC4tLhSwgGt8UlG+664s mjA07NfAPuY2erY0peCkuytkYvDKEc6NaaYwuLyfcxZrSlJ5zLJXUAW8Hd1OFUdstPdq M9Kw== X-Gm-Message-State: ALoCoQm9p0tnoye36yIQtgjh9KeziNTi6HzD+FeSNtiYHlQXjJ8XlW0W5ajUgK0Os/B2FChgw7TGd7qLMmKxf53Dy32IAKdJ6Ce0dp8AYzWuDPJX+YkE/lwXHxlvE6oSfrOlTJdUPeCfIhaqHWAmZEat7l5bqOGpFyFZwRmW2OnJBF9dIJQ302kDt1uuBYSPCtNhH8VQxu9Y X-Received: by 10.50.194.200 with SMTP id hy8mr8809567igc.25.1392673612266; Mon, 17 Feb 2014 13:46:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.56.228 with HTTP; Mon, 17 Feb 2014 13:46:22 -0800 (PST) In-Reply-To: References: <23845_1391280851_s11IsAD0008772_cd3fb9f2748d08183af6652c0d58f61a.squirrel@www.trepanning.net> <1391369584.4360.72.camel@destiny.pc.cs.cmu.edu> <943e83dcb64a8666ea82900f013b2b9b.squirrel@www.trepanning.net> From: Richard Alimi Date: Mon, 17 Feb 2014 13:46:22 -0800 Message-ID: To: Dan Harkins Content-Type: multipart/alternative; boundary=14dae934100df2a2a804f2a1170b Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/VeWHaKNXiPbAOVAyL4aR6KbxdkQ Cc: secdir@ietf.org, "draft-ietf-alto-protocol.all@tools.ietf.org" , iesg@ietf.org, Jeffrey Hutzelman Subject: Re: [secdir] secdir review of draft-ietf-alto-protocol X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 21:46:58 -0000 --14dae934100df2a2a804f2a1170b Content-Type: text/plain; charset=UTF-8 On Mon, Feb 17, 2014 at 6:38 AM, Dan Harkins wrote: > > Hi RIchard, > > On Sun, February 9, 2014 11:03 pm, Richard Alimi wrote: > > On Sun, Feb 2, 2014 at 7:08 PM, Dan Harkins wrote: > > > >> > >> On Sun, February 2, 2014 11:33 am, Jeffrey Hutzelman wrote: > >> > On Sat, 2014-02-01 at 10:54 -0800, Dan Harkins wrote: > >> > > >> >> Also, given those > >> >> restrictions and the fact that a tag just has to be less than > >> >> or equal to 64 octets, the probability of identical tags being > >> >> used is not zero. I think the probability of the tag from > >> >> example 11.3.1.7 is 0.5 to collide with one of just 460 > >> >> other Network Maps. > >> >> > >> >> I suggest requiring a tag to be 64 octets. That will make > >> >> even money probability of collision among nearly 3000 > >> >> other Network Maps, which is safer. > >> > > >> > OK, maybe I'm confused and reading out of context here. But I once > >> had > >> > someone tell me I needed to change my 5-character username because > >> they > >> > were requiring all usernames to be at least 6 characters, _in order to > >> > increase the number of possible usernames_. That is, they claimed > >> they > >> > were increasing the size of a namespace by eliminating possible names. > >> > >> Well that's a hair brained policy, but username selection is not a > >> good > >> analogy. I was at a company that had no strict requirements on a > >> username > >> so there should have been a near infinite size of the namespace. But we > >> had > >> a collision when the company had less than 10 employees because there > >> was another "dan" at the company. > >> > >> > The point is, if a tag is required to be exactly 64 octets, you get > >> > 0x5e^64 possible tags. But if it is required to be up to 64 octets, > >> you > >> > get Sum(i=0..64) 0x5e^i possible tags, which is strictly greater than > >> > 0x5e^64. So, requiring a tag to be 64 octets _reduces_ the number of > >> > possible tags, thereby increasing the chance of collision. > >> > >> That would be the case if all tags in the Sum(i=1..64) 0x5e^i tagspace > >> were equally probable of being chosen. Which implies implementations > >> choosing a random tag length for each tag generated in addition to a > >> random tag selection scheme for the randomly chosen length. I suspect, > >> though, that in practice the tag length will be fixed for a particular > >> implementation and the tag selection scheme will not necessarily be > >> random. So the herd mentality, plus the proliferation of one or two > >> companies' ALTO servers, will result in a severely reduced size of the > >> effective tagspace and the increased possibility of collisions. > >> > >> A tag generated as SHA256(NetworkMap) represented in 64 hex > >> characters would basically guarantee you'd never have a collision. > >> Saying, "it can be anything you want as long as it's less than 64 > >> octets" would not. > >> > > > > Should I interpret your comment to say that we should to require > > particular > > mechanisms for generating version tags, or be more explicit about > > suggesting mechanisms that have a low collision probability? > > Yes, I think you should. Suggestions on how to ensure a low > probability of collision would be helpful. > We've added the following text to section 10.3: It is RECOMMENDED that the tag have a low collision probability with other tags. One suggested mechanism is to compute it using a hash of the data content of the resource. > > > To help steer readers towards better implementation practices, we'll > > change > > the examples to use hashes in the version tags. > > That's a great idea. So people who implement ALTO and check > the example will use hashes themselves and that will help ensure > a low probability of collision. > This change has been made to our copy in SVN. > > > Thank you again for the review! > > You're very welcome! > > regards, > > Dan. > > > --14dae934100df2a2a804f2a1170b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 17, 2014 at 6:38 AM, Dan Harkins <dharkins@lounge.org> wrote:

=C2=A0 Hi RIchard,

On Sun, February 9, 2014 11:03 pm, Richard Alimi wrote:
> On Sun, Feb 2, 2014 at 7:08 PM, Dan Harkins <dharkins@lounge.org> wrote:
>
>>
>> On Sun, February 2, 2014 11:33 am, Jeffrey Hutzelman wrote:
>> > On Sat, 2014-02-01 at 10:54 -0800, Dan Harkins wrote:
>> >
>> >> =C2=A0Also, given those
>> >> =C2=A0 =C2=A0 =C2=A0restrictions and the fact that a tag = just has to be less than
>> >> =C2=A0 =C2=A0 =C2=A0or equal to 64 octets, the probabilit= y of identical tags being
>> >> =C2=A0 =C2=A0 =C2=A0used is not zero. I think the probabi= lity of the tag from
>> >> =C2=A0 =C2=A0 =C2=A0example 11.3.1.7 is 0.5 to collide wi= th one of just 460
>> >> =C2=A0 =C2=A0 =C2=A0other Network Maps.
>> >>
>> >> =C2=A0 =C2=A0 =C2=A0I suggest requiring a tag to be 64 oc= tets. That will make
>> >> =C2=A0 =C2=A0 =C2=A0even money probability of collision a= mong nearly 3000
>> >> =C2=A0 =C2=A0 =C2=A0other Network Maps, which is safer. >> >
>> > OK, maybe I'm confused and reading out of context here. = =C2=A0But I once
>> had
>> > someone tell me I needed to change my 5-character username be= cause
>> they
>> > were requiring all usernames to be at least 6 characters, _in= order to
>> > increase the number of possible usernames_. =C2=A0That is, th= ey claimed
>> they
>> > were increasing the size of a namespace by eliminating possib= le names.
>>
>> =C2=A0 Well that's a hair brained policy, but username selecti= on is not a
>> good
>> analogy. I was at a company that had no strict requirements on a >> username
>> so there should have been a near infinite size of the namespace. B= ut we
>> had
>> a collision when the company had less than 10 employees because th= ere
>> was another "dan" at the company.
>>
>> > The point is, if a tag is required to be exactly 64 octets, y= ou get
>> > 0x5e^64 possible tags. =C2=A0But if it is required to be up t= o 64 octets,
>> you
>> > get Sum(i=3D0..64) 0x5e^i possible tags, which is strictly gr= eater than
>> > 0x5e^64. =C2=A0So, requiring a tag to be 64 octets _reduces_ = the number of
>> > possible tags, thereby increasing the chance of collision. >>
>> =C2=A0 That would be the case if all tags in the Sum(i=3D1..64) 0x= 5e^i tagspace
>> were equally probable of being chosen. Which implies implementatio= ns
>> choosing a random tag length for each tag generated in addition to= a
>> random tag selection scheme for the randomly chosen length. I susp= ect,
>> though, that in practice the tag length will be fixed for a partic= ular
>> implementation and the tag selection scheme will not necessarily b= e
>> random. So the herd mentality, plus the proliferation of one or tw= o
>> companies' ALTO servers, will result in a severely reduced siz= e of the
>> effective tagspace and the increased possibility of collisions. >>
>> =C2=A0 A tag generated as SHA256(NetworkMap) represented in 64 hex=
>> characters would basically guarantee you'd never have a collis= ion.
>> Saying, "it can be anything you want as long as it's less= than 64
>> octets" would not.
>>
>
> Should I interpret your comment to say that we should to require
> particular
> mechanisms for generating version tags, or be more explicit about
> suggesting mechanisms that have a low collision probability?

=C2=A0 Yes, I think you should. Suggestions on how to ensure a = low
probability of collision would be helpful.

<= div>We've added the following text to section 10.3:

It is RECOMMENDED=C2=A0that the tag have a low collision probability = with other tags. One suggested mechanism is to compute it using a hash of t= he data content of the resource.
=C2=A0

> To help steer readers towards better implementation practices, we'= ll
> change
> the examples to use hashes in the version tags.

=C2=A0 That's a great idea. So people who implement ALTO and chec= k
the example will use hashes themselves and that will help ensure
a low probability of collision.

This ch= ange has been made to our copy in SVN.
=C2=A0

> Thank you again for the review!

=C2=A0 You're very welcome!

=C2=A0 regards,

=C2=A0 Dan.



--14dae934100df2a2a804f2a1170b-- From nobody Mon Feb 17 14:28:20 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45991A04ED; Mon, 17 Feb 2014 14:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D_alj70KsY51; Mon, 17 Feb 2014 14:17:17 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF5D1A040A; Mon, 17 Feb 2014 14:17:17 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id fp1so15073266pdb.10 for ; Mon, 17 Feb 2014 14:17:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=TMwIFpOCz7ce16SqeitoWs79WSoA2IZjuSCsmYkBSfw=; b=JhrcS0ckbHaktLR6Sw7BkJEsXtkBrKbyB3jWaDV/1zfKePU/Am7BwtbrxZ2GwnIjnE KnG756nkMp+0/FJQp96ygyIcEt2LKIYfPMy43lgcpOrKbsIFDBuv2TxiCIz1P97Tz31H 3qhGHDjVy1A/mOPpRdCU+xKFyj6UUw+GARkYPewuZHHzLNR0cpuQBTlvzty4lA4EKngg hbyLA65ym4QaoJ/oF6154jg1uiwandx+gGAV/ef1SeXI4fB69vftAOgqhtgXgLGEL8P6 AeaT4X4sBBXbRJf9P7jF0a4eLrMTbkml8ylktXD+Cpw/Jpn4pjm7OoL82TdH4pVfESx0 AnzQ== MIME-Version: 1.0 X-Received: by 10.66.159.132 with SMTP id xc4mr28712375pab.27.1392675434564; Mon, 17 Feb 2014 14:17:14 -0800 (PST) Sender: yang.r.yang@gmail.com Received: by 10.68.144.168 with HTTP; Mon, 17 Feb 2014 14:17:14 -0800 (PST) In-Reply-To: References: <2910582168899709b7211d3cea87c29d.squirrel@www.trepanning.net> Date: Mon, 17 Feb 2014 17:17:14 -0500 X-Google-Sender-Auth: 5eyD31LmbCc2Es6FcE37q6rGNCc Message-ID: From: "Y. Richard Yang" To: Richard Alimi Content-Type: multipart/alternative; boundary=047d7b6d7a1090939104f2a1848b Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/MmhQ1pMKE868T-6MJadVL6u1uFA X-Mailman-Approved-At: Mon, 17 Feb 2014 14:28:18 -0800 Cc: secdir@ietf.org, "draft-ietf-alto-protocol.all@tools.ietf.org" , The IESG Subject: Re: [secdir] secdir review of draft-ietf-alto-protocol X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 22:17:19 -0000 --047d7b6d7a1090939104f2a1848b Content-Type: text/plain; charset=ISO-8859-1 Dan, Richard A. On Mon, Feb 17, 2014 at 4:10 PM, Richard Alimi wrote: > > > On Mon, Feb 17, 2014 at 6:26 AM, Dan Harkins wrote: > >> >> Hi Richard, >> >> On Sun, February 9, 2014 10:58 pm, Richard Alimi wrote: >> > Thank you very much for the review! >> > >> > Responses inline... >> > >> > >> > On Sat, Feb 1, 2014 at 10:54 AM, Dan Harkins >> wrote: >> > >> >> >> [snip] >> >> - 6.1.2, while a particular Cost Map may contain only one of the >> >> two cost modes, servers MUST implement support for both, >> >> right? It's not clear from the text. >> >> >> > >> > Servers only need to implement at least one, but not necessarily both. >> > Section 6.1.2 states the following: >> > >> > >> > An ALTO Server MUST support at least one of 'numerical' and 'ordinal' >> > modes. >> > >> > >> > Can you suggest which text was misleading so that we can address it? >> >> It's not clear to me how this interoperates unless it's possible to >> infer >> one from the other and if that's the case then why are there two things >> to choose to support? >> > > The key is that the client needs to handle both types, not the server. > During working group discussions, it was not clear that a server would > always wish to provide both and may opt to expose one or the other. > > For example, one cited reason for a server not exposing numerical costs > was concerns over revealing too many details of internal network topology. > > It is possible to derive ordinal costs from numerical costs. Thus, we > could require servers to provide ordinal costs and optionally provide > numerical costs. We opted to put this logic in the client-side, though, in > the interest of keeping the server simpler. > > Richard/Reinaldo: do you believe this is still a reasonable tradeoff and > am I missing any other rationale for this? I'm typically on the side of > keeping servers simpler, but we could reconsider if necessary. > I remember extensive discussions on the two modes. Given the dependency between the numerical and the ordinal modes (one can derive the ordinal from numerical but not the other way around), we can say that the ordinal mode is always provided, either implicitly (only numerical) or explicitly (when both are provided). This will allow interop. At the same time, the discussion was that we do not enforce the explicit approach to keep the Server simple, as Richard A. mentioned. Also, the less redundancy at the source (maintaining both numerical and ordinal), the less likely we encounter inconsistency. Richard --047d7b6d7a1090939104f2a1848b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Dan, Richard A.

On Mon, Feb 17, 2014 at 4:10 PM, Richard Alimi <ral= imi@google.com> wrote:

=
On Mon, Feb 17, 2014 at 6:26 AM, Dan Harkins <dharkins@l= ounge.org> wrote:

=A0 Hi Richard,

On Sun, February 9, 2014 10:58 pm, Richard Alimi wrote:
> Thank you very much for the review!
>
> Responses inline...
>
>
> On Sat, Feb 1, 2014 at 10:54 AM, Dan Harkins <dharkins@lounge.org> wrote:
>
>>
[snip]
>> =A0 - 6.1.2, while a particular Cost Map may contain only one= of the
>> =A0 =A0 =A0two cost modes, servers MUST implement support for both= ,
>> =A0 =A0 =A0right? It's not clear from the text.
>>
>
> Servers only need to implement at least one, but not necessarily both.=
> =A0Section 6.1.2 states the following:
>
>
> =A0 =A0An ALTO Server MUST support at least one of 'numerical'= and 'ordinal'
> =A0 =A0modes.
>
>
> Can you suggest which text was misleading so that we can address it?
=A0 It's not clear to me how this interoperates unless it's p= ossible to infer
one from the other and if that's the case then why are there two things=
to choose to support?

The key is = that the client needs to handle both types, not the server. =A0During worki= ng group discussions, it was not clear that a server would always wish to p= rovide both and may opt to expose one or the other.

For example, one cited reason for a server not exposing= numerical costs was concerns over revealing too many details of internal n= etwork topology.

It is possible to derive ordinal = costs from numerical costs. =A0Thus, we could require servers to provide or= dinal costs and optionally provide numerical costs. =A0We opted to put this= logic in the client-side, though, in the interest of keeping the server si= mpler.

Richard/Reinaldo: do you believe this is still a reason= able tradeoff and am I missing any other rationale for this? =A0I'm typ= ically on the side of keeping servers simpler, but we could reconsider if n= ecessary.

I remem= ber extensive discussions on the two modes. Given the dependency between th= e numerical and the ordinal modes (one can derive the ordinal from numerica= l but not the other way around), we can say that the ordinal mode is always= provided, either implicitly (only numerical) or explicitly (when both are = provided). This will allow interop.

At the same time, the discussion was that we do not enf= orce the explicit approach to keep the Server simple, as Richard A. mention= ed. Also, the less redundancy at the source (maintaining both numerical and= ordinal), the less likely we encounter inconsistency.

Richard
=A0
--047d7b6d7a1090939104f2a1848b-- From nobody Tue Feb 18 06:40:39 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CFA1A068F; Tue, 18 Feb 2014 06:40:34 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37tVAOyrhO5x; Tue, 18 Feb 2014 06:40:28 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 960711A068B; Tue, 18 Feb 2014 06:40:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1392734421; d=isode.com; s=selector; i=@isode.com; bh=RagVF8JHHpuR5qaxx9XxUv65U2y7Fzmr1wH0Un/8pKY=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=rz3QC+yMAw17cAj9UwNBBkBdMgIw+ePI2cjbXx0AGZzersOVzjTc8YkBfkzzPEtEGcHiTK vZ7HiaCcJjDE18OXAlaLew5IXmke8q6Wxr0C69I1m573hv1EJoV+akXM/LvWtkeY8X8gBT bc06ltDB+oZT/5nTtC9MOn9I19bhmSs=; Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 18 Feb 2014 14:40:21 +0000 Message-ID: <530370CC.1030702@isode.com> Date: Tue, 18 Feb 2014 14:40:12 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/UFv2_-EAlZ-DPKLnmakpxd4mViE Subject: [secdir] SECDIR review of draft-ietf-l2vpn-vpls-mib-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 14:40:34 -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 working group chairs should treat these comments just like any other last call comments. This document describes managed objects for configuring and/or monitoring Virtual Private LAN services, including LDP and BGP extensions. The document says that information in 3 defined MIB modules is not sensitive and thus not really worth protecting from passive monitoring. I doubt a bit this claim, as it seems that observing information from the MIB tables can help an attacker to mount other types of attacks on a particular VPLS. It also looks like gaining write access can enable Denial-of-Service attack on the monitoring system itself and/or on the underlying infrastructure. I also agree with Benoit Claise's DISCUSS that the document should follow the recommended MIB-security template: http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security Other than that, I have no security concerns in regards to this document. From nobody Tue Feb 18 09:08:19 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CFE1A04DE; Tue, 18 Feb 2014 09:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lguFPIb8iQW3; Tue, 18 Feb 2014 09:08:08 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF891A03F9; Tue, 18 Feb 2014 09:08:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3877; q=dns/txt; s=iport; t=1392743285; x=1393952885; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=VP+b1ucCdTBAHNFebpfyvJIOznoSJWl58hZ3Tv11eE4=; b=G5oryWSfK51vusaDGlCicneeFvF9uQDVgRQKqG5vU8CEoa9MBM1rW56S pORC4Px8UZnW22mY5vsWWmsedbhGj5Z8JahdXuB9KBDItcUGPun4O59PH vex+YLm1KpqVFiUhz4mMxxxglY7DVypg1uvKBjUbSXOEtZ6lV1iO3lQfv w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAMaSA1OQ/khR/2dsb2JhbABZgwaEEblEgwqBGxZ0giUBAQEEIxVAEQsYAgIFFgsCAgkDAgECAUUGAQwIAQGIAaoWoggXgSmNAF+Cb4FJAQOYLJIjgy2BaA X-IronPort-AV: E=Sophos;i="4.97,502,1389744000"; d="scan'208";a="5408427" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 18 Feb 2014 17:08:03 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1IH820Y016748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Feb 2014 17:08:02 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s1IH80U6022729; Tue, 18 Feb 2014 17:08:00 GMT Message-ID: <53039370.4070707@cisco.com> Date: Tue, 18 Feb 2014 17:08:00 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Scott G. Kelly" , "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-pwe3-iccp.all@tools.ietf.org References: <1392310413.011331048@apps.rackspace.com> In-Reply-To: <1392310413.011331048@apps.rackspace.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/HPyPiXEnPfLCSaziRs7q6QaPR9k Subject: Re: [secdir] secdir review of draft-ietf-pwe3-iccp-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 17:08:13 -0000 On 13/02/2014 16:53, Scott G. Kelly 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'm sorry that this review is a few days late. From the abstract: > > This document specifies an inter-chassis communication protocol > (ICCP) that enables Provider Edge (PE) device redundancy for Virtual > Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) > applications. The protocol runs within a set of two or more PEs, > forming a redundancy group, for the purpose of synchronizing data > amongst the systems. It accommodates multi-chassis attachment circuit > as well as pseudowire redundancy mechanisms. > > So, it's a redundancy protocol between provider edge devices. The document is long (81 pages), and not having been a participant in the wg, I encountered a lot of unfamiliar territory. > > The document presents 4 different interconnect scenarios for PEs (provider edge devices), as they are called. The security considerations section says that the security considerations in RFC5036 (LDP) and RFC4447 (Pseudowire Setup and Maintenance Using LDP) apply, and goes on to say that the ICCP protocol (which runs between the PEs) is intended to be restricted to a single administrative domain. > > The security considerations section goes on to talk about the need for policy configuration, and recommends that implementations provide control-plane policing to mitigate various attacks. > > I have to admit that I only have a limited understanding of this protocol, and this review should be taken accordingly. Zooming up to a 20000` level, I see that there is a group, and that this protocol allows a device to join and participate the group. > > The 4 different interconnect scenarios have different security properties/considerations. The first one (co-located dedicated interconnect) allows assumptions about physical security. The second and fourth have the PEs communicating via shared fabric ("Core Network"). The third has a dedicated interconnect which may allow assumptions about connection security. > > So, the questions I think of are these: > > - what are the potential consequences of an unauthorized join? > > - if any of these are a concern, then how do I prevent unauthorized joins? > > - assuming unauthorized joins are prevented, what are the potential consequences of interfering with traffic? > > - if any of these are a concern, then how do I detect/prevent these? > > In the case relying on physical security and/or a dedicated link (first/third), these can all be addressed by securing the physical link. In the other two cases, we either need protocol mechanisms, or we need assumptions/methods relating to the core network. > > Since the security considerations section points at RFCs 5036 and 4447, I went and looked at those. They talk about LDP and MPLS security, but the mechanisms they are using are ip address filtering and MD5 authentication. Under some assumptions for the core network, these may be fine, but under others (e.g. a potentially hostile core network), they are not. > > These are the things that occurred to me, as an outside observer who read the draft once. > > --Scott > > > . Scott Thank you for the review. MPLS signalling is only used in well managed and highly monitored networks so an attempt by an attacker to join would be noticed. However to attempt the join the attacker would first need to breach the physical and packet filtering security measures. This would not be deployed on or over the public Internet. Stewart From nobody Tue Feb 18 09:25:44 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728491A04FC; Tue, 18 Feb 2014 09:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0f6Dti9tvlg; Tue, 18 Feb 2014 09:25:22 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 427931A03F9; Tue, 18 Feb 2014 09:25:22 -0800 (PST) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s1IHPGK1010360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Feb 2014 12:25:17 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s1IHPGK1010360 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1392744317; bh=MqzXflPJH2En/aiebNDMqrsm0nU=; h=From:To:CC:Date:Subject:Message-ID:Content-Type:MIME-Version; b=rZqha7LXohpm6wkvC25PxgMOgMtmFoH5TqpbuqoTt5b923V3xNpOGYhvhCVpZPnFO jsPxsrp41FLCgdcdY6FbLszb1StWWFa58XrBHM1WqOLk+7tIdn93pV/K/XZvWC33jM uezxeLdVl/V+lAhQsTR2lz5SzUgKJjrR+fLYGJJ0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s1IHPGK1010360 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd51.lss.emc.com (RSA Interceptor); Tue, 18 Feb 2014 12:25:11 -0500 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s1IHPAoX002025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 12:25:10 -0500 Received: from mx15a.corp.emc.com ([169.254.1.167]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Tue, 18 Feb 2014 12:25:10 -0500 From: "Moriarty, Kathleen" To: "secdir@ietf.org" , "iesg@ietf.org" Date: Tue, 18 Feb 2014 12:25:07 -0500 Thread-Topic: SecDir Review of draft-ietf-tcpm-1323bis-19 Thread-Index: Ac8sy+PKVC0RZe0iRMS/K3E7IpheJg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24065BE94B74MX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/pAHohuZRpvt6qni_zMHsGeyZ-iY Cc: "rs@netapp.com" , "braden@isi.edu" , "david.borman@quantum.com" , "vanj@google.com" Subject: [secdir] SecDir Review of draft-ietf-tcpm-1323bis-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 17:25:32 -0000 --_000_F5063677821E3B4F81ACFB7905573F24065BE94B74MX15Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These 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. draft-ietf-tcpm-1323bis-19 is mostly ready. Discussion of the possible DoS= attacks that could occur from the technique described in section 5.3 shoul= d be included in this section and mentioned in the security considerations = section as well. Suppose again that segments: A.1, B.1, C.1, ..., Z.1 have been sent in sequence and that segment B.1 has been lost. Furthermore, suppose delivery of some of C.1, ... Z.1 is delayed until *after* the retransmission B.2 arrives at the receiver. These delayed segments will be discarded unnecessarily when they do arrive, since their timestamps are now out of date. Thank you, Kathleen --_000_F5063677821E3B4F81ACFB7905573F24065BE94B74MX15Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have review= ed this document as part of the security directorate's ongoing effort to re= view all IETF documents being processed by the IESG.  These comments w= ere written primarily for the benefit of the security area directors. = Document editors and WG chairs should treat these comments just like any o= ther last call comments.

 

 

draft-= ietf-tcpm-1323bis-19 is mostly ready.  Discussion of the possible DoS = attacks that could occur from the technique described in section 5.3 should= be included in this section and mentioned in the security considerations s= ection as well.

 

Suppose again that segments: A.1, B.1, C.1, ..., Z.1 have been
      sent in sequence and=
 that segment B.1 has been lost.  Furthermore,
= 
      suppose delivery of some of C.1, ...=
  Z.1 is delayed until *after*
 &n=
bsp;    the retransmission B.2 arrives at the receiver. =
; These delayed
    &nbs=
p; segments will be discarded unnecessarily when they do arrive,=

      since their timestamps=
 are now out of date.
 

 

Than= k you,

Kathleen

= --_000_F5063677821E3B4F81ACFB7905573F24065BE94B74MX15Acorpemcc_-- From nobody Tue Feb 18 11:39:06 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10181A052E; Tue, 18 Feb 2014 11:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwshxgWEFCxt; Tue, 18 Feb 2014 11:38:57 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id A94DE1A050C; Tue, 18 Feb 2014 11:38:52 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1IJckjW023611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Feb 2014 13:38:46 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s1IJcknx006303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Feb 2014 13:38:46 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s1IJcjPT007397; Tue, 18 Feb 2014 13:38:45 -0600 (CST) Message-ID: <5303B709.20407@bell-labs.com> Date: Tue, 18 Feb 2014 13:39:53 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Spencer Dawkins , "jsalowey@cisco.com" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/OgUmumw-uMsos_VF1BcLwTUVh4w Cc: "draft-ietf-soc-overload-control@tools.ietf.org" , "soc-chairs@tools.ietf.org" , IESG IESG , "secdir@ietf.org" Subject: [secdir] Collision on changes for draft-ietf-soc-overload-control-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 19:39:03 -0000 Spencer and Joe: I am attending to the secdir (Joe) and IESG (Spencer) comments to soc-overload-control-14. It appears that both of you hit on the same piece of text in the draft and requested modifications to it. The text in question is the following paragraph in Section 11 of -14 [1]: Attacks that indicate false overload control can be mitigated by using TCP or Websockets [RFC6455], or better yet, TLS in conjunction with applying BCP 38 [RFC2827]. Attacks that are mounted to suppress genuine overload conditions can be avoided by using TLS on the connection. The gist of your comments revolve around the role of TLS in the above paragraph. Both of you wanted the role highlighted, and in addition Joe thought that the role of BCP 38 should be encouraged in all cases, rather than just with the TLS case. I independently agreed to a modification of the above paragraph with both of you, and now I have to ensure that the independently agreed-to modifications are distilled into a single new paragraph that is acceptable to both of you. Here is the text Joe and I agreed on (Jan 17, 2014): Attacks that indicate false overload control can be mitigated by using TCP or Websockets [RFC6455], or better yet, TLS in conjunction with applying BCP 38 [RFC2827]. Attacks that are mounted to suppress genuine overload conditions can be avoided by using TLS on the connection. Generally, TCP and Websockets in conjunction with BCP-38 make it more difficult for an attacker to insert or modify messages, but it is still possible depending on where the attacker is positioned in the network. TLS provides better protection from an attacker that has access to the network link. And here is the text Spencer and I agreed on (Feb 11, 2014): Attacks that indicate false overload control are best mitigated by by using TLS in conjunction with applying BCP 38 [RFC2827]. Attacks that are mounted to suppress genuine overload conditions can be similarly avoided by using TLS on the connection. The use of TCP or Websockets [RFC6455] without TLS can provide some protection, but may be inadequate against an adversary that can modify traffic on links L1 and L2. As you can see, both the suggested texts above appear to be heading in the same direction. I propose the following merger of the suggested texts that I hope will be acceptable to both of you. Attacks that indicate false overload control are best mitigated by using TLS in conjunction with applying BCP 38 [RFC2827]. Attacks that are mounted to suppress genuine overload conditions can be similarly avoided by using TLS on the connection. Generally, TCP and Websockets in conjunction with BCP-38 make it difficult for an attacker to insert or modify messages, but may be inadequate against an adversary that can modify traffic on links L1 and L2. TLS provides the best protection from an attacker with access to the network links. Thank you for your time attending to this email. Please let me know of any changes to the above text. [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-14 Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Tue Feb 18 12:59:31 2014 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAED1A06D1; Tue, 18 Feb 2014 09:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1392746241; bh=fLf1duBa4zFy4dfRWjhxe78FdoeE8hYhNJLkfOtdXu8=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=K5ZP24ft6vAtd5Njm8c259EG48dGbcRMXJc8i1u7QsZzdt19eE00Dk1SsTFfiKd1i 71PMDJdB2qvR2Gfppl6Bd+j8XN+DW+LmfKPF4p4d3qynZ8QMvnS4Ek+VzyWyUvaddT evZMM1e514wG2y9ubGue1LoHyMF6Id/dg5bZQDBY= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B441A06D1 for ; Tue, 18 Feb 2014 09:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.45 X-Spam-Level: X-Spam-Status: No, score=-7.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hVjfsOSsV0j for ; Tue, 18 Feb 2014 09:57:13 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id A060C1A024B for ; Tue, 18 Feb 2014 09:57:13 -0800 (PST) Received: from eb.bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1WFous-00029W-9U for new-work@ietf.org; Tue, 18 Feb 2014 12:57:10 -0500 To: new-work@ietf.org Date: Tue, 18 Feb 2014 18:57:08 +0100 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/Bngmw8EpBUbOTGCUHppV2eOjDLk X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/dYBODolnLCOyWQNr0eigpeATEEI X-Mailman-Approved-At: Tue, 18 Feb 2014 12:59:29 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Timed Text Working Group (until 2014-03-20) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 17:57:21 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Video in the Web Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Timed Text Working Group: http://www.w3.org/2013/10/timed-text-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2014-03-20 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 Philippe Le Hegaret and Thierry Michel , Staff Contacts. Thank you, Coralie Mercier, W3C Communications [0] http://www.w3.org/2008/WebVideo/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Tue Feb 18 13:38:01 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0B61A04B1; Tue, 18 Feb 2014 13:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHhGOwvHS07T; Tue, 18 Feb 2014 13:37:55 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E6FDD1A026D; Tue, 18 Feb 2014 13:37:54 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D2FDE10224008; Tue, 18 Feb 2014 13:37:51 -0800 (PST) Received: from 209.29.74.150 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 18 Feb 2014 13:37:52 -0800 (PST) Message-ID: In-Reply-To: References: <23845_1391280851_s11IsAD0008772_cd3fb9f2748d08183af6652c0d58f61a.squirrel@www.trepanning.net> <1391369584.4360.72.camel@destiny.pc.cs.cmu.edu> <943e83dcb64a8666ea82900f013b2b9b.squirrel@www.trepanning.net> Date: Tue, 18 Feb 2014 13:37:52 -0800 (PST) From: "Dan Harkins" To: "Richard Alimi" 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 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/URZatTt2KQUUhWvHo1dmqVRu43o Cc: iesg@ietf.org, "draft-ietf-alto-protocol.all@tools.ietf.org" , secdir@ietf.org, Jeffrey Hutzelman Subject: Re: [secdir] secdir review of draft-ietf-alto-protocol X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:37:57 -0000 Hi Richard, On Mon, February 17, 2014 1:46 pm, Richard Alimi wrote: > On Mon, Feb 17, 2014 at 6:38 AM, Dan Harkins wrote: > >> >> Hi RIchard, >> >> On Sun, February 9, 2014 11:03 pm, Richard Alimi wrote: >> > On Sun, Feb 2, 2014 at 7:08 PM, Dan Harkins >> wrote: >> > >> >> >> >> On Sun, February 2, 2014 11:33 am, Jeffrey Hutzelman wrote: >> >> > On Sat, 2014-02-01 at 10:54 -0800, Dan Harkins wrote: >> >> > >> >> >> Also, given those >> >> >> restrictions and the fact that a tag just has to be less than >> >> >> or equal to 64 octets, the probability of identical tags >> being >> >> >> used is not zero. I think the probability of the tag from >> >> >> example 11.3.1.7 is 0.5 to collide with one of just 460 >> >> >> other Network Maps. >> >> >> >> >> >> I suggest requiring a tag to be 64 octets. That will make >> >> >> even money probability of collision among nearly 3000 >> >> >> other Network Maps, which is safer. >> >> > >> >> > OK, maybe I'm confused and reading out of context here. But I once >> >> had >> >> > someone tell me I needed to change my 5-character username because >> >> they >> >> > were requiring all usernames to be at least 6 characters, _in order >> to >> >> > increase the number of possible usernames_. That is, they claimed >> >> they >> >> > were increasing the size of a namespace by eliminating possible >> names. >> >> >> >> Well that's a hair brained policy, but username selection is not a >> >> good >> >> analogy. I was at a company that had no strict requirements on a >> >> username >> >> so there should have been a near infinite size of the namespace. But >> we >> >> had >> >> a collision when the company had less than 10 employees because there >> >> was another "dan" at the company. >> >> >> >> > The point is, if a tag is required to be exactly 64 octets, you get >> >> > 0x5e^64 possible tags. But if it is required to be up to 64 >> octets, >> >> you >> >> > get Sum(i=0..64) 0x5e^i possible tags, which is strictly greater >> than >> >> > 0x5e^64. So, requiring a tag to be 64 octets _reduces_ the number >> of >> >> > possible tags, thereby increasing the chance of collision. >> >> >> >> That would be the case if all tags in the Sum(i=1..64) 0x5e^i >> tagspace >> >> were equally probable of being chosen. Which implies implementations >> >> choosing a random tag length for each tag generated in addition to a >> >> random tag selection scheme for the randomly chosen length. I >> suspect, >> >> though, that in practice the tag length will be fixed for a >> particular >> >> implementation and the tag selection scheme will not necessarily be >> >> random. So the herd mentality, plus the proliferation of one or two >> >> companies' ALTO servers, will result in a severely reduced size of >> the >> >> effective tagspace and the increased possibility of collisions. >> >> >> >> A tag generated as SHA256(NetworkMap) represented in 64 hex >> >> characters would basically guarantee you'd never have a collision. >> >> Saying, "it can be anything you want as long as it's less than 64 >> >> octets" would not. >> >> >> > >> > Should I interpret your comment to say that we should to require >> > particular >> > mechanisms for generating version tags, or be more explicit about >> > suggesting mechanisms that have a low collision probability? >> >> Yes, I think you should. Suggestions on how to ensure a low >> probability of collision would be helpful. >> > > We've added the following text to section 10.3: > > It is RECOMMENDED that the tag have a low collision probability with other > tags. One suggested mechanism is to compute it using a hash of the data > content of the resource. That sounds great! >> >> > To help steer readers towards better implementation practices, we'll >> > change >> > the examples to use hashes in the version tags. >> >> That's a great idea. So people who implement ALTO and check >> the example will use hashes themselves and that will help ensure >> a low probability of collision. >> > > This change has been made to our copy in SVN. Fantastic. Thank you very much for your resolution to my comments. Dan. >> >> > Thank you again for the review! >> >> You're very welcome! >> >> regards, >> >> Dan. >> >> >> > From nobody Tue Feb 18 13:40:00 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749ED1A026A; Tue, 18 Feb 2014 13:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXUsZ_XbH9o4; Tue, 18 Feb 2014 13:39:52 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 709151A04D2; Tue, 18 Feb 2014 13:39:52 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6AA9E10224008; Tue, 18 Feb 2014 13:39:49 -0800 (PST) Received: from 209.29.74.150 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 18 Feb 2014 13:39:49 -0800 (PST) Message-ID: In-Reply-To: References: <2910582168899709b7211d3cea87c29d.squirrel@www.trepanning.net> Date: Tue, 18 Feb 2014 13:39:49 -0800 (PST) From: "Dan Harkins" To: "Y. Richard Yang" 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 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/G1LA61OwkM_rutmlgCypu_IqmHE Cc: secdir@ietf.org, Richard Alimi , "draft-ietf-alto-protocol.all@tools.ietf.org" , The IESG Subject: Re: [secdir] secdir review of draft-ietf-alto-protocol X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:39:55 -0000 Hi Richard (Y), On Mon, February 17, 2014 2:17 pm, Y. Richard Yang wrote: > Dan, Richard A. > > On Mon, Feb 17, 2014 at 4:10 PM, Richard Alimi wrote: >> >> >> On Mon, Feb 17, 2014 at 6:26 AM, Dan Harkins >> wrote: >> >>> >>> Hi Richard, >>> >>> On Sun, February 9, 2014 10:58 pm, Richard Alimi wrote: >>> > Thank you very much for the review! >>> > >>> > Responses inline... >>> > >>> > >>> > On Sat, Feb 1, 2014 at 10:54 AM, Dan Harkins >>> wrote: >>> > >>> >> >>> [snip] >>> >> - 6.1.2, while a particular Cost Map may contain only one of the >>> >> two cost modes, servers MUST implement support for both, >>> >> right? It's not clear from the text. >>> >> >>> > >>> > Servers only need to implement at least one, but not necessarily >>> both. >>> > Section 6.1.2 states the following: >>> > >>> > >>> > An ALTO Server MUST support at least one of 'numerical' and >>> 'ordinal' >>> > modes. >>> > >>> > >>> > Can you suggest which text was misleading so that we can address it? >>> >>> It's not clear to me how this interoperates unless it's possible to >>> infer >>> one from the other and if that's the case then why are there two things >>> to choose to support? >>> >> >> The key is that the client needs to handle both types, not the server. >> During working group discussions, it was not clear that a server would >> always wish to provide both and may opt to expose one or the other. >> >> For example, one cited reason for a server not exposing numerical costs >> was concerns over revealing too many details of internal network >> topology. >> >> It is possible to derive ordinal costs from numerical costs. Thus, we >> could require servers to provide ordinal costs and optionally provide >> numerical costs. We opted to put this logic in the client-side, though, >> in >> the interest of keeping the server simpler. >> >> Richard/Reinaldo: do you believe this is still a reasonable tradeoff and >> am I missing any other rationale for this? I'm typically on the side of >> keeping servers simpler, but we could reconsider if necessary. >> > > I remember extensive discussions on the two modes. Given the dependency > between the numerical and the ordinal modes (one can derive the ordinal > from numerical but not the other way around), we can say that the ordinal > mode is always provided, either implicitly (only numerical) or explicitly > (when both are provided). This will allow interop. That is a good suggestion. > At the same time, the discussion was that we do not enforce the explicit > approach to keep the Server simple, as Richard A. mentioned. Also, the > less > redundancy at the source (maintaining both numerical and ordinal), the > less > likely we encounter inconsistency. That makes sense, one side would have to do both. If you want to keep the server simple I guess that's the way to do it. thanks, Dan. > Richard > From nobody Tue Feb 18 16:20:00 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD851A00F6 for ; Tue, 18 Feb 2014 16:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVcRyWvb37CG for ; Tue, 18 Feb 2014 16:19:56 -0800 (PST) Received: from smtp122.iad3a.emailsrvr.com (smtp122.iad3a.emailsrvr.com [173.203.187.122]) by ietfa.amsl.com (Postfix) with ESMTP id E8C031A0166 for ; Tue, 18 Feb 2014 16:19:55 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id D5FD7248160; Tue, 18 Feb 2014 19:19:52 -0500 (EST) X-Virus-Scanned: OK Received: from app30.wa-webapps.iad3a (relay.iad3a.rsapps.net [172.27.255.110]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 052892480C8; Tue, 18 Feb 2014 19:19:51 -0500 (EST) Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app30.wa-webapps.iad3a (Postfix) with ESMTP id D61B980042; Tue, 18 Feb 2014 19:19:51 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Tue, 18 Feb 2014 16:19:51 -0800 (PST) Date: Tue, 18 Feb 2014 16:19:51 -0800 (PST) From: "Scott G. Kelly" To: stbryant@cisco.com MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: <53039370.4070707@cisco.com> References: <1392310413.011331048@apps.rackspace.com> <53039370.4070707@cisco.com> Message-ID: <1392769191.875311529@apps.rackspace.com> X-Mailer: webmail7.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/iJsW4xDAtRMPemeUo91vEdO-jM8 Cc: draft-ietf-pwe3-iccp.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-pwe3-iccp-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 00:19:57 -0000 Hi Stewart,=0A=0AOn Tuesday, February 18, 2014 9:08am, "Stewart Bryant" said:=0A=0A=0A> Scott=0A> =0A> Thank you for the= review.=0A> =0A> MPLS signalling is only used in well managed and highly m= onitored networks=0A> so an attempt by an attacker to join would be noticed= . However to=0A> attempt the=0A> join the attacker would first need to brea= ch the physical and packet=0A> filtering=0A> security measures.=0A> =0A> Th= is would not be deployed on or over the public Internet.=0A> =0A> Stewart= =0A=0AIf this is obvious to folks working in this domain, you may not need = to say this in the document, but if you want it to be obvious to everyone, = a statement to this effect in the security considerations might be helpful.= =0A=0AThanks,=0A=0AScott=0A From nobody Wed Feb 19 04:30:51 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA4F1A0487 for ; Wed, 19 Feb 2014 04:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSiUyZ1aDDlt for ; Wed, 19 Feb 2014 04:30:45 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 5619D1A047F for ; Wed, 19 Feb 2014 04:30:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1392813038; d=isode.com; s=selector; i=@isode.com; bh=cdANPkWz7LXUDVN2XuSVuKXm0iRvKt2gLaCGUioaqGY=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=WKesWANJRub9q6xQQJcKEEduiWjpq+YRJEUOn2kyjUcfqwco9kVSmjCc2UUqeSVo7Z5ENE 79jPRJFl/D+GowAwR19tkFbEvEL+BLDbQarbAv3o9cGCzDwGBHM6qae/bof4Uzhknlt0yT VGS5oBmUoT30enm9gXoZA0vQi5FOq1Q=; Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 19 Feb 2014 12:30:38 +0000 Message-ID: <5304A3F2.5070107@isode.com> Date: Wed, 19 Feb 2014 12:30:42 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 To: Phillip Hallam-Baker , Jeffrey Hutzelman References: <1392341826.4569.14.camel@destiny.pc.cs.cmu.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010308000809040203090408" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/LEmfbhSaUp4KryglBQ02rbdGyz0 Cc: "secdir@ietf.org" Subject: Re: [secdir] SECDIR Review of draft-ietf-qresync-rfc5162bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 12:30:48 -0000 This is a multi-part message in MIME format. --------------010308000809040203090408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Phillip, On 14/02/2014 02:20, Phillip Hallam-Baker wrote: > On Thu, Feb 13, 2014 at 8:37 PM, Jeffrey Hutzelman > wrote: > > On Thu, 2014-02-13 at 19:31 -0500, Phillip Hallam-Baker wrote: > > > > We have a problem here, the security considerations in the draft are > > a back reference to the original protocol. This is the security > references > > section of IMAP, a core Internet protocol in their entirety: > > > > 11 . Security > Considerations > > > > IMAP4rev1 protocol transactions, including electronic mail > data, are > > sent in the clear over the network unless protection from > snooping is > > negotiated. This can be accomplished either by the use of > STARTTLS, > > negotiated privacy protection in the AUTHENTICATE command, or > some > > other protection mechanism. > > Nope. That's the entirety of the _introduction_ to the security > considerations section in RFC33501. It is followed by two subsections > which give a fairly detailed treatment of issues related to > authentication, connection security, and handling of passwords. > > That's not to say the security considerations in the IMAP spec are > complete and perfect; they're certainly not. For example, there is no > discussion of authorization and access control. However, > incomplete is > not the same as nonexistent, and there is no need here to be alarmist. > > > Weird and I was looking for it.. > > There is a problem in that it does not state what the attack model is. > It seems as if the attack model is limited to a passive attack. > > If there is an active MITM attack, SSL will only provide protection if > the server certificate is authenticated. Otherwise, passing the > username and password enclair is problematic. Thank you for your review. As this extension doesn't change authentication model or how TLS services are used, I don't think this is the right document to talk about passive monitoring, passwords or TLS server certificate verification. So I believe the Security Considerations as stated is correct. Best Regards, Alexey --------------010308000809040203090408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Phillip,

On 14/02/2014 02:20, Phillip Hallam-Baker wrote:
On Thu, Feb 13, 2014 at 8:37 PM, Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
On Thu, 2014-02-13 at 19:31 -0500, Phillip Hallam-Baker wrote:


> We have a problem here, the security considerations in the draft are
> a back reference to the original protocol. This is the security references
> section of IMAP, a core Internet protocol in their entirety:
>
> 11 <http://tools.ietf.org/html/rfc3501#section-11>.     Security Considerations
>
>    IMAP4rev1 protocol transactions, including electronic mail data, are
>    sent in the clear over the network unless protection from snooping is
>    negotiated.  This can be accomplished either by the use of STARTTLS,
>    negotiated privacy protection in the AUTHENTICATE command, or some
>    other protection mechanism.

Nope.  That's the entirety of the _introduction_ to the security
considerations section in RFC33501.  It is followed by two subsections
which give a fairly detailed treatment of issues related to
authentication, connection security, and handling of passwords.

That's not to say the security considerations in the IMAP spec are
complete and perfect; they're certainly not.  For example, there is no
discussion of authorization and access control.  However, incomplete is
not the same as nonexistent, and there is no need here to be alarmist.

Weird and I was looking for it..

There is a problem in that it does not state what the attack model is. It seems as if the attack model is limited to a passive attack.

If there is an active MITM attack, SSL will only provide protection if the server certificate is authenticated. Otherwise, passing the username and password enclair is problematic.
Thank you for your review.

As this extension doesn't change authentication model or how TLS services are used, I don't think this is the right document to talk about passive monitoring, passwords or TLS server certificate verification. So I believe the Security Considerations as stated is correct.

Best Regards,
Alexey

--------------010308000809040203090408-- From nobody Wed Feb 19 07:50:05 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8C91A040F; Wed, 19 Feb 2014 07:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFb4yDpd4SA7; Wed, 19 Feb 2014 07:49:52 -0800 (PST) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id D4E9D1A032A; Wed, 19 Feb 2014 07:49:51 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id t10so322976eei.7 for ; Wed, 19 Feb 2014 07:49:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=DQegKVzEXDuHj3SXDd/z9Yh2r/o1snbJTEgSrtRxS88=; b=Tty3X94HF2HQDbNuLTgMHwf2QLl82nTzGaqx9gH+l4EujzkGvZ21d56yp4UapNMCs5 JmfEnlDFCGkyLsBsfSf84jxdc4Om8BLPz0vcnVIm8zAmlSa+BxZ4h0nyfr/66ANFoVwY Fz66nbHJTDq73FuPrcxJmqXOqCEZHTh21Pay/sPIyJ8k5kuCvuSnDTFeIlN0+W9p6iTB CJFxm43SWrdr+Vfv1h99LpGHoXeH9IxT8OQQ8WfBSbMGVe5g8kfBcrrNffUcXzgLCRxN YSy0xTfLB/81ARPgZzex7ZTMhatC8Kj35MoEwWF7u8ROqhrz4TiJuxVQnFbe3+pWoY2m th0w== X-Received: by 10.15.75.193 with SMTP id l41mr1781787eey.114.1392824987751; Wed, 19 Feb 2014 07:49:47 -0800 (PST) Received: from [10.2.0.16] (89-139-136-195.bb.netvision.net.il. [89.139.136.195]) by mx.google.com with ESMTPSA id m9sm2141715eeh.3.2014.02.19.07.49.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 07:49:46 -0800 (PST) Message-ID: <5304D298.7050101@gmail.com> Date: Wed, 19 Feb 2014 17:49:44 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: secdir@ietf.org, draft-ietf-v6ops-64share.all@tools.ietf.org, iesg@ietf.org References: <4FBFAE5F.8010305@gmail.com> In-Reply-To: <4FBFAE5F.8010305@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/qMyzETpAItcL7OiSvCEx9sXOYc4 Subject: [secdir] SecDir review of draft-ietf-v6ops-64share-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 15:49: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 comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes two options of providing hosts behind a 3GPP UE (e.g., cellular router) with an IPv6 network prefix, in networks that do not support IPv6 prefix delegation. The document is explicitly non-normative. Summary The document is ready to progress. Details - I don't understand why the first scenario (sec. 4.2) is even useful, i.e. why allocate the /64 to the LAN (and not just settle for a link-local prefix) when the UE does not have an address on the 3GPP link, and so cannot route traffic to the Internet? - Despite the non-normative status of the document, I think the security considerations deserve stronger wording. I suggest to replace "shall be considered" by "SHOULD be applied". - I would suggest that the security considerations also mention the privacy implications of having a (typically) small number of devices, all within a single unchanging network prefix. I *believe* this is behind the discussion of RFC 4941 is Sec. 4.3, but I would rather have the threat spelled out. Thanks, Yaron From nobody Wed Feb 19 08:18:28 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E57C1A0249; Wed, 19 Feb 2014 08:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKoBQPyeSZXd; Wed, 19 Feb 2014 08:18:23 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id EBF7B1A021B; Wed, 19 Feb 2014 08:18:22 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1JGIFKP013062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Feb 2014 10:18:15 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s1JGIEhB007046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Feb 2014 10:18:14 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s1JGIDfK019210; Wed, 19 Feb 2014 10:18:13 -0600 (CST) Message-ID: <5304D989.80902@bell-labs.com> Date: Wed, 19 Feb 2014 10:19:21 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Spencer Dawkins , "jsalowey@cisco.com" References: <5303B709.20407@bell-labs.com> <5303D6BF.6070901@gmail.com> In-Reply-To: <5303D6BF.6070901@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/LE7I3XRC0GxzyqyEJOtH358gb4U Cc: "draft-ietf-soc-overload-control@tools.ietf.org" , "soc-chairs@tools.ietf.org" , IESG IESG , "secdir@ietf.org" Subject: Re: [secdir] Collision on changes for draft-ietf-soc-overload-control-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 16:18:25 -0000 On 02/18/2014 03:55 PM, Spencer Dawkins wrote: [...] > This is working for me, but the version you and Joe crafted had "make it > *more* difficult". > > I'm hoping not to say anything like "TCP is a great security strategy"; > "more difficult" is more like "TCP is a better security strategy than > UDP, but ...". > > Could you help me understand where that word went? Spencer: I had excised that word in a pique of editorial discretion since I thought it was not qualifying anything substantive. Clearly, you thought otherwise, and that is perfectly fine. I will reintroduce it as follows (plus some minor edits to improve readability): Attacks that indicate false overload control are best mitigated by using TLS in conjunction with applying BCP 38 [RFC2827]. Attacks that are mounted to suppress genuine overload conditions can be similarly avoided by using TLS on the connection. Generally, TCP or Websockets [RFC6455] in conjunction with BCP 38 makes it more difficult for an attacker to insert or modify messages, but may still prove inadequate against an adversary that controls links L1 and L2. TLS provides the best protection from an attacker with access to the network links. Thanks! - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Wed Feb 19 09:26:39 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDF21A028F; Tue, 18 Feb 2014 13:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsLexC1El-Wz; Tue, 18 Feb 2014 13:55:16 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id B272F1A026A; Tue, 18 Feb 2014 13:55:16 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id va2so19208305obc.40 for ; Tue, 18 Feb 2014 13:55:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6V5GYAuBCfei2ZRKiQ/pJMxbVsdIrTLjlE4cgJ+pKAQ=; b=0JjaWFiIoQwYQpEet5m1+I6X83K14I4mEsbgb4KfHMrv06vG8h7Vvwm0Hulz2ctvm9 SUzehVVLv2RR0xmdoI4VuvVTtMXEfzjLeCKSmrxY4rcIwioKN53LZS87d70jy79wdk5+ D4sfm2PP3X0ZTHwXCMq0P6bSkL47QrjhyegTfJ2OEsRHddXDdJLaRCcKIPr9H2vzFTOU uW1tzAOkEB1NQfHhFOtBN4lKZ+zh1ozCn83bTZ++0wYdqqvd+31+TKJgvW/R6AnrNSXR fw77W4dhARZ7M4t/YrwLQBR3NO1UZ0ykpHcLZrZripmLQsoUQKQ6/UCrJAFo0RTP7F4j mtFA== X-Received: by 10.60.69.138 with SMTP id e10mr2462848oeu.75.1392760513642; Tue, 18 Feb 2014 13:55:13 -0800 (PST) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id m7sm62639431obo.7.2014.02.18.13.55.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Feb 2014 13:55:13 -0800 (PST) Message-ID: <5303D6BF.6070901@gmail.com> Date: Tue, 18 Feb 2014 15:55:11 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Vijay K. Gurbani" , "jsalowey@cisco.com" References: <5303B709.20407@bell-labs.com> In-Reply-To: <5303B709.20407@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/2M2r2YbOjSjjl5mPw5hzuLsU97Q X-Mailman-Approved-At: Wed, 19 Feb 2014 09:26:35 -0800 Cc: "draft-ietf-soc-overload-control@tools.ietf.org" , "soc-chairs@tools.ietf.org" , IESG IESG , "secdir@ietf.org" Subject: Re: [secdir] Collision on changes for draft-ietf-soc-overload-control-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:55:19 -0000 Hi, Vijay, Thank you for asking. Pls. see below. On 02/18/2014 01:39 PM, Vijay K. Gurbani wrote: > Spencer and Joe: I am attending to the secdir (Joe) and IESG (Spencer) > comments to soc-overload-control-14. > > It appears that both of you hit on the same piece of text in the draft > and requested modifications to it. The text in question is the > following paragraph in Section 11 of -14 [1]: > > Attacks that indicate false overload control can be mitigated by > using TCP or Websockets [RFC6455], or better yet, TLS in conjunction > with applying BCP 38 [RFC2827]. Attacks that are mounted to suppress > genuine overload conditions can be avoided by using TLS on the > connection. > > The gist of your comments revolve around the role of TLS in the above > paragraph. Both of you wanted the role highlighted, and in addition > Joe thought that the role of BCP 38 should be encouraged in all cases, > rather than just with the TLS case. > > I independently agreed to a modification of the above paragraph with > both of you, and now I have to ensure that the independently agreed-to > modifications are distilled into a single new paragraph that is > acceptable to both of you. > > Here is the text Joe and I agreed on (Jan 17, 2014): > > Attacks that indicate false overload control can be mitigated by > using TCP or Websockets [RFC6455], or better yet, TLS in conjunction > with applying BCP 38 [RFC2827]. Attacks that are mounted to suppress > genuine overload conditions can be avoided by using TLS on the > connection. Generally, TCP and Websockets in conjunction with > BCP-38 make it more difficult for an attacker to insert or modify > messages, but it is still possible depending on where the attacker > is positioned in the network. TLS provides better protection from > an attacker that has access to the network link. > > And here is the text Spencer and I agreed on (Feb 11, 2014): > > Attacks that indicate false overload control are best mitigated by > by using TLS in conjunction with applying BCP 38 [RFC2827]. Attacks > that are mounted to suppress genuine overload conditions can be > similarly avoided by using TLS on the connection. The use of TCP or > Websockets [RFC6455] without TLS can provide some protection, but > may be inadequate against an adversary that can modify traffic on > links L1 and L2. > > As you can see, both the suggested texts above appear to be heading in > the same direction. I propose the following merger of the suggested > texts that I hope will be acceptable to both of you. > > Attacks that indicate false overload control are best mitigated by > using TLS in conjunction with applying BCP 38 [RFC2827]. Attacks > that are mounted to suppress genuine overload conditions can be > similarly avoided by using TLS on the connection. Generally, TCP > and Websockets in conjunction with BCP-38 make it difficult for an This is working for me, but the version you and Joe crafted had "make it *more* difficult". I'm hoping not to say anything like "TCP is a great security strategy"; "more difficult" is more like "TCP is a better security strategy than UDP, but ...". Could you help me understand where that word went? Spencer > attacker to insert or modify messages, but may be inadequate > against an adversary that can modify traffic on links L1 and L2. > TLS provides the best protection from an attacker with access to > the network links. > > Thank you for your time attending to this email. Please let me know of > any changes to the above text. > > [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-14 > > Cheers, > > - vijay From nobody Wed Feb 19 09:26:41 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563C61A01DE; Wed, 19 Feb 2014 07:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTAMAU10a4j1; Wed, 19 Feb 2014 07:59:09 -0800 (PST) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id 313E61A0203; Wed, 19 Feb 2014 07:59:06 -0800 (PST) From: =?utf-8?B?VsOtemRhbCBBbGXFoQ==?= To: Yaron Sheffer Date: Wed, 19 Feb 2014 16:59:00 +0100 Thread-Topic: SecDir review of draft-ietf-v6ops-64share-09 Thread-Index: Ac8tij/XPzJsJTlMR62q6PmDAXIG9QAAEOwg Message-ID: <1808340F7EC362469DDFFB112B37E2FCDA3256BC44@SRVHKE02.rdm.cz> References: <4FBFAE5F.8010305@gmail.com> <5304D298.7050101@gmail.com> In-Reply-To: <5304D298.7050101@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-loop: 2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forwarded Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/B1LS-mYXbSDaLcxp5R8eAUqRPxs X-Mailman-Approved-At: Wed, 19 Feb 2014 09:26:35 -0800 Cc: "draft-ietf-v6ops-64share.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-v6ops-64share-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 15:59:12 -0000 RGVhciBZYXJvbiwNCg0KTWFueSB0aGFua3MgZm9yIHlvdXIgcmV2aWV3Lg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFlhcm9uIFNoZWZmZXIgW21haWx0bzp5YXJvbmYu aWV0ZkBnbWFpbC5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTksIDIwMTQgNDo1 MCBQTQ0KPiBUbzogc2VjZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLXY2b3BzLQ0KPiA2NHNoYXJl LmFsbEB0b29scy5pZXRmLm9yZzsgaWVzZ0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBTZWNEaXIgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtdjZvcHMtNjRzaGFyZS0wOQ0KPiANCj4gSSBoYXZlIHJldmlld2Vk IHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkNCj4gZGlyZWN0b3JhdGUncyBv bmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzDQo+IGJlaW5nIHByb2Nl c3NlZCBieSB0aGUgSUVTRy4NCj4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmls eSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlDQo+IHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiAgRG9j dW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzDQo+IHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50 cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbA0KPiBjb21tZW50cy4NCj4gDQo+IFRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIHR3byBvcHRpb25zIG9mIHByb3ZpZGluZyBob3N0cyBiZWhpbmQN Cj4gYSAzR1BQIFVFIChlLmcuLCBjZWxsdWxhciByb3V0ZXIpIHdpdGggYW4gSVB2NiBuZXR3b3Jr DQo+IHByZWZpeCwgaW4gbmV0d29ya3MgdGhhdCBkbyBub3Qgc3VwcG9ydCBJUHY2IHByZWZpeA0K PiBkZWxlZ2F0aW9uLiBUaGUgZG9jdW1lbnQgaXMgZXhwbGljaXRseSBub24tbm9ybWF0aXZlLg0K PiANCj4gU3VtbWFyeQ0KPiANCj4gVGhlIGRvY3VtZW50IGlzIHJlYWR5IHRvIHByb2dyZXNzLg0K PiANCj4gRGV0YWlscw0KPiANCj4gLSBJIGRvbid0IHVuZGVyc3RhbmQgd2h5IHRoZSBmaXJzdCBz Y2VuYXJpbyAoc2VjLiA0LjIpIGlzDQo+IGV2ZW4gdXNlZnVsLCBpLmUuIHdoeSBhbGxvY2F0ZSB0 aGUgLzY0IHRvIHRoZSBMQU4gKGFuZCBub3QNCj4ganVzdCBzZXR0bGUgZm9yIGEgbGluay1sb2Nh bCBwcmVmaXgpIHdoZW4gdGhlIFVFIGRvZXMgbm90DQo+IGhhdmUgYW4gYWRkcmVzcyBvbiB0aGUg M0dQUCBsaW5rLCBhbmQgc28gY2Fubm90IHJvdXRlIHRyYWZmaWMNCj4gdG8gdGhlIEludGVybmV0 Pw0KDQpUaGlzIHNjZW5hcmlvIGlzIGRpc2N1c3NpbmcgYSBjYXNlIHdoZXJlIHRoZSAzR1BQIGlu dGVyZmFjZSBhc3NpZ25lZA0KR1VBIHByZWZpeCB3aWxsIGJlIG1vdmVkIHRvIHRoZSBMQU4gbGlu aywgdGhlIDNHUFAgbGluayB3aWxsIHN0aWxsDQpiZSBMTEEgbnVtYmVyZWQuDQoNCj4gLSBEZXNw aXRlIHRoZSBub24tbm9ybWF0aXZlIHN0YXR1cyBvZiB0aGUgZG9jdW1lbnQsIEkgdGhpbmsNCj4g dGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGRlc2VydmUgc3Ryb25nZXIgd29yZGluZy4gSQ0K PiBzdWdnZXN0IHRvIHJlcGxhY2UgInNoYWxsIGJlIGNvbnNpZGVyZWQiIGJ5ICJTSE9VTEQgYmUN Cj4gYXBwbGllZCIuDQoNCk9LLCB3ZSB3aWxsIGNvbnNpZGVyIGl0Lg0KDQo+IC0gSSB3b3VsZCBz dWdnZXN0IHRoYXQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFsc28NCj4gbWVudGlvbiB0 aGUgcHJpdmFjeSBpbXBsaWNhdGlvbnMgb2YgaGF2aW5nIGEgKHR5cGljYWxseSkNCj4gc21hbGwg bnVtYmVyIG9mIGRldmljZXMsIGFsbCB3aXRoaW4gYSBzaW5nbGUgdW5jaGFuZ2luZw0KPiBuZXR3 b3JrIHByZWZpeC4gSSAqYmVsaWV2ZSogdGhpcyBpcyBiZWhpbmQgdGhlIGRpc2N1c3Npb24gb2YN Cj4gUkZDIDQ5NDEgaXMgU2VjLiA0LjMsIGJ1dCBJIHdvdWxkIHJhdGhlciBoYXZlIHRoZSB0aHJl YXQNCj4gc3BlbGxlZCBvdXQuDQoNCk9LLCB0aGUgbGlmZXRpbWUgb2YgYSBwcmVmaXggaXMgYm91 bmQgdG8gdGhlIGxpZmV0aW1lIG9mIHRoZSBuZXR3b3JrDQphdHRhY2ggKGNvbnRleHQpLCBvbmNl IHRoZSBkZXZpY2UgKFVFKSByZS1hdHRhY2hlcyBhIG5ldyBwcmVmaXggd2lsbCANCmJlIGFzc2ln bmVkIGJ5IHRoZSBuZXR3b3JrLiBUaGlzIHNvbHV0aW9uIHNoYWxsIGJlIHVuZGVyc3Rvb2QgYXMN CmFuIGludGVyaW0gb25lIGJyaWRnaW5nIHRoZSBnYXAgdGlsbCBESENQLVBEIHdpbGwgYmUgd2lk ZWx5IGF2YWlsYWJsZS4NCiANCj4gVGhhbmtzLA0KPiAgICAgICBZYXJvbg0KDQpDaGVlcnMsDQpB bGVzDQo= From nobody Wed Feb 19 09:26:43 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F94A1A021B; Wed, 19 Feb 2014 08:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHyFQ5NqrcxM; Wed, 19 Feb 2014 08:23:58 -0800 (PST) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id D1A9F1A01F0; Wed, 19 Feb 2014 08:23:57 -0800 (PST) Received: by mail-oa0-f54.google.com with SMTP id g12so263269oah.13 for ; Wed, 19 Feb 2014 08:23:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pAki5qusyKJppQbmecsHuvXDbwQ3bPDTDR2JHEj5Hsw=; b=I0+OYdZ61gBLYFO0UvVir7pAfU0hxwLV3biy/3dww42A9fSkVwDMBksg4jds0gYBTA xgqMf+eldWVObrkNamro81NiMUAEALAxbnxMen2o6HmFjvssGLI8ZlR6UK4BvpNylTgH /NUKDW3Gh1Q4OaE2vXjVZZjnWSu6dsdPL+OtcaqZtPpgzg/n8fv+I0unYFr1Ysvar8OI YJi/76fl2SUWUECOMuxTzrsAhOlkQgUVYnyUqs+vkHD1ixtCBUNp50VU/3qwVFiTS26W viEXd8/Qfs9wuhZg+pGKxI16LlGGs0LWagfc3OB0Q53q+k73qpPoe/JRLbjF8rWqgZe8 8lbw== X-Received: by 10.60.102.243 with SMTP id fr19mr21411078oeb.13.1392827034505; Wed, 19 Feb 2014 08:23:54 -0800 (PST) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id z5sm1880067obg.13.2014.02.19.08.23.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 08:23:53 -0800 (PST) Message-ID: <5304DA97.3000900@gmail.com> Date: Wed, 19 Feb 2014 10:23:51 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Vijay K. Gurbani" , "jsalowey@cisco.com" References: <5303B709.20407@bell-labs.com> <5303D6BF.6070901@gmail.com> <5304D989.80902@bell-labs.com> In-Reply-To: <5304D989.80902@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/jIW5qZ9uFzl_6red1G4VtfSiPdo X-Mailman-Approved-At: Wed, 19 Feb 2014 09:26:35 -0800 Cc: "draft-ietf-soc-overload-control@tools.ietf.org" , "soc-chairs@tools.ietf.org" , IESG IESG , "secdir@ietf.org" Subject: Re: [secdir] Collision on changes for draft-ietf-soc-overload-control-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 16:23:59 -0000 On 02/19/2014 10:19 AM, Vijay K. Gurbani wrote: > On 02/18/2014 03:55 PM, Spencer Dawkins wrote: > [...] >> This is working for me, but the version you and Joe crafted had "make it >> *more* difficult". >> >> I'm hoping not to say anything like "TCP is a great security strategy"; >> "more difficult" is more like "TCP is a better security strategy than >> UDP, but ...". >> >> Could you help me understand where that word went? > > Spencer: I had excised that word in a pique of editorial discretion > since I thought it was not qualifying anything substantive. Clearly, > you thought otherwise, and that is perfectly fine. I will reintroduce > it as follows (plus some minor edits to improve readability): > > Attacks that indicate false overload control are best mitigated by > using TLS in conjunction with applying BCP 38 [RFC2827]. Attacks > that are mounted to suppress genuine overload conditions can be > similarly avoided by using TLS on the connection. Generally, TCP or > Websockets [RFC6455] in conjunction with BCP 38 makes it more > difficult for an attacker to insert or modify messages, but may still > prove inadequate against an adversary that controls links L1 and > L2. TLS provides the best protection from an attacker with access > to the network links. > > Thanks! > > - vijay Works for me! Spencer From nobody Wed Feb 19 17:46:16 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3778E1A0168; Wed, 19 Feb 2014 17:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnK4Bc7PoxAm; Wed, 19 Feb 2014 17:46:09 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9D61A0103; Wed, 19 Feb 2014 17:46:09 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id y1so861244lam.41 for ; Wed, 19 Feb 2014 17:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DXHs8Ok1BHyXbVr/icSeO2QXOJfwmm7uOIWMU7NQ/YQ=; b=Wsdk6m60WqaLvMS0PKnAwbp3CBoTTqSI4tJx//bwGhmBsSNtFyNNMbvOWt3UJ/qSHk A0tMJp4AGmf1NBQj1IE0sbBSkAIbochg188yYe8QMCfPl1rJrVvN1e++2aDzSmsuv6T6 E2ea+LQ3OSL45yu+NEkL4Jkv3dJ0guongFATnyHocx6U0vLZvmpYVgZxKh/nAADvbD81 pIwwT7iwNgriRw/+xwXl/iqrEFYkJrT0veMdhgB3MbZEBfTvKwyNzt+7X48+T6UaB09e OXmYBOBvQM8XcLNiDNI2I8edEmXzMICP/MKTztka1cN9lAIj4Zp/nguJ7Z4wQ7hRI1dg e89w== MIME-Version: 1.0 X-Received: by 10.152.20.134 with SMTP id n6mr2154091lae.83.1392860765171; Wed, 19 Feb 2014 17:46:05 -0800 (PST) Received: by 10.112.37.168 with HTTP; Wed, 19 Feb 2014 17:46:05 -0800 (PST) Date: Wed, 19 Feb 2014 20:46:05 -0500 Message-ID: From: Phillip Hallam-Baker To: "secdir@ietf.org" , "draft-ietf-pcp-description-option@tools.ietf.org" , "iesg@ietf.org" Content-Type: multipart/alternative; boundary=089e01493dbe21363f04f2ccab4b Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/rnTkCt3AdIoXUoe4IZFdlDdj2PY Subject: [secdir] SECDIR review of draft-ietf-pcp-description-option-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 01:46:12 -0000 --089e01493dbe21363f04f2ccab4b Content-Type: text/plain; charset=ISO-8859-1 This draft simply adds in a description field to the Port Control Protocol. While this does not raise security concerns in itself, uses of the field may. In particular, the (ab)use of the DNS TXT field to stuff site local or non-standard control data into the protocol might become a problem I suspect it won't be long before someone has the idea that their application announce itself with a description of "# SELECT * FROM Bobby.tables". The SC should point out that the data is not authenticated for this purpose and relying on (or executing) descriptions is a trail of tears. -- Website: http://hallambaker.com/ --089e01493dbe21363f04f2ccab4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This draft simply adds in a description field to the Port = Control Protocol.

While this does not raise security con= cerns in itself, uses of the field may. In particular, the (ab)use of the D= NS TXT field to stuff site local or non-standard control data into the prot= ocol might become a problem=A0

I suspect it won't be long before someone has the i= dea that their application announce itself with a description of "# SE= LECT * FROM Bobby.tables".=A0

The SC should p= oint out that the data is not authenticated for this purpose and relying on= (or executing) descriptions is a trail of tears.

--
Website: http://h= allambaker.com/
--089e01493dbe21363f04f2ccab4b-- From nobody Wed Feb 19 22:35:16 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426D61A040E for ; Wed, 19 Feb 2014 22:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvVYvmUAhR_O for ; Wed, 19 Feb 2014 22:35:13 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id EFD501A0352 for ; Wed, 19 Feb 2014 22:35:12 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s1K6Z8WK020887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 20 Feb 2014 08:35:08 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s1K6Z8JN029306; Thu, 20 Feb 2014 08:35:08 +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: <21253.41500.428028.583691@fireball.kivinen.iki.fi> Date: Thu, 20 Feb 2014 08:35:08 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 1 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/uy2u8UpiSFvLuukC-Bq3mcNAm38 Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 06:35:15 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Derek Atkins is next in the rotation. For telechat 2014-02-20 Reviewer LC end Draft Dorothy Gellert T 2014-02-11 draft-housley-pkix-test-oids-00 Steve Hanna TR2014-02-04 draft-ietf-pcp-nat64-prefix64-05 Steve Hanna T 2014-01-28 draft-ietf-v6ops-nat64-experience-09 Jeffrey Hutzelman T 2014-02-04 draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01 Warren Kumari T 2014-02-12 draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03 Kathleen Moriarty TR2013-12-16 draft-ietf-opsec-vpn-leakages-03 Joe Salowey T 2014-02-20 draft-ietf-stir-problem-statement-03 For telechat 2014-03-20 Julien Laganier T 2014-02-28 draft-fairhurst-ipdvb-ule-iana-05 Chris Lonvick T 2014-02-18 draft-ietf-dhc-dhcpv6-unknown-msg-05 Klaas Wierenga T 2014-03-12 draft-ietf-jcardcal-jcal-09 Last calls and special requests: Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-11 Catherine Meadows 2014-02-17 draft-ietf-dmm-requirements-14 Adam Montville 2014-02-19 draft-ietf-storm-rdmap-ext-08 Russ Mundy 2014-03-24 draft-mahalingam-dutt-dcops-vxlan-08 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Sandy Murphy 2014-03-05 draft-melnikov-smime-msa-to-mda-03 Yoav Nir 2014-02-24 draft-ietf-eman-framework-15 Magnus Nystrom 2014-02-24 draft-ietf-mpls-ldp-applicability-label-adv-02 Hilarie Orman 2014-02-24 draft-ietf-mpls-tp-psc-itu-02 Radia Perlman 2014-02-24 draft-ietf-multimob-pmipv6-source-07 Vincent Roca 2014-02-25 draft-ietf-sidr-policy-qualifiers-01 Zach Shelby 2013-08-30 draft-kaplan-insipid-session-id-03 Ondrej Sury 2014-02-27 draft-ietf-ippm-testplan-rfc2680-04 Carl Wallace 2014-03-14 draft-drage-sipping-rfc3455bis-13 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-10 Brian Weis 2014-02-28 draft-ietf-ecrit-trustworthy-location-08 Tom Yu 2014-03-03 draft-ietf-mpls-special-purpose-labels-05 Dacheng Zhang 2014-03-14 draft-vanelburg-dispatch-private-network-ind-05 -- kivinen@iki.fi From nobody Wed Feb 19 23:22:20 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0678E1A064F; Wed, 19 Feb 2014 23:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6BTGFftoK0J; Wed, 19 Feb 2014 23:22:12 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6F28E1A0422; Wed, 19 Feb 2014 23:22:12 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s1K7M7Tw032224; Thu, 20 Feb 2014 09:22:07 +0200 Received: from IL-EX10.ad.checkpoint.com ([169.254.2.228]) by DAG-EX10.ad.checkpoint.com ([169.254.3.228]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 09:22:07 +0200 From: Yoav Nir To: "" , " IESG" , "draft-ietf-eman-framework.all@tools.ietf.org" Thread-Topic: SECDIR review of draft-ietf-eman-framework-07 Thread-Index: AQHPLgx1Ya8fUKe8SUm7crencxxdfA== Date: Thu, 20 Feb 2014 07:22:06 +0000 Message-ID: <523EEFE5-315C-4A49-B802-1F7C31B7ADD9@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.132] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <591A1EFD1817CB4D9729B625002D5394@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Pr9FtjphKsdcvt4D-kwW1xR2cNs Subject: [secdir] SECDIR review of draft-ietf-eman-framework-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 07:22:15 -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. Although I am reviewing this for SECDIR, I have to begin with some editoria= l remarks. I don't know what tool was used, but it's producing a very ill-f= ormatted draft. It's true that the RFC editor staff will get it right, but = it is apparent that this is a combination of several sources. See for examp= le section 2 for a jarring mixture of line lengths. Or the broken-in-half = artwork of Figure 1 at the bottom of page 14. When you do that, someone (th= at's the RFC editor) has to put your diagrams back together, an error-prone= process that should be done by the authors. The middle of section 1 has a paragraph whose entire text is "Energy Manage= ment Documents Overview". Was this supposed to be the title to a subsection= ? The document also contains some parts that are supposed to be removed befor= e publication, for example the URL to the issue tracker. Please add a label= like "RFC EDITOR NOTE: REMOVE THE FOLLOWING PARAGRAPH" before this. They k= now to look for it, and we don't end up with things we didn't want in the d= raft. Speaking of issues, I followed that URL, and found that it is showing three= open issues. Are these resolved? I confess to being totally ignorant of the subject matter, but reading thro= ugh this I noticed something that surprised me. In section 3.1 there is thi= s paragraph: A simple device such as a light bulb can be switched on or off=20 only by switching its power supply. More complex devices may=20 have the ability to switch off themselves or to bring=20 themselves to states in which they consume very little power. Is the "may" here appropriate? Don't these complex devices *require* that t= hey switch themselves off rather than have their power switched off? Finally, the security considerations section. The most important recommenda= tion there is to use SNMPv3, because it includes authentication and privacy= , unlike earlier versions. I agree with the recommendation, but it should b= e noted that authentication was part of SNMPv1 as well, although different = mechanisms (not based on community strings) were only added in SNMPv3. "Pri= vacy" is a loaded term with multiple meanings. In SNMP privacy simply means= confidentiality, and it's preferable to use that term rather than "privacy= " which today is no longer used interchangeably with confidentiality. The section does an OK job of enumerating the risks, but IMO downplays them= . For example, "Unauthorized changes to the Energy Management Domain or bus= iness context of an Energy Object may result in misreporting or interruptio= n of power." There's no "may" about it. If an attacker can modify the ener= gy management domain, then they can at least shut down the network. Yoav From nobody Thu Feb 20 00:41:35 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F268C1A003D; Thu, 20 Feb 2014 00:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciXs7g3OUh8b; Thu, 20 Feb 2014 00:41:28 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (smtp01.srv.cs.cmu.edu [128.2.217.200]) by ietfa.amsl.com (Postfix) with ESMTP id AAF3B1A0037; Thu, 20 Feb 2014 00:41:28 -0800 (PST) Received: from [192.168.202.157] (pool-108-39-146-104.pitbpa.fios.verizon.net [108.39.146.104]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s1K8fKMm000497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 20 Feb 2014 03:41:22 -0500 (EST) Message-ID: <1392885680.27604.21.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: iesg@ietf.org, secdir@ietf.org, draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric.all@tools.ietf.org Date: Thu, 20 Feb 2014 03:41:20 -0500 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.200 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/srodMaIE1hpj3VhNm444dg_zesc Cc: jhutz@cmu.edu Subject: [secdir] secdir review of draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 08:41:31 -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 an RTCP extended report block for reporting the number of RTP payload bytes discarded from a stream after being received, due to packets arriving too early or too late. I believe this document is ready for publication, or nearly so. The Interval Metric (I) flag is described inconsistently with regard to the permissible values. The description of this flag indicates that only I=10 (Interval Duration) or I=11 (Cumulative Duration) are permitted, and that I=01 (Sampled Metric) is specifically prohibited. However, when discussing the meaning of the byte count, the meaning is described for I=11 and I=01 cases, rather than I=11 and I=10. This appears to be a typo, but should be corrected. Also, in the Interval Duration case, the byte count is described as being the number of bytes discarded "since the last RTCP XR Byte Discarded Block was received". In fact, since these blocks may be lost in transit, the sender of this report (the RTP receiver) cannot know which reports were received, and the interval is in fact since the last Byte Discarded block was _sent_. Further, some clarification is probably needed that we're actually talking about the last block with the same 'E' flag. That is, a block arriving with E=0 and I=10 describes bytes discarded due to arriving late since the last block with E=0, even if there was an intervening block with E=1. For the most part, the security considerations section of this document is fairly reasonable. However, one issue I do not see discussed is that senders relying on this information for tuning purposes may be tricked by an attacker into undesirable behavior. This may be one reason to apply appropriate integrity protection, but also suggests that senders take the reported values with a grain of salt. -- Jeffrey T. Hutzelman (N3NHS) Carnegie Mellon University - Pittsburgh, PA From nobody Thu Feb 20 00:47:30 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1801A003D for ; Thu, 20 Feb 2014 00:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWqaMvPPSq57 for ; Thu, 20 Feb 2014 00:47:27 -0800 (PST) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id CA01A1A0037 for ; Thu, 20 Feb 2014 00:47:26 -0800 (PST) Received: by mail-ee0-f42.google.com with SMTP id b15so775227eek.15 for ; Thu, 20 Feb 2014 00:47:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=e3r2vV5bSyl00VOlHuguNufL36TOIV8Rm6nhn3fenyQ=; b=KPiZN+5tBqsPXh6iEhzSTTq9u/b3lHJ/41Jq49BIQBxf/WyKGh8ZbTsaFjNaFtAPn0 Fr8U9zg7IIoH7XclVC4iFfgqmr/fN8K7xpbLrwgpARKkadMzL8TOHJHmW197qs/uILVR 9V2oCyQK1wFrCnhAHYVH1B0khFtJ2XYR67ypVjHju5O1QTtRfRp/ZTGUzz5JClo5MknZ iWGMCtn4tnJaqmMcpyib25hc768GFSlp4NbxvHKNTx/2iaAIQcEeaZOqkLeKv+/3OFXw DiD8RPBycWKjTeKFhr6v04Z2XGnpPWt0OKKosEDZ2mT75IPONHVUUsmt8oTDJ2mvYENQ /4Iw== X-Received: by 10.15.54.65 with SMTP id s41mr611571eew.100.1392886042546; Thu, 20 Feb 2014 00:47:22 -0800 (PST) Received: from [10.2.0.16] (89-139-136-195.bb.netvision.net.il. [89.139.136.195]) by mx.google.com with ESMTPSA id f45sm11019886eeg.5.2014.02.20.00.47.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Feb 2014 00:47:22 -0800 (PST) Message-ID: <5305C118.5040507@gmail.com> Date: Thu, 20 Feb 2014 10:47:20 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: =?UTF-8?B?VsOtemRhbCBBbGXFoQ==?= References: <4FBFAE5F.8010305@gmail.com> <5304D298.7050101@gmail.com> <1808340F7EC362469DDFFB112B37E2FCDA3256BC44@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCDA3256BC44@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ch_Z5Li3R_BCebDn8s6pj2mIx-s Cc: "draft-ietf-v6ops-64share.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-v6ops-64share-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 08:47:28 -0000 [Dropped IESG] Hi Ales, please see below. Thanks, Yaron On 02/19/2014 05:59 PM, Vízdal Aleš wrote: > Dear Yaron, > > Many thanks for your review. > >> -----Original Message----- >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] [...] >> Summary >> >> The document is ready to progress. >> >> Details >> >> - I don't understand why the first scenario (sec. 4.2) is >> even useful, i.e. why allocate the /64 to the LAN (and not >> just settle for a link-local prefix) when the UE does not >> have an address on the 3GPP link, and so cannot route traffic >> to the Internet? > > This scenario is discussing a case where the 3GPP interface assigned > GUA prefix will be moved to the LAN link, the 3GPP link will still > be LLA numbered. So can Internet traffic from the LAN be routed through the 3GPP link in this case? It looks funny to me to have a default route with an LLA. If this is a small independent network with no Internet routing, you don't really need a GUA prefix. > >> - Despite the non-normative status of the document, I think >> the security considerations deserve stronger wording. I >> suggest to replace "shall be considered" by "SHOULD be >> applied". > > OK, we will consider it. > >> - I would suggest that the security considerations also >> mention the privacy implications of having a (typically) >> small number of devices, all within a single unchanging >> network prefix. I *believe* this is behind the discussion of >> RFC 4941 is Sec. 4.3, but I would rather have the threat >> spelled out. > > OK, the lifetime of a prefix is bound to the lifetime of the network > attach (context), once the device (UE) re-attaches a new prefix will > be assigned by the network. This solution shall be understood as > an interim one bridging the gap till DHCP-PD will be widely available. This "interim" period can be a few years, and in the meantime we have a large privacy issue here. Does the provider normally enforce periodic reassignment of the network prefix? Otherwise I can see prefixes remaining valid for months (for small routers of course, not for phones). > >> Thanks, >> Yaron > > Cheers, > Ales > From nobody Thu Feb 20 01:55:41 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BD31A0083 for ; Thu, 20 Feb 2014 01:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9hqbjwUc8Gc for ; Thu, 20 Feb 2014 01:55:35 -0800 (PST) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id E554B1A0063 for ; Thu, 20 Feb 2014 01:55:32 -0800 (PST) From: =?utf-8?B?VsOtemRhbCBBbGXFoQ==?= To: Yaron Sheffer Date: Thu, 20 Feb 2014 10:55:23 +0100 Thread-Topic: SecDir review of draft-ietf-v6ops-64share-09 Thread-Index: Ac8uGGCXp2OwkdPOQ/uwlLfeYhot7AABtuwA Message-ID: <1808340F7EC362469DDFFB112B37E2FCDA3256BD0B@SRVHKE02.rdm.cz> References: <4FBFAE5F.8010305@gmail.com> <5304D298.7050101@gmail.com> <1808340F7EC362469DDFFB112B37E2FCDA3256BC44@SRVHKE02.rdm.cz> <5305C118.5040507@gmail.com> In-Reply-To: <5305C118.5040507@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-loop: 2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forwarded Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Lt0wlVP1IUzU1Z2u-n8LUwVmM4A Cc: "draft-ietf-v6ops-64share.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-v6ops-64share-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 09:55:38 -0000 SGkgWWFyb24sDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4+IEZyb206IFlhcm9uIFNoZWZmZXIgW21haWx0bzp5YXJvbmYuaWV0ZkBn bWFpbC5jb21dDQo+IA0KPiBbLi4uXQ0KPiANCj4gPj4gU3VtbWFyeQ0KPiA+Pg0KPiA+PiBUaGUg ZG9jdW1lbnQgaXMgcmVhZHkgdG8gcHJvZ3Jlc3MuDQo+ID4+DQo+ID4+IERldGFpbHMNCj4gPj4N Cj4gPj4gLSBJIGRvbid0IHVuZGVyc3RhbmQgd2h5IHRoZSBmaXJzdCBzY2VuYXJpbyAoc2VjLiA0 LjIpIGlzDQo+IGV2ZW4NCj4gPj4gdXNlZnVsLCBpLmUuIHdoeSBhbGxvY2F0ZSB0aGUgLzY0IHRv IHRoZSBMQU4gKGFuZCBub3QganVzdA0KPiBzZXR0bGUgZm9yDQo+ID4+IGEgbGluay1sb2NhbCBw cmVmaXgpIHdoZW4gdGhlIFVFIGRvZXMgbm90IGhhdmUgYW4gYWRkcmVzcw0KPiBvbiB0aGUgM0dQ UA0KPiA+PiBsaW5rLCBhbmQgc28gY2Fubm90IHJvdXRlIHRyYWZmaWMgdG8gdGhlIEludGVybmV0 Pw0KPiA+DQo+ID4gVGhpcyBzY2VuYXJpbyBpcyBkaXNjdXNzaW5nIGEgY2FzZSB3aGVyZSB0aGUg M0dQUCBpbnRlcmZhY2UNCj4gYXNzaWduZWQNCj4gPiBHVUEgcHJlZml4IHdpbGwgYmUgbW92ZWQg dG8gdGhlIExBTiBsaW5rLCB0aGUgM0dQUCBsaW5rDQo+IHdpbGwgc3RpbGwgYmUNCj4gPiBMTEEg bnVtYmVyZWQuDQo+IA0KPiBTbyBjYW4gSW50ZXJuZXQgdHJhZmZpYyBmcm9tIHRoZSBMQU4gYmUg cm91dGVkIHRocm91Z2ggdGhlDQo+IDNHUFAgbGluayBpbiB0aGlzIGNhc2U/IA0KDQpZZXMsIHRo YXQncyB0aGUgaW50ZW50aW9uLg0KDQo+SXQgbG9va3MgZnVubnkgdG8gbWUgdG8gaGF2ZSBhIGRl ZmF1bHQgcm91dGUgd2l0aCBhbiBMTEEuDQoNCklmIHlvdSBkbyBTTEFBQywgdGhlIG9uLWxpbmsg cm91dGVyIHdpbGwgc2VuZCB5b3UgdGhlIFJBIG1lc3NhZ2UNCndob3NlIHNvdXJjZSBJUHY2IGFk ZHJlc3Mgd2lsbCBiZSBMTEEgYW5kIHdpbGwgYmUgYWxzbyB1c2VkDQphcyB0aGUgZGVmYXVsdCBy b3V0ZS4gKGFzIHBlciBOZWlnaGJvciBEaXNjb3ZlcnkgUkZDKQ0KDQo+IElmIHRoaXMgaXMgYSBz bWFsbCBpbmRlcGVuZGVudCBuZXR3b3JrIHdpdGggbm8gSW50ZXJuZXQNCj4gcm91dGluZywgeW91 IGRvbid0IHJlYWxseSBuZWVkIGEgR1VBIHByZWZpeC4NCg0KVGhlIHVzZS1jYXNlIGlzIHlvdXIg bW9iaWxlIHBob25lIGFjdGluZyBhcyBhIFdpRmkgYWNjZXNzIHBvaW50DQpmb3IgeW91ciBub3Rl Ym9vayB3aGlsZSB0cmF2ZWxsaW5nIG9yIHdoaWxlIGJlaW5nIGF0IGhvbWUuIFRoZXJlDQppcyBh IG5lZWQgZm9yIEdVQSBmb3IgdGhlIHRldGhlcmVkIGRldmljZXMuIChJUHY0IGFwcHJvYWNoIHdv dWxkDQpiZSBwcml2YXRlIElQVjQrTkFUNDQpDQoNCj4gPj4gLSBEZXNwaXRlIHRoZSBub24tbm9y bWF0aXZlIHN0YXR1cyBvZiB0aGUgZG9jdW1lbnQsIEkNCj4gdGhpbmsgdGhlDQo+ID4+IHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIGRlc2VydmUgc3Ryb25nZXIgd29yZGluZy4gSQ0KPiBzdWdnZXN0 IHRvDQo+ID4+IHJlcGxhY2UgInNoYWxsIGJlIGNvbnNpZGVyZWQiIGJ5ICJTSE9VTEQgYmUgYXBw bGllZCIuDQo+ID4NCj4gPiBPSywgd2Ugd2lsbCBjb25zaWRlciBpdC4NCj4gPg0KPiA+PiAtIEkg d291bGQgc3VnZ2VzdCB0aGF0IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhbHNvDQo+IG1l bnRpb24gdGhlDQo+ID4+IHByaXZhY3kgaW1wbGljYXRpb25zIG9mIGhhdmluZyBhICh0eXBpY2Fs bHkpIHNtYWxsIG51bWJlcg0KPiBvZiBkZXZpY2VzLA0KPiA+PiBhbGwgd2l0aGluIGEgc2luZ2xl IHVuY2hhbmdpbmcgbmV0d29yayBwcmVmaXguIEkgKmJlbGlldmUqDQo+IHRoaXMgaXMNCj4gPj4g YmVoaW5kIHRoZSBkaXNjdXNzaW9uIG9mIFJGQyA0OTQxIGlzIFNlYy4gNC4zLCBidXQgSSB3b3Vs ZA0KPiByYXRoZXINCj4gPj4gaGF2ZSB0aGUgdGhyZWF0IHNwZWxsZWQgb3V0Lg0KPiA+DQo+ID4g T0ssIHRoZSBsaWZldGltZSBvZiBhIHByZWZpeCBpcyBib3VuZCB0byB0aGUgbGlmZXRpbWUgb2YN Cj4gdGhlIG5ldHdvcmsNCj4gPiBhdHRhY2ggKGNvbnRleHQpLCBvbmNlIHRoZSBkZXZpY2UgKFVF KSByZS1hdHRhY2hlcyBhIG5ldw0KPiBwcmVmaXggd2lsbA0KPiA+IGJlIGFzc2lnbmVkIGJ5IHRo ZSBuZXR3b3JrLiBUaGlzIHNvbHV0aW9uIHNoYWxsIGJlDQo+IHVuZGVyc3Rvb2QgYXMgYW4NCj4g PiBpbnRlcmltIG9uZSBicmlkZ2luZyB0aGUgZ2FwIHRpbGwgREhDUC1QRCB3aWxsIGJlIHdpZGVs eQ0KPiBhdmFpbGFibGUuDQo+IA0KPiBUaGlzICJpbnRlcmltIiBwZXJpb2QgY2FuIGJlIGEgZmV3 IHllYXJzLCBhbmQgaW4gdGhlIG1lYW50aW1lDQo+IHdlIGhhdmUgYSBsYXJnZSBwcml2YWN5IGlz c3VlIGhlcmUuIERvZXMgdGhlIHByb3ZpZGVyDQo+IG5vcm1hbGx5IGVuZm9yY2UgcGVyaW9kaWMg cmVhc3NpZ25tZW50IG9mIHRoZSBuZXR3b3JrIHByZWZpeD8NCj4gT3RoZXJ3aXNlIEkgY2FuIHNl ZSBwcmVmaXhlcyByZW1haW5pbmcgdmFsaWQgZm9yIG1vbnRocyAoZm9yDQo+IHNtYWxsIHJvdXRl cnMgb2YgY291cnNlLCBub3QgZm9yIHBob25lcykuDQoNCllvdSdyZSByaWdodCwgdGhlIGludGVy aW0gc29sdXRpb25zIHRlbmQgdG8gYmVjb21lIHBlcm1hbmVudC4NCg0KU29tZSBuZXR3b3JrcyBk bywgc29tZSBkb24ndC4gUGxlYXNlIG5vdGUgdGhhdCB0aGUgbW9iaWxlIHBob25lcw0KYXJlIGdl dHRpbmcgYSAvNjQgdGhlc2UgZGF5cywgc28gdGhlIHBvdGVudGlhbCBwcml2YWN5IGlzc3VlIGlz DQphbHJlYWR5IHRoZXJlLCB3ZSdyZSBqdXN0IGV4dGVuZGluZyB0aGUgc2FtZSAvNjQgdG8gYSBz bWFsbCBMQU4uDQoNCkEgdXNlciBtYXkgcmUtbG9hZCB0aGUgZGV2aWNlIHRvIGdldCBhIG5ldyBw cmVmaXggaWYgdGhlaXIgbmV0d29yaw0KaXMgbm90IGVuZm9yY2luZyBhIG5ldyBwcmVmaXggZXZl cnkgbiBob3Vycy4NCg0KPiA+PiBUaGFua3MsDQo+ID4+ICAgICAgICBZYXJvbg0KDQpDaGVlcnMs DQpBbGVzDQo= From nobody Thu Feb 20 14:22:08 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F03B1A031F for ; Thu, 20 Feb 2014 14:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bj863qSKT8tT for ; Thu, 20 Feb 2014 14:21:20 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id C95851A031E for ; Thu, 20 Feb 2014 14:21:19 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1KMLCnO009566; Thu, 20 Feb 2014 22:21:13 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1KMLBZq009549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Feb 2014 22:21:12 GMT From: "Daniel King" To: References: <017601cf1943$8ebabe20$ac303a60$@olddog.co.uk> In-Reply-To: <017601cf1943$8ebabe20$ac303a60$@olddog.co.uk> Date: Thu, 20 Feb 2014 22:21:11 -0000 Message-ID: <02dd01cf2e8a$10469760$30d3c620$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHkDiVHbpwcnyd5R7MzcDez/HCHegEKUfAlmoygyfA= Content-Language: en-ca X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/B5yylDnSELIYxuvigoieE7ZP4eA X-Mailman-Approved-At: Thu, 20 Feb 2014 14:22:07 -0800 Cc: adrian@olddog.co.uk, mpls-chairs@tools.ietf.org, draft-ietf-mpls-ldp-multi-topology@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Sec Dir review of draft-ietf-mpls-ldp-multi-topology-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 22:21:23 -0000 Dear Kathleen, Thank you for your review of draft-ietf-mpls-ldp-multi-topology-09. We have updated the document to address a number of comments, including your Sec Dir review: http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-11 Please see our specific responses and/or how addressed your comments inline ("Authors:") below: > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf > Of Moriarty, Kathleen > Sent: 03 November 2013 23:27 > To: secdir@ietf.org; iesg@ietf.org; draft-ietf-mpls-ldp-multi- > topology.all@tools.ietf.org > Cc: rtorvi@juniper.net; daniel@olddog.co.uk; lichenyj@chinamobile.com; > huaimochen@huawei.com; zhenbin.li@huawei.com; huanglu@chinamobile.com; > ning.so@tatacommunications.com; emily.chen220@gmail.com > Subject: Sec Dir review of draft-ietf-mpls-ldp-multi-topology-09.txt > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > Review: > It is unclear to me how there could not be any security > considerations. The draft > introduces the ability to segregate traffic, allowing for the MT > capability to be > supported and then transitioned to equipment where the capability is > not supported. See section 3.2: > > If an LSR is changed from IGP-MT capable to non-MT capable, it may > wait until the routes update to withdraw FEC and release the label > mapping for existing LSPs of specific MT. > > The introduction states this feature may be used to segregate traffic > for different > purposes, including the use of management traffic. Typically, > management traffic > requires security protections such as session encryption. The > labeling also appears to allow for labels to change in addition to the > feature support disappearing. The security considerations should at > least mention that no additional protections are offered through this > mechanism of segregating traffic, > so that the reader is informed of this risk. The advantages may be > limited to QoS > and other possible benefits. Users should be aware that the > segregation offers > no security advantage over MPLS without MT. Authors: Thanks for your comments and as you suggest we have updated the Security section to state that MPLS MT does not offer any additional security over MPLS. Although we do not believe that the reader needs to be informed of any "risk" because we do not believe there is any additional risk. MPLS security, as discussed in RFC5920, is split into two items: control plane security and data plane security: - For the control plane (and our document is chiefly about the control plane) the security relies on the security provided for LDP; LDP runs over TCP so it can leverage TLS and TCP/AO. - The MPLS data plane is not secure and it is the responsibility of the application to secure its traffic as necessary (e.g., running management traffic over IPsec tunnels). We believe that the document makes no change to those basic concepts. However, we have clarified the Security section and included a reference to RFC5920 to assist/remind the reader. Also, we would like to underline that when MT support is withdrawn, there is no change in labeling. We have documented that when an LSR stops supporting MT, the LSPs that exist for non-default topologies must be torn down (because they are no longer supported) and this should be done by withdrawing the labels that were advertised for the other topologies. > Editorial nits: > > In Introduction, change from isolated to isolate: > Separate routing and MPLS domains may be used to isolated > multicast and IPv6 islands within the backbone network. > > To: Separate routing and MPLS domains may be used to isolate > multicast and IPv6 islands within the backbone network. Authors: Thanks, updated. > Change Carries to carry: > Management traffic could be separated from customer traffic using > multiple MTs, where the management traffic MT does not use links > that carries customer traffic. > To: Management traffic could be separated from customer traffic using > multiple MTs, where the management traffic MT does not use links > that carry customer traffic. > > Section 3.6: Change "imply" to "simply": > Since using different label spaces for different topologies would > imply significant changes to the data plane, a single global label > space is supported in this solution. Authors: Thanks, but this was intended so left. > Change "peer" to "peers": > There will be one session > supported for each pair of peer, even there are multiple topologies > supported between these two peers. > > Section 4.3.4: > Change from: > For the case that the LSP ping with return path not specified , the > reply packet must go through the default topology instead of the > topology where the Echo Request goes through. > To: For the case that the LSP ping with return path is not specified, the > reply packet must go through the default topology instead of the > topology where the Echo Request goes through. Authors: Thanks, updated. > Section 5.1: > Recommend breaking this text into multiple sentences. Authors: Thanks, updated. > Section 6: > Change from: > In case the bad things does happen, according > to [RFC5036], processing of such message should be aborted. > To: In case the bad things happen, according > to [RFC5036], processing of such messages should be aborted. Authors: Thanks, updated. > Section 7: I recommend breaking the second paragraph into multiple sentences. Authors: Thanks, updated. > Best regards, > Kathleen Again, thank you for your valuable comments and suggestions. Br, Dan & Authors. From nobody Thu Feb 20 14:31:05 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3A61A0324; Thu, 20 Feb 2014 14:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYoSGROpgRh7; Thu, 20 Feb 2014 14:31:01 -0800 (PST) Received: from smtp-out-02.aalto.fi (smtp-out-02.aalto.fi [130.233.228.121]) by ietfa.amsl.com (Postfix) with ESMTP id B0E881A0328; Thu, 20 Feb 2014 14:30:59 -0800 (PST) Received: from smtp-out-02.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 72B6827114A_306821FB; Thu, 20 Feb 2014 22:30:55 +0000 (GMT) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-out-02.aalto.fi (Sophos Email Appliance) with ESMTP id 3B1E4271147_306821FF; Thu, 20 Feb 2014 22:30:55 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 1AB4F1E021; Fri, 21 Feb 2014 00:30:55 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4jNPoWeJEVo7; Fri, 21 Feb 2014 00:30:49 +0200 (EET) Received: from [192.168.0.12] (cs181253247.pp.htv.fi [82.181.253.247]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id B1B7B1E0EA; Fri, 21 Feb 2014 00:30:49 +0200 (EET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Varun Singh In-Reply-To: <1392885680.27604.21.camel@destiny.pc.cs.cmu.edu> Date: Fri, 21 Feb 2014 00:30:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1392885680.27604.21.camel@destiny.pc.cs.cmu.edu> To: Jeffrey Hutzelman X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/eOS6C85XBkxATZ-_MGY-iDw6H3U Cc: draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 22:31:04 -0000 Hi Jeffery, Thank you for reviewing the document, comments inline. Cheers, Varun On 20 Feb 2014, at 10:41, Jeffrey Hutzelman wrote: [snip!] > The Interval Metric (I) flag is described inconsistently with regard = to > the permissible values. The description of this flag indicates that > only I=3D10 (Interval Duration) or I=3D11 (Cumulative Duration) are > permitted, and that I=3D01 (Sampled Metric) is specifically = prohibited. > However, when discussing the meaning of the byte count, the meaning is > described for I=3D11 and I=3D01 cases, rather than I=3D11 and I=3D10. = This > appears to be a typo, but should be corrected. >=20 Yes, it is a typo. Fixed. > Also, in the Interval Duration case, the byte count is described as > being the number of bytes discarded "since the last RTCP XR Byte > Discarded Block was received". In fact, since these blocks may be = lost > in transit, the sender of this report (the RTP receiver) cannot know > which reports were received, and the interval is in fact since the = last > Byte Discarded block was _sent_. Further, some clarification is Should be =93sent=94. Fixed. > probably needed that we're actually talking about the last block with > the same 'E' flag. That is, a block arriving with E=3D0 and I=3D10 > describes bytes discarded due to arriving late since the last block = with > E=3D0, even if there was an intervening block with E=3D1. >=20 It should be since the last RTCP report interval, if a report does not contain a bytes discarded block, the sender assumes that no bytes/packets are discarded, this behaviour is mentioned in=20 section 4.2. Should this be explicitly mentioned before at the end of section 3? >=20 > For the most part, the security considerations section of this = document > is fairly reasonable. However, one issue I do not see discussed is = that > senders relying on this information for tuning purposes may be tricked > by an attacker into undesirable behavior. This may be one reason to > apply appropriate integrity protection, but also suggests that senders > take the reported values with a grain of salt. >=20 Proposal to add this: The discarded bytes report is employed by the sender to perform=20 congestion control, typically, for calculating goodput. In these cases=20= an attacker MAY drive the endpoint to lower its sending rate and=20 under-utilised the link, therefore media senders should choose appropriate security measures to mitigate such attacks. Does the above text address you concern? > -- Jeffrey T. Hutzelman (N3NHS) > Carnegie Mellon University - Pittsburgh, PA From nobody Thu Feb 20 15:03:51 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A681A0304; Thu, 20 Feb 2014 15:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rnz1g9-l_FZG; Thu, 20 Feb 2014 15:03:43 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (smtp02.srv.cs.cmu.edu [128.2.217.201]) by ietfa.amsl.com (Postfix) with ESMTP id 636031A0105; Thu, 20 Feb 2014 15:03:42 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s1KN3Wms026289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 20 Feb 2014 18:03:33 -0500 (EST) Message-ID: <1392937412.4395.114.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Varun Singh Date: Thu, 20 Feb 2014 18:03:32 -0500 In-Reply-To: References: <1392885680.27604.21.camel@destiny.pc.cs.cmu.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.201 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/5WW5IXhzh4xSduWdQTeMVI0WWzQ Cc: draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric.all@tools.ietf.org, secdir@ietf.org, The IESG , jhutz@cmu.edu Subject: Re: [secdir] secdir review of draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 23:03:46 -0000 On Fri, 2014-02-21 at 00:30 +0200, Varun Singh wrote: > > probably needed that we're actually talking about the last block with > > the same 'E' flag. That is, a block arriving with E=0 and I=10 > > describes bytes discarded due to arriving late since the last block with > > E=0, even if there was an intervening block with E=1. > > > > It should be since the last RTCP report interval, if a report does not > contain a bytes discarded block, the sender assumes that no > bytes/packets are discarded, this behaviour is mentioned in > section 4.2. > > Should this be explicitly mentioned before at the end of section 3? OK; so it's not really since the last Bytes Discarded block at all, but since the last report interval? That makes sense, but contradicts the third-to-last paragraph in section 3 (quoted below): If Interval Metric flag (I=11) is set, the value in the field indicates the number of RTP payload bytes discarded from the start of the session, if Interval Metric flag (I=01) is set, it indicates the number of bytes discarded since the last RTCP XR Byte Discarded Block was received. In fact, a reference to RFC6792 may be appropriate at the point where the I flag is first described. Then the above can be rewritten... "... If Interval Metric (I=10) is set, it indicates the number of bytes discarded in the most recent reporting interval." ... or something like that. > > > > For the most part, the security considerations section of this document > > is fairly reasonable. However, one issue I do not see discussed is that > > senders relying on this information for tuning purposes may be tricked > > by an attacker into undesirable behavior. This may be one reason to > > > apply appropriate integrity protection, but also suggests that senders > > take the reported values with a grain of salt. > > > > Proposal to add this: > > The discarded bytes report is employed by the sender to perform > congestion control, typically, for calculating goodput. In these cases > an attacker MAY drive the endpoint to lower its sending rate and > under-utilised the link, therefore media senders should choose > appropriate security measures to mitigate such attacks. > > > Does the above text address you concern? Pretty much. Is it also possible that an attacker might get the sender to _increase_ its sending rate, by reporting bytes discarded because they arrived too late? If so, that should be mentioned as well. -- Jeff From nobody Thu Feb 20 15:26:58 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684C01A0339; Thu, 20 Feb 2014 15:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEmn64RUqf79; Thu, 20 Feb 2014 15:26:54 -0800 (PST) Received: from smtp-out-01.aalto.fi (smtp-out-01.aalto.fi [130.233.228.120]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9FF1A0337; Thu, 20 Feb 2014 15:26:54 -0800 (PST) Received: from smtp-out-01.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id AC8AC115314_3068F39B; Thu, 20 Feb 2014 23:26:49 +0000 (GMT) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-out-01.aalto.fi (Sophos Email Appliance) with ESMTP id 4596F1152EF_3068F39F; Thu, 20 Feb 2014 23:26:49 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 299DB1E0EA; Fri, 21 Feb 2014 01:26:49 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7ZaaRxLGv3Iv; Fri, 21 Feb 2014 01:26:43 +0200 (EET) Received: from [192.168.0.12] (cs181253247.pp.htv.fi [82.181.253.247]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 741541E021; Fri, 21 Feb 2014 01:26:43 +0200 (EET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Varun Singh In-Reply-To: <1392937412.4395.114.camel@minbar.fac.cs.cmu.edu> Date: Fri, 21 Feb 2014 01:26:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <05FF2E57-25CB-42AE-BC01-C46BB6AB17C7@comnet.tkk.fi> References: <1392885680.27604.21.camel@destiny.pc.cs.cmu.edu> <1392937412.4395.114.camel@minbar.fac.cs.cmu.edu> To: Jeffrey Hutzelman X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/wUqNhF7AO4l3hu-ZmjH-nUJw3OQ Cc: draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 23:26:57 -0000 Hi Jeff, Comments inline. On 21 Feb 2014, at 01:03, Jeffrey Hutzelman wrote: > On Fri, 2014-02-21 at 00:30 +0200, Varun Singh wrote: >=20 >>> probably needed that we're actually talking about the last block = with >>> the same 'E' flag. That is, a block arriving with E=3D0 and I=3D10 >>> describes bytes discarded due to arriving late since the last block = with >>> E=3D0, even if there was an intervening block with E=3D1. >>>=20 >>=20 >> It should be since the last RTCP report interval, if a report does = not >> contain a bytes discarded block, the sender assumes that no >> bytes/packets are discarded, this behaviour is mentioned in=20 >> section 4.2. >>=20 >> Should this be explicitly mentioned before at the end of section 3? >=20 > OK; so it's not really since the last Bytes Discarded block at all, = but > since the last report interval? That makes sense, but contradicts the > third-to-last paragraph in section 3 (quoted below): >=20 > If Interval Metric flag (I=3D11) is set, the value in the field > indicates the number of RTP payload bytes discarded from the start = of > the session, if Interval Metric flag (I=3D01) is set, it indicates = the > number of bytes discarded since the last RTCP XR Byte Discarded = Block > was received. >=20 >=20 > In fact, a reference to RFC6792 may be appropriate at the point where > the I flag is first described. Then the above can be rewritten=85 >=20 Fixed. > "... If Interval Metric (I=3D10) is set, it indicates the number of = bytes > discarded in the most recent reporting interval." >=20 > ... or something like that. >=20 The most recent reporting interval works. >=20 >>>=20 >>> For the most part, the security considerations section of this = document >>> is fairly reasonable. However, one issue I do not see discussed is = that >>> senders relying on this information for tuning purposes may be = tricked >>> by an attacker into undesirable behavior. This may be one reason to >>=20 >>> apply appropriate integrity protection, but also suggests that = senders >>> take the reported values with a grain of salt. >>>=20 >>=20 >> Proposal to add this: >>=20 >> The discarded bytes report is employed by the sender to perform=20 >> congestion control, typically, for calculating goodput. In these = cases=20 >> an attacker MAY drive the endpoint to lower its sending rate and=20 >> under-utilised the link, therefore media senders should choose >> appropriate security measures to mitigate such attacks. >>=20 >>=20 >> Does the above text address you concern? >=20 > Pretty much. Is it also possible that an attacker might get the = sender > to _increase_ its sending rate, by reporting bytes discarded because > they arrived too late? If so, that should be mentioned as well. >=20 Late could mean congestion and the receiver is skipping these packets.=20= early may signify the jitter buffer is small and not capable of handling = the packet=20 (or perhaps a route change and packets are arriving out of order). I = don=92t think that=20 in either case, the sender will increase the rate in response to a = discard report.=20 Or did I misunderstand ? > -- Jeff From nobody Thu Feb 20 15:38:24 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FBC1A0342; Thu, 20 Feb 2014 15:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzbYN0oB2OFp; Thu, 20 Feb 2014 15:38:21 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (smtp03.srv.cs.cmu.edu [128.2.217.202]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8CC1A0304; Thu, 20 Feb 2014 15:38:21 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s1KNcA4w005565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 20 Feb 2014 18:38:11 -0500 (EST) Message-ID: <1392939490.4395.116.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Varun Singh Date: Thu, 20 Feb 2014 18:38:10 -0500 In-Reply-To: <05FF2E57-25CB-42AE-BC01-C46BB6AB17C7@comnet.tkk.fi> References: <1392885680.27604.21.camel@destiny.pc.cs.cmu.edu> <1392937412.4395.114.camel@minbar.fac.cs.cmu.edu> <05FF2E57-25CB-42AE-BC01-C46BB6AB17C7@comnet.tkk.fi> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 8bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.202 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/bBY6LlOC2RTc6vwIzo96GNG4YmY Cc: draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric.all@tools.ietf.org, secdir@ietf.org, The IESG , jhutz@cmu.edu Subject: Re: [secdir] secdir review of draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 23:38:23 -0000 On Fri, 2014-02-21 at 01:26 +0200, Varun Singh wrote: > Late could mean congestion and the receiver is skipping these packets. > early may signify the jitter buffer is small and not capable of handling the packet > (or perhaps a route change and packets are arriving out of order). I don’t think that > in either case, the sender will increase the rate in response to a discard report. > > Or did I misunderstand ? Nope; that's where I was going, and your explanation makes sense to me. In which case, the text you proposed seems fine to me. -- Jeff From nobody Fri Feb 21 06:40:16 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D1E1A018B for ; Fri, 21 Feb 2014 06:40:15 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHgGBRrvO4Jd for ; Fri, 21 Feb 2014 06:40:12 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id F25231A0169 for ; Fri, 21 Feb 2014 06:40:11 -0800 (PST) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s1LEe41M002456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Feb 2014 09:40:06 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s1LEe41M002456 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1392993607; bh=r+nHo7EFinAYTq3BgvoUK6/LbkY=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=K4aEbdeOYGTaa52hfzY5htHpSeqAWiT8nEB5urkiMoIkiEDir6JeIGJVDE1sS+9re 6A2UQ2hxe2B09MoA3qLePqSDqoiRI19IrMmeN4+dGHWarhSKh4EZFihv5mPZZ/MJmi 2aIoXMckQtVu++F5g5M8uJ8UbnRKfN8vG2znY3+s= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s1LEe41M002456 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd05.lss.emc.com (RSA Interceptor); Fri, 21 Feb 2014 06:39:56 -0800 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s1LEdtjC018346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 09:39:56 -0500 Received: from mx15a.corp.emc.com ([169.254.1.167]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Fri, 21 Feb 2014 09:39:55 -0500 From: "Moriarty, Kathleen" To: Daniel King Date: Fri, 21 Feb 2014 09:39:47 -0500 Thread-Topic: Sec Dir review of draft-ietf-mpls-ldp-multi-topology-09.txt Thread-Index: AQHkDiVHbpwcnyd5R7MzcDez/HCHegEKUfAlmoygyfCAABWr0A== Message-ID: References: <017601cf1943$8ebabe20$ac303a60$@olddog.co.uk> <02dd01cf2e8a$10469760$30d3c620$@olddog.co.uk> In-Reply-To: <02dd01cf2e8a$10469760$30d3c620$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/UP41QhGIve0wrSW0gpdlo2v4MoY Cc: "adrian@olddog.co.uk" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-multi-topology@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Sec Dir review of draft-ietf-mpls-ldp-multi-topology-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 14:40:15 -0000 Hello Dan, Thank you for the update to the draft and response to my comments. I'll ha= ve to read through the draft again to see why I thought labels changed. If= I find a specific point, I'll let you know so it could be clarified for ot= her readers, but it may not be an issue. I have a couple of responses below that start with KM>. Thank you! Kathleen -----Original Message----- From: Daniel King [mailto:daniel@olddog.co.uk]=20 Sent: Thursday, February 20, 2014 5:21 PM To: Moriarty, Kathleen Cc: draft-ietf-mpls-ldp-multi-topology@tools.ietf.org; adrian@olddog.co.uk;= mpls-chairs@tools.ietf.org; secdir@ietf.org Subject: RE: Sec Dir review of draft-ietf-mpls-ldp-multi-topology-09.txt Dear Kathleen, Thank you for your review of draft-ietf-mpls-ldp-multi-topology-09. We have= updated the document to address a number of comments, including your Sec D= ir review: http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-11 Please see our specific responses and/or how addressed your comments inline ("Authors:") below: > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf=20 > Of Moriarty, Kathleen > Sent: 03 November 2013 23:27 > To: secdir@ietf.org; iesg@ietf.org; draft-ietf-mpls-ldp-multi-=20 > topology.all@tools.ietf.org > Cc: rtorvi@juniper.net; daniel@olddog.co.uk; lichenyj@chinamobile.com;=20 > huaimochen@huawei.com; zhenbin.li@huawei.com; huanglu@chinamobile.com;=20 > ning.so@tatacommunications.com; emily.chen220@gmail.com > Subject: Sec Dir review of draft-ietf-mpls-ldp-multi-topology-09.txt >=20 > I have reviewed this document as part of the security directorate's=20 > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security=20 > area directors. Document editors and WG chairs should treat these=20 > comments just like any other last call comments. >=20 > Review: > It is unclear to me how there could not be any security=20 > considerations. The draft > introduces the ability to segregate traffic, allowing for the MT=20 > capability to be > supported and then transitioned to equipment where the capability is=20 > not supported. See section 3.2: >=20 > If an LSR is changed from IGP-MT capable to non-MT capable, it may > wait until the routes update to withdraw FEC and release the label > mapping for existing LSPs of specific MT. >=20 > The introduction states this feature may be used to segregate traffic=20 > for different > purposes, including the use of management traffic. Typically,=20 > management traffic > requires security protections such as session encryption. The=20 > labeling also appears to allow for labels to change in addition to the=20 > feature support disappearing. The security considerations should at=20 > least mention that no additional protections are offered through this=20 > mechanism of segregating traffic, > so that the reader is informed of this risk. The advantages may be=20 > limited to QoS > and other possible benefits. Users should be aware that the=20 > segregation offers > no security advantage over MPLS without MT. Authors: Thanks for your comments and as you suggest we have updated the Se= curity section to state that MPLS MT does not offer any additional security= over MPLS. Although we do not believe that the reader needs to be informed= of any "risk" because we do not believe there is any additional risk. =20 KM> I agree there is no additional risk, the 'risk' is more the perception = a reader may have if they see something is segregated and assumes that mean= s it is secure. The reader just needs to understand the points noted above= so they are clear that the traffic may not remain segregated. MPLS security, as discussed in RFC5920, is split into two items: control pl= ane security and data plane security:=20 - For the control plane (and our document is chiefly about the control plane) the security relies on the security provided for LDP; LDP runs over = TCP so it can leverage TLS and TCP/AO. =20 - The MPLS data plane is not secure and it is the responsibility of the app= lication to secure its traffic as necessary (e.g., running management traff= ic over IPsec tunnels). We believe that the document makes no change to th= ose basic concepts. However, we have clarified the Security section and inc= luded a reference to RFC5920 to assist/remind the reader.=20 KM> Thank you! Also, we would like to underline that when MT support is withdrawn, there i= s no change in labeling. We have documented that when an LSR stops supporti= ng MT, the LSPs that exist for non-default topologies must be torn down (be= cause they are no longer supported) and this should be done by withdrawing = the labels that were advertised for the other topologies. KM> OK, This was my first time through the draft and I'll go back to see wh= y I came to that assumption. =20 > Editorial nits: >=20 > In Introduction, change from isolated to isolate: > Separate routing and MPLS domains may be used to isolated > multicast and IPv6 islands within the backbone network. >=20 > To: Separate routing and MPLS domains may be used to isolate > multicast and IPv6 islands within the backbone network. Authors: Thanks, updated.=20 =20 > Change Carries to carry: > Management traffic could be separated from customer traffic using > multiple MTs, where the management traffic MT does not use links > that carries customer traffic. > To: Management traffic could be separated from customer traffic using > multiple MTs, where the management traffic MT does not use links > that carry customer traffic. >=20 > Section 3.6: Change "imply" to "simply": > Since using different label spaces for different topologies would > imply significant changes to the data plane, a single global label > space is supported in this solution. Authors: Thanks, but this was intended so left.=20 > Change "peer" to "peers": > There will be one session > supported for each pair of peer, even there are multiple topologies > supported between these two peers. >=20 > Section 4.3.4: > Change from: > For the case that the LSP ping with return path not specified , the > reply packet must go through the default topology instead of the > topology where the Echo Request goes through. > To: For the case that the LSP ping with return path is not specified, the > reply packet must go through the default topology instead of the > topology where the Echo Request goes through. Authors: Thanks, updated. =20 > Section 5.1: > Recommend breaking this text into multiple sentences. Authors: Thanks, updated. =20 > Section 6: > Change from: > In case the bad things does happen, according > to [RFC5036], processing of such message should be aborted. > To: In case the bad things happen, according > to [RFC5036], processing of such messages should be aborted. Authors: Thanks, updated. > Section 7: I recommend breaking the second paragraph into multiple sentences. Authors: Thanks, updated. > Best regards, > Kathleen Again, thank you for your valuable comments and suggestions.=20 Br, Dan & Authors.=20 From nobody Sat Feb 22 07:18:10 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2701A02E2; Fri, 21 Feb 2014 15:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1ZGEP54aW4t; Fri, 21 Feb 2014 15:27:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 928E71A0272; Fri, 21 Feb 2014 15:27:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBJ45264; Fri, 21 Feb 2014 23:27:06 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 23:26:47 +0000 Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 23:27:04 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml704-chm.china.huawei.com ([169.254.6.202]) with mapi id 14.03.0158.001; Fri, 21 Feb 2014 15:26:49 -0800 From: Linda Dunbar To: Tina TSOU , "secdir@ietf.org" , "iesg@ietf.org" , "draft-dunbar-armd-arp-nd-scaling-practices@tools.ietf.org" Thread-Topic: SECDIR early review of draft-dunbar-armd-arp-nd-scaling-practices-07 Thread-Index: AQHPKfsc65F4O1ntVkqzN1q05nHFcJrAX++Q Date: Fri, 21 Feb 2014 23:26:49 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C841F6@dfweml701-chm.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.67] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645C841F6dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/OUwQlX-IFQknKadZS1JbKoP67Oc X-Mailman-Approved-At: Sat, 22 Feb 2014 07:18:02 -0800 Subject: Re: [secdir] SECDIR early review of draft-dunbar-armd-arp-nd-scaling-practices-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 23:27:17 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645C841F6dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tina, Thank you very much for the review. Replies are inserted below From: Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com] Sent: Friday, February 14, 2014 9:08 PM To: secdir@ietf.org; iesg@ietf.org; draft-dunbar-armd-arp-nd-scaling-practi= ces@tools.ietf.org Subject: SECDIR early review of draft-dunbar-armd-arp-nd-scaling-practices-= 07 Dear all, I have reviewed this document as part of the security directorate's ongoing= effort to for early review of WG drafts. These comments were written prim= arily for the benefit of the security area directors. Document editors and= working group chairs should treat these comments just like any other comme= nts. Section 1: Please expand ToR upon first occurrence. [Linda] ToR is already defined in the Terminology section. Is it still nece= ssary to expand? Section 2, page 3/4: Could you please clarify the difference between "node" and "end station"? A= re they synonyms? [Linda] Node can be switches/routers. "end station" doesn't route or forwar= d traffic. Packets are terminated by "end station". Section 5.1.1: Shouldn't it be possible to avoid ND load by proper setting of the Reachabl= eTime variable? -- This wouldn't require any protocol changes. [Linda] Do you mean changing the setting on GuestOS? The issue is that many= Guest OSs are out of network's control. If Network can control Guest OS's = behavior, many things can be easier. Section 5.1.1: Snooping ARP packets probably means increased load (a disadvantage you didn= 't mention). [Linda] yes, it increase the load, but in a controlled way. So the routers = can process them within its capacity. So, it is not really disadvantage. Section 5.1.1: When address resolution is needed to deliver a packet, some routers just dr= op the packet when they engage in ARP (see http://tools.ietf.org/html/rfc62= 74#section-4.2.3). The same is true for IPv6 ND. [Linda] correct. The behavior is described in the second paragraph of Secti= on 5.1.2: Solution: To protect a router from being overburdened by resolving target M= AC addresses, one solution is for the router to limit the rate of resolving= target MAC addresses for inbound traffic whose target is not in the router= 's ARP/ND cache. When the rate is exceeded, the incoming traffic whose targ= et is not in the ARP/ND cache is dropped. Section 8: While this document does not introduce new issues itself, it should at leas= t mention how the same ARP/ND issues may be intentionally triggered by an a= ttacker. For example, you may reference RFC 6583 [Linda] Sure. Will add in the new version. * Nits Section 4, page 4: > There are no address > resolution issue in this design. Replace "issue" with "issues" [Linda] In the latest draft ( 07 version: https://datatracker.ietf.org/doc/= draft-dunbar-armd-arp-nd-scaling-practices/), it is already changed: There is no address resolution issue in this design. Section 5.1.1, page 5: "Ipv6" -> "IPv6" [Linda ] In the latest draft (07 version), it is already changed. Section 5.1.2: Please expand UNA (possibly in the terminology section) -- you probably mea= n "Unsolicited..", but this should be explicit. [Linda] in the latest draft (07 version), UNA is already listed under the T= erminology section. Thank you very much for the review and comments. Linda Thank you, Tina From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Matthew Lepinski Sent: Friday, February 14, 2014 2:52 AM To: secdir@ietf.org; iesg@ietf.org; draft-housley-pkix-oids.all@tools.ietf.org Subject: [secdir] SECDIR review of draft-housley-pkix-oids 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 working group chairs should treat these comments j= ust like any other last call comments. This document returns control of the PKIX object identifier arc to IANA. Th= at is, it establishes a new IANA registry for OIDs in the PKIX arc and popu= lates that registry with the existing OID assignments. Finally, the documen= t establishes expert review as the criteria for future additions to the reg= istry and includes guidance that for review. After reviewing the document, I agree with the author that this document in= troduces no new security concerns. I found no issues in the document and I believe it is ready for publication= . ------------------------------- Nits The author should consider including an expansion of the acronym SMI, which= is used frequently in the document. (I believe in this context SMI =3D Str= ucture of Management Information) In Section 3: s/be related to X.509 certificate/be related to X.509 certificates/ In Section 3.1: s/to points to this document/to point to this document/ --_000_4A95BA014132FF49AE685FAB4B9F17F645C841F6dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tina,

 <= /p>

Thank you very much for t= he review.

 <= /p>

Replies are inserted belo= w

 <= /p>

From: Tina TSO= U [mailto:Tina.Tsou.Zouting@huawei.com]
Sent: Friday, February 14, 2014 9:08 PM
To: secdir@ietf.org; iesg@ietf.org; draft-dunbar-armd-arp-nd-scaling= -practices@tools.ietf.org
Subject: SECDIR early review of draft-dunbar-armd-arp-nd-scaling-pra= ctices-07

 

Dear  all,

I have reviewed this document as part of the security directorate's ong= oing effort to for early review of WG drafts.  These comments were written primarily for the benefit of the security area directors.&nbs= p; Document editors and working group chairs should treat these comments ju= st like any other comments.

 

Section 1:

Please expand ToR upon first occurrence.

[Linda] ToR is already defined in the Terminology section. Is it still = necessary to expand?  

 

Section 2, page 3/4:

Could you please clarify the difference between "node" and &q= uot;end station"? Are they synonyms?

[Linda] Node can be switches/routers. “end station” doesn&#= 8217;t route or forward traffic. Packets are terminated by “end stati= on”.

 

 

 

Section 5.1.1:

 

Shouldn't it be possible to avoid ND load by proper setting of the Reac= hableTime variable? -- This wouldn't require any protocol changes.

 

[Linda] Do you mean changing the setting on GuestOS? The issue is that = many Guest OSs are out of network’s control. If Network can control Guest OS’s behavior, many things can be easier. <= /span>

 

 

Section 5.1.1:

 

Snooping ARP packets probably means increased load (a disadvantage you = didn't mention).

[Linda] yes, it increase the load, but in a controlled way. So the rout= ers can process them within its capacity. So, it is not really disadvantage.

 

Section 5.1.1:

 

When address resolution is needed to deliver a packet, some routers jus= t drop the packet when they engage in ARP (see http://tools.i= etf.org/html/rfc6274#section-4.2.3). The same is true for

IPv6 ND.

 

[Linda] correct. The behavior is described in the second paragraph of S= ection 5.1.2:

Solution: To prote= ct a router from being overburdened by resolving target MAC addresses, one = solution is for the router to limit the rate of resolving target MAC addres= ses for inbound traffic whose target is not in the router’s ARP/ND cache. When the rate is exceeded, the = incoming traffic whose target is not in the ARP/ND cache is dropped.

 

 

Section 8:

 

While this document does not introduce new issues itself, it should at = least mention how the same ARP/ND issues may be intentionally triggered by an attacker. For example, you may reference RFC 6583

 

[Linda] Sure. Will add in the new version.

 

* Nits

 

Section 4, page 4:

> There are no address

>    resolution issue in this design.

 

Replace "issue" with "issues"

[Linda] In the latest draft ( 07 version: https://datatracker.ietf.org/= doc/draft-dunbar-armd-arp-nd-scaling-practices/), it is already changed:

 

There is no address resol= ution issue in this design.

 

 

 

Section 5.1.1, page 5:

 

"Ipv6" -> "IPv6"

 

[Linda ] In the latest draft (07 version), it is already changed.

 

 

Section 5.1.2:

 

Please expand UNA (possibly in the terminology section) -- you probably= mean "Unsolicited..", but this should be explicit.

[Linda] in the latest draft (07 version), UNA is already listed under t= he Terminology section.

 

Thank you very much for the review and comments.

 

Linda

 

Thank you,

Tina

 

 

I have reviewed this document as part of t= he 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= working group chairs should treat these comments just like any other last = call comments.

 

This document returns control of the PKIX object identifie= r arc to IANA. That is, it establishes a new IANA registry for OIDs in the = PKIX arc and populates that registry with the existing OID assignments. Finally, the document establishes expert review as the c= riteria for future additions to the registry and includes gu= idance that for review.

 

After reviewing the document, I agree with the author that= this document introduces no new security concerns. =

 

I found no issues in the document and I believe it is read= y for publication.

 

-------------------------------

 

Nits

 

The author should consider including an expansion of the&n= bsp;acronym SMI, which is used frequently in the document. (I believe = in this context SMI =3D Structure of Management Information)

 

In Section 3:

s/be related to X.509 c= ertificate/be related to X.509 certificates/

 

In Section 3.1: 

s/to points to this doc= ument/to point to this document/

 

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645C841F6dfweml701chmchi_-- From nobody Sat Feb 22 07:18:12 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2016B1A025C; Fri, 21 Feb 2014 15:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCuFt2LWYTUT; Fri, 21 Feb 2014 15:32:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E95B41A0272; Fri, 21 Feb 2014 15:32:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDV41454; Fri, 21 Feb 2014 23:32:34 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 23:32:15 +0000 Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 23:32:33 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml703-chm.china.huawei.com ([169.254.5.188]) with mapi id 14.03.0158.001; Fri, 21 Feb 2014 15:32:14 -0800 From: Linda Dunbar To: Tina TSOU , "secdir@ietf.org" , "iesg@ietf.org" , "draft-dunbar-armd-arp-nd-scaling-practices@tools.ietf.org" Thread-Topic: SECDIR early review of draft-dunbar-armd-arp-nd-scaling-practices-07 Thread-Index: AQHPKfsc65F4O1ntVkqzN1q05nHFcJrAX++QgAAGE6A= Date: Fri, 21 Feb 2014 23:32:13 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C84211@dfweml701-chm.china.huawei.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.67] Content-Type: multipart/mixed; boundary="_004_4A95BA014132FF49AE685FAB4B9F17F645C84211dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/2xvr0SiHImkpxyjQZRBUlD3aNOw X-Mailman-Approved-At: Sat, 22 Feb 2014 07:18:02 -0800 Subject: Re: [secdir] SECDIR early review of draft-dunbar-armd-arp-nd-scaling-practices-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 23:32:45 -0000 --_004_4A95BA014132FF49AE685FAB4B9F17F645C84211dfweml701chmchi_ Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645C84211dfweml701chmchi_" --_000_4A95BA014132FF49AE685FAB4B9F17F645C84211dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tina, Please see the attached 08 version for the changes to address your comments= . Please let me know if they are OK. Thanks, Linda From: Linda Dunbar Sent: Friday, February 21, 2014 5:27 PM To: Tina TSOU; secdir@ietf.org; iesg@ietf.org; draft-dunbar-armd-arp-nd-sca= ling-practices@tools.ietf.org Subject: RE: SECDIR early review of draft-dunbar-armd-arp-nd-scaling-practi= ces-07 Tina, Thank you very much for the review. Replies are inserted below From: Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com] Sent: Friday, February 14, 2014 9:08 PM To: secdir@ietf.org; iesg@ietf.org; draft-dunbar-armd-arp-nd-scaling-practices@tools.ietf.org Subject: SECDIR early review of draft-dunbar-armd-arp-nd-scaling-practices-= 07 Dear all, I have reviewed this document as part of the security directorate's ongoing= effort to for early review of WG drafts. These comments were written prim= arily for the benefit of the security area directors. Document editors and= working group chairs should treat these comments just like any other comme= nts. Section 1: Please expand ToR upon first occurrence. [Linda] ToR is already defined in the Terminology section. Is it still nece= ssary to expand? Section 2, page 3/4: Could you please clarify the difference between "node" and "end station"? A= re they synonyms? [Linda] Node can be switches/routers. "end station" doesn't route or forwar= d traffic. Packets are terminated by "end station". Section 5.1.1: Shouldn't it be possible to avoid ND load by proper setting of the Reachabl= eTime variable? -- This wouldn't require any protocol changes. [Linda] Do you mean changing the setting on GuestOS? The issue is that many= Guest OSs are out of network's control. If Network can control Guest OS's = behavior, many things can be easier. Section 5.1.1: Snooping ARP packets probably means increased load (a disadvantage you didn= 't mention). [Linda] yes, it increase the load, but in a controlled way. So the routers = can process them within its capacity. So, it is not really disadvantage. Section 5.1.1: When address resolution is needed to deliver a packet, some routers just dr= op the packet when they engage in ARP (see http://tools.ietf.org/html/rfc62= 74#section-4.2.3). The same is true for IPv6 ND. [Linda] correct. The behavior is described in the second paragraph of Secti= on 5.1.2: Solution: To protect a router from being overburdened by resolving target M= AC addresses, one solution is for the router to limit the rate of resolving= target MAC addresses for inbound traffic whose target is not in the router= 's ARP/ND cache. When the rate is exceeded, the incoming traffic whose targ= et is not in the ARP/ND cache is dropped. Section 8: While this document does not introduce new issues itself, it should at leas= t mention how the same ARP/ND issues may be intentionally triggered by an a= ttacker. For example, you may reference RFC 6583 [Linda] Sure. Will add in the new version. * Nits Section 4, page 4: > There are no address > resolution issue in this design. Replace "issue" with "issues" [Linda] In the latest draft ( 07 version: https://datatracker.ietf.org/doc/= draft-dunbar-armd-arp-nd-scaling-practices/), it is already changed: There is no address resolution issue in this design. Section 5.1.1, page 5: "Ipv6" -> "IPv6" [Linda ] In the latest draft (07 version), it is already changed. Section 5.1.2: Please expand UNA (possibly in the terminology section) -- you probably mea= n "Unsolicited..", but this should be explicit. [Linda] in the latest draft (07 version), UNA is already listed under the T= erminology section. Thank you very much for the review and comments. Linda Thank you, Tina From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Matthew Lepinski Sent: Friday, February 14, 2014 2:52 AM To: secdir@ietf.org; iesg@ietf.org; draft-housley-pkix-oids.all@tools.ietf.org Subject: [secdir] SECDIR review of draft-housley-pkix-oids 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 working group chairs should treat these comments j= ust like any other last call comments. This document returns control of the PKIX object identifier arc to IANA. Th= at is, it establishes a new IANA registry for OIDs in the PKIX arc and popu= lates that registry with the existing OID assignments. Finally, the documen= t establishes expert review as the criteria for future additions to the reg= istry and includes guidance that for review. After reviewing the document, I agree with the author that this document in= troduces no new security concerns. I found no issues in the document and I believe it is ready for publication= . ------------------------------- Nits The author should consider including an expansion of the acronym SMI, which= is used frequently in the document. (I believe in this context SMI =3D Str= ucture of Management Information) In Section 3: s/be related to X.509 certificate/be related to X.509 certificates/ In Section 3.1: s/to points to this document/to point to this document/ --_000_4A95BA014132FF49AE685FAB4B9F17F645C84211dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tina,

 <= /p>

Please see the attached 0= 8 version for the changes to address your comments. Please let me know if t= hey are OK.

 <= /p>

Thanks, Linda<= /span>

 <= /p>

From: Linda Du= nbar
Sent: Friday, February 21, 2014 5:27 PM
To: Tina TSOU; secdir@ietf.org; iesg@ietf.org; draft-dunbar-armd-arp= -nd-scaling-practices@tools.ietf.org
Subject: RE: SECDIR early review of draft-dunbar-armd-arp-nd-scaling= -practices-07

 

Tina,

 <= /p>

Thank you very much for t= he review.

 <= /p>

Replies are inserted belo= w

 <= /p>

From: Tina TSO= U [mailto:Tina.Tsou.Zouting= @huawei.com]
Sent: Friday, February 14, 2014 9:08 PM
To: secdir@ietf.org; iesg@ietf.org; draft-dunbar-armd-arp-nd-scaling-practices@tools.ietf.org
Subject: SECDIR early review of draft-dunbar-armd-arp-nd-scaling-pra= ctices-07

 

Dear  all,

I have reviewed this document as part of the security directorate's ong= oing effort to for early review of WG drafts.  These comments were written primarily for the benefit of the security area directors.&nbs= p; Document editors and working group chairs should treat these comments ju= st like any other comments.

 

Section 1:

Please expand ToR upon first occurrence.

[Linda] ToR is already defined in the Terminology section. Is it still = necessary to expand?  

 

Section 2, page 3/4:

Could you please clarify the difference between "node" and &q= uot;end station"? Are they synonyms?

[Linda] Node can be switches/routers. “end station” doesn&#= 8217;t route or forward traffic. Packets are terminated by “end stati= on”.

 

 

 

Section 5.1.1:

 

Shouldn't it be possible to avoid ND load by proper setting of the Reac= hableTime variable? -- This wouldn't require any protocol changes.

 

[Linda] Do you mean changing the setting on GuestOS? The issue is that = many Guest OSs are out of network’s control. If Network can control Guest OS’s behavior, many things can be easier. <= /span>

 

 

Section 5.1.1:

 

Snooping ARP packets probably means increased load (a disadvantage you = didn't mention).

[Linda] yes, it increase the load, but in a controlled way. So the rout= ers can process them within its capacity. So, it is not really disadvantage.

 

Section 5.1.1:

 

When address resolution is needed to deliver a packet, some routers jus= t drop the packet when they engage in ARP (see http://tools.i= etf.org/html/rfc6274#section-4.2.3). The same is true for

IPv6 ND.

 

[Linda] correct. The behavior is described in the second paragraph of S= ection 5.1.2:

Solution: To prote= ct a router from being overburdened by resolving target MAC addresses, one = solution is for the router to limit the rate of resolving target MAC addres= ses for inbound traffic whose target is not in the router’s ARP/ND cache. When the rate is exceeded, the = incoming traffic whose target is not in the ARP/ND cache is dropped.

 

 

Section 8:

 

While this document does not introduce new issues itself, it should at = least mention how the same ARP/ND issues may be intentionally triggered by an attacker. For example, you may reference RFC 6583

 

[Linda] Sure. Will add in the new version.

 

* Nits

 

Section 4, page 4:

> There are no address

>    resolution issue in this design.

 

Replace "issue" with "issues"

[Linda] In the latest draft ( 07 version: https://datatracker.ietf.org/doc/draft-dunbar-armd-arp-nd-scaling-practices= /), it is already changed:

 

There is no address resol= ution issue in this design.

 

 

 

Section 5.1.1, page 5:

 

"Ipv6" -> "IPv6"

 

[Linda ] In the latest draft (07 version), it is already changed.

 

 

Section 5.1.2:

 

Please expand UNA (possibly in the terminology section) -- you probably= mean "Unsolicited..", but this should be explicit.

[Linda] in the latest draft (07 version), UNA is already listed under t= he Terminology section.

 

Thank you very much for the review and comments.

 

Linda

 

Thank you,

Tina

 

 

I have reviewed this document as part of t= he 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= working group chairs should treat these comments just like any other last = call comments.

 

This document returns control of the PKIX object identifie= r arc to IANA. That is, it establishes a new IANA registry for OIDs in the = PKIX arc and populates that registry with the existing OID assignments. Finally, the document establishes expert review as the c= riteria for future additions to the registry and includes gu= idance that for review.

 

After reviewing the document, I agree with the author that= this document introduces no new security concerns. =

 

I found no issues in the document and I believe it is read= y for publication.

 

-------------------------------

 

Nits

 

The author should consider including an expansion of the&n= bsp;acronym SMI, which is used frequently in the document. (I believe = in this context SMI =3D Structure of Management Information)

 

In Section 3:

s/be related to X.509 c= ertificate/be related to X.509 certificates/

 

In Section 3.1: 

s/to points to this doc= ument/to point to this document/

 

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645C84211dfweml701chmchi_-- --_004_4A95BA014132FF49AE685FAB4B9F17F645C84211dfweml701chmchi_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="draft-dunbar-armd-arp-nd-scaling-practices-08.docx" Content-Description: draft-dunbar-armd-arp-nd-scaling-practices-08.docx Content-Disposition: attachment; filename="draft-dunbar-armd-arp-nd-scaling-practices-08.docx"; size=78606; creation-date="Fri, 21 Feb 2014 23:13:25 GMT"; modification-date="Fri, 21 Feb 2014 23:30:48 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQB7lZep/AEAABwKAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 VsFu2zAMvQ/YPxi6DrbSHoZhiNPD2h23AsuwXRWJjoVakiExbfP3o63a25rUamrkEsAI+N7jeyTt 5dWjabJ78EE7W7KLYsEysNIpbbcl+7n+mn9iWUBhlWichZLtIbCr1ft3y/W+hZBRtQ0lqxHbz5wH WYMRoXAtWPqnct4IpEe/5a2Qd2IL/HKx+MilswgWc+ww2Gr5nQR4rSC7FR6/CUM8/MF5xSvn0DqE UBAcy77Euo66ZKJtGy0FknB+b9Uz0txVlZagnNwZoio6uNY7CSFQa6YpRugPHTQ/LkLuAjrz2zRc I5hb79pwMVvKCNrhgUcNYdBwDZXYNZjdPJI/MRIPTTit8yerC6rs3Qm1bqcYpq2dcKePaHR4GuYN CY3IRmg7OPTiqNid2YCnbGfnczAqI3RSRMB9c45hjbhJerDqTNsyIE9JoLz6DeG0mbNDgG4DFKic lvbZkrw4AtGlXxrrm6oCSZcnPZMm5F3exUHtVKf94AdApHF7Dcn/9zB5mgbkpITuhoG/fEWbJyqI wFP8Y9jxms2WEGFOSTtqnH+OD9Y93XyfP9K7Dnj/O19EDzPld09Zg1BnyTsCJ/krev+uxaaB2XEf Mf0JOiniATY/zrZ6/4AnhUTT5md/4EU6jb/b5/wbwhi+ECRVH1k53n/brf4AAAD//wMAUEsDBBQA BgAIAAAAIQCZVX4FBAEAAOECAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArJLPSsNAEMbvgu+wzL2Z tIqINOlFhN5E4gMMu9MkmP3D7lTbt3ctiAZq0oPHnfnmm9987HpzsIN655h67ypYFiUodtqb3rUV vDZPi3tQScgZGrzjCo6cYFNfX61feCDJQ6nrQ1LZxaUKOpHwgJh0x5ZS4QO73Nn5aEnyM7YYSL9R y7gqyzuMvz2gHnmqrakgbs0NqOYY8uZ5b7/b9Zofvd5bdnJmBfJB2Bk2ixAzW5Q+X6Maii1LBcbr 51xOSCEUGRvwPNHqcqK/r0XLQoaEUPvI0zxfiimg5eVA8xGNFT/pfPhoMEd0ynaK5vY/afQ+ibcz 8Zw030g4+pj1JwAAAP//AwBQSwMEFAAGAAgAAAAhAGHT0chIAgAAqgsAABwACAF3b3JkL19yZWxz L2RvY3VtZW50LnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArFZN j9MwEL0j8R+q3BM3BXYBbboXFmkPXKBoubr2pLEa25E9hfbfM01ImrKN90O+RJpJMn56M++Nb273 up79BueVNUWSZ/NkBkZYqcymSH6uvqYfk5lHbiSvrYEiOYBPbpdv39x8h5oj/eQr1fgZVTG+SCrE 5jNjXlSguc9sA4belNZpjhS6DWu42PINsMV8fsXcuEayPKs5u5dF4u4lnb86NHTy07VtWSoBX6zY aTB44QhWUSVXK7OlotxtAIey6HYeATIFWLZAayplPKTKlLb/+puVBORuj+AMrxN2GXH+Lipk4BJc j4DwtnGeEa+TAKJyhtRLOJ3fhqx9BkFEJcHjoabBG5rWxSEOrmP2AIw0FscA+kwIQr6IiWFidD3J TXLk6EhY4E7zK61g0vESU1/xKuVOS3o0qQO5E0fhsp7OZ051VEZLa3DF1/VosIZUiNOolJqdXoMj p+uZKJIhFQKRX8VsbGlptEYC7+JFCMCCXPqiKWolnPW2xExYzTo/PPrg9bnVsk4/Dwqru7IEgY+k NXoVApJP4Lhg/E+bsyAHtvoX+dqg8yxjQ5YpBB20nOht+U/0x860qSAlUTl5veq33CnXyZ72NyqP SvgXav5DzPb+gfUPQCS5jaZtlAySGhVJt0JPU9bFQcXlU4p71aRPdDVk5a4U+Xxx/cIGvo/ZQP+o e30m1LpPMSFME4fW1v60/SrU9b/1d7zRpY3SKewbutQpTNtdSXOYzo/rpL0HPnMHRuXzsvEPDsfO btjLvwAAAP//AwBQSwMEFAAGAAgAAAAhADOJvsqaYAAAdYgCABEAAAB3b3JkL2RvY3VtZW50Lnht bOx963LbWJLm/43Yd0BrYmfsXUoGwLvcZpvixaUe2+WVVTU7213RA5GQhDIJsAFQsnr+9GtsxO7L 9ZPsl+cC4noIUqBEu1gRJUskcC558p55Mn//h6/zmXZn+4HjuW+OjBP9SLPdiTd13Js3Rz9djo87 R1oQWu7Umnmu/ebowQ6O/tD7r//l9/enU2+ynNtuqGEINzi9w7e3Ybg4ffUqmNzacys48Ra2iy+v PX9uhfjTv3k1t/wvy8XxxJsvrNC5cmZO+PDK1PXWkRjGe3O09N1TMcTx3Jn4XuBdh/TKqXd97Uxs 8Y98wy8zL39zKJbMZnzl2zOswXODW2cRyNHm246GLd7KQe5Um7ibz+Rz94sys0196x7nMZ/xZd97 /nThexM7CPDpkH8ZjWjoqrkFAGmI6I0yS0jOKVcytxw3GoawI3X+0eGd4PBe8blf0VCrjQAWPeDS lTd9oH8X2v0pcHF68eZI1/WzRms4OpIffcJB63qzXR8169GHQ/vaWs5C+qbVbHeGXfnNJ/rI7Jt6 o8FmWHzy2QSfw4eZjSHvrNmbo4vx4NIJZ/bRq97vX2F2/gx70Oe/u94n3/Ou8f396cxyb/CmbQVh P3CsN0d/uz0efBTviucXziTs/f7uNLi1Fnb4sLA1Z/rm6C9fsRv9L2G7caRNPAAgcP4GcJlGS9dr 7OeR5p0GC+yDHgFp3L45mht6p0Vfd9oTQ280jZrRbrRq3abZrRm60al1daNZa9f1WrvTataMpllr tTrNWq3ZwOe1htHmH5rdbrPWpD+6rXbNqOv4zWjygdnnddM0a2bDrDVMU2ev40v82Wpienqx3ey2 Z3I1bMk6jUkf3zUw47Gh19u1FgY+ptXW2Gf1ers9MQ1MVeMT6A2Mzr7HQuqmWEmHJmCrazdMvmCj ZeIzbAinjX/q7br43GzjA2z47phgYHY6mJnBRTda+LXTwHONZvurjRPHEYS+98XWfvUcN6BDB0Sd 0PbpvO5OCcTajW9NHXAwdljelzdHIR3DxHNdexLS4b05miyD0JvHPp55kwCMMjqa12bX7OA8Orr+ Wn4KEL02Oq029kifx94GBs1svI+d1IyOjiOs4evQ/hpeeV99zPrmqEmwNM02jqrVbNKBtdpthmQx rIpQjKHXMAw+E759tOY2TRYsYkgXGLrZxhxsO/8Ux0SL6MbASQ7r3fpIP6s3zVH97eCtPgApjVpn 9a4+bOjd1vCfb8LXzY75uv/r+0ajUW/9jv13dv7Dj29/WX3ytv3OOHvXMgy9WX87HHSab9/Gf+cv bfaz+/rdYNx9/cexMW63Gu1mfOLr6BOaeKTTxJ26PuiMGu+G8d83m5I/3TE7r/8Xfpz+8MeWiSOM Txz/hD4HiuvvzLN6qzuod+O/85c2+9lpvv/Dp05r/PbXfwciGN237HUO6gf2CZ8Rk9J/ut5pDM/0 Rl2P/77ZlPxpTEzH/KHTaLz933/CaKaJ6fEdn/s/Y5/QC5h7aDTPus36uw7mXv3OR9vsZ6dxOnDw Y9T9GdMYzbbZxgB84rvYJzSqnNjEQhtiYvb7ZlPypzvd0/6vr/XT1386v3z78/CH2rDVeNcthvZZ vTHqDJqNrh38x82y9hDWJlPnP+6nNefrJLi1a8uvf53W/hpMb24fwGPBr2vB9P5376f2K9u9ii+w 03n9ut7pDE7ro+HbH8/Ohz+OaxdnfOJRB7zD5FvFbum/ut5+Wx+cnRn1+O/xAQ+/HyBwgMABAgcI fD8QMH73n2R8M9V14QUO2aqn1lXgzZah/XpmX4en+mvSHY+tmXPjntInr2Fg3zjusfhW/BV6Czx6 70zD29MTvbkIX9/azs1tKP7427HjTu2vp2bTaLV06NWv75xAGOent850artkQxn6qeVObj0fOvAX spiEQsptJ2b4wIji1pM02tbZcWRXCdPpFivCPm5DaZ092LOZd5+0r658bqptPkvY++RbkxD+g0C7 JmsPdlrucgdNE/JX2pEXCbOTlhv2PF8LJoA5zMH+xScN3hHt41CDm0ObAfq2NrVCS5uo5lCZtnwO mCXwyjxmjO1Bxd6kjcLzAM/LdOleWf6x5c+n+LE4dqfHYvvHCwnSY9VK23q9O+gTCmFMXfVkXa+b /a54spN4kuxzGuExLoIk2JmLQHzERi5wEfxgHLve5Y8D13OXc4GO0lUg8TwHSz6HVrgMNO9aC2+d QPtgz70n3pCvWN0lremckMy1w2N4ka5DDZ8EyytYyaE91UJPOx9djjXH1a6Xsxn8Fi5z5LkTuE8c WM/hra3BD0WsAj402ufZ4JPW7jB6YL92T/Zow8m9BprlYx+e/4WoWLoyxWnZEWC0kQtuats+PXVp BV+0secDAC8INC9rmhOygaygxnZNf8oxb3xvuQhOtI9eaANWVqh5gJgPpwN9rs2tB82aBZ42deCo cK7A0qNXV8ux0mcU7BFIyWMLX4M1gZ9k4duB7d/B85IHZ8ZHYlCG882ZMoZpARBfnflyTvgTOF+1 ueeGtwAqeCqB6MrWlgvwU3ta03x7McNk+A2cNoFZ4ArkpRv5hPHc0xEsID1Agn5IFAsho6AFj2Sq jTlKDTpyp2uHzAeNdvUgkCB2wiH2+qCFztw+0c4ZDTqutcB+Fr6DfRMdLoMVRnJSBYACwOPa9uGt twEp0LFjzQgweH4CPxeRJ4DKUA7Y59ILR4SbRNAY/QYHFpwcJXa8exarOIV8kF2CycxAIYQek6WP 7Ybpo4/GJF2jPWrqw/FR8WHnT5NG2gkABtSzJuRlBzME9SYgpcYn4Qa/v78/cezwmgU+6JdXhgMJ egV6hyISnIRfwz2i5l4c1El4aPAuTr17bVgEA4L8YFhv9/sbQ94hr6fnO9DKqgc6HLtY98ltOJ/t EaTzUTBPIN87ELz21wWApHluIQoS+JPRj6zWej2bDm4tohXx2yVzCF/ZkG9Cp8nq1OuoiTzr/iUs kPwtaedjtubosR4hUHaanay9O2qcDRVqfLSogrV/7v88GvYvR5r257fa0Ycj7c//Xfswung3Gv94 8aF/ucuNBfbC8sHSC8+l3mqaQ52pycJ4WsWpCMJckY122KsT3Fd/bncKipkKkMvmkjL3zB+LWm80 Q/vjcvawy3M4EEcRYUfEkU8bB1JhTC6PKJ+FVEytv7xBJPNALNtIwcokST6xVMGbC7DqIEhiYq9A zr/R6tpnexHa8ytY5zs8jIM02VKa7PBM1hLIWcfom6t0o4ybT6EUrfQtw6xiC4qpCsh/t/pXQ/sR ltuBaCKLajPb6juWKgeiKZQ1TfiD7w6ihjyyBUxLLSYPVJNnVHzvoqalDe3JgWoOVJP1HR5kTaGs aWt/tNyl5R98ZAdRs4p/UrDgQDSFRNPRxvaVf6Cag4KWyBo4UI0izPdG62ofLH9ye3CfHfzLiXSM g6ApFDSGrvWR4jM70MyBZg40Q8I28mIU04wBOXMwZw7mzMGcYck/JSjGRJaMa2tHY8tB2YE9Ssyo RDWgvVURWyugqF0G0A5HwQo9ZCKqh6N4dLz5QBWyTIjCY/40of/DURyOYv2thHVy/CArDrJiR6Gv A4M6MKjHM6iDYcHLlh202YQrS9xTKbyNp0hpjERiL0rOPRh6VPnuMSrt4TyOevvEqh5xHmGSLoqK WWx5te4xjo+iLG8i34qXudtcwdXtv2ntaJdhmrWmaLn7fmHPNGqPgbKCHe/AK7M3ePLYq4jfxS3X w90kJlmflgQiJacg4vXPs/C11t4l69ktB01cE/13/LdXEYhyXDU6o56pG9/hReodatVq5DqwXRQX 2D+2W0lc7nu88UblcbXW8zHjx9LLm+dbeqW3dvZOjlRCMRAu3+Et0f+BKh17FLxYR0IK7a96NWAH JlW0yAJ9Mj8LZJ9OqCpaqkRRe4YT2iNiKacew+kg1OKKfTtFLqiMiz3sPXVtL1H8c5HuJbJlodCB t3jwWeFb1IpEfdqECwdOsx2XPY089jmQXS3txeSlZuqJpcWK4NH1CGPYQDuAo0Jnf9gzVK93G62m UdDthXzeIa9ilYdl2YUX8D9W0PTSp0o4VGASxRG1BarsUvlSB0WOQ+faoWJ/AX2jWmtJOeKPUcwS FUFjLWM+O/PPS1ZwrVw/mW2cZOtWVzCmrEmpWcsQRZ5RurQIBFl49/ooVMdwmMpSskqg02eiSiHD Hw17IjzRD0iB0qxqXwQ5XkD3V1Q0pDKcrAZuEQyJYrY8KF5hl5B3hc//Emjv7RtUAC2aL+fMPq2K 916wVliocSur/g5Fp6xAe5Ea8RZ1A33Uvv6i+afUZsY/n6JH2D3qhKNTjv+AjjLckVYINHlACe75 gxxV1rzjoA97opZmSERr26t6mjMwSjewUbn8OlNWOVoi8Q0Ve3uZ2lvxs3LRT0/ROQeHCq729TVh GYpCEh5QgVxUSP02d7NYXuEwWSc2qvLKimVLijrRPs3Qb8sGU7lz7HvaLP6Q31LJUBTBRXXqB9Rf Zlz7QZvawQT1lG3twVv6gid9m4AhEQVmiurQKFtPMoqV3cYnC8FgkqDa103uXoORfFqw68fSqOT8 T7bwqhTJvigtnMCE3e+imGsWaBpcaLKS8ytSDry5XSi9SFr2R/p4xERNfjJgwWRoQolaqqCfjYRj vgIZtTsAI1KUhKbVdtr1VgO93SCAqJ9hlovnz2BRy4tCMGRH6aEBxauPysLMW66EVAFq81CoCGcX k78lKjjOO2KwnhboL3rn+J5LrUOhYyb3mousg1bzbDTIB6WEb6wPZPLxeJMHVgj+m+kfcWldoVMl JOIAVgQB64nJOtfKRRsMQ6ho7PvcA9Nb1JQuOrDY2Yh0FNLLlMNHNYwjNd4KJo5ziZr2rI+j6/k/ 9N3AoTlkP874lyPRo5O+v6UH419Gb04C6BPRgGfO1KGt3Z8Gf8NrrEGoacpPBmTHJT5b3w6UgLPO hCjwMalDZ8k+Jlnmss4PiFPU/uxpR8Yx7HVCq+iFnArdGTovWPLaLJYUWvBxjUarM+YdXyrUsXsG mim4aAA6XTLdKUE6MZuAOLVYFvMxWFfx9kL0UcFm15wPJwB6P4JsAXP81H83uhiNtb9cepN6U+/W db3b1v5cXEpBsai1JzAetIcD2V6HuUjj7hTFyAln3IY0H4Pvb5nmd4To5ol2aftzx/Vm3s1DGs/p SMMkUoONMY2EUD/Gjkvj+bZI3VEh9WaL2gzPG2mgbDbZAfW5CHyEuNsR6teTHkbgNUP3AkY78Obo LaQNBxoaXrFGOEM7QNu8pFolB9kPmuk+F800DzTDlcsnVBEZ8vYaJ9p76wGVyOtkgPVZAyLtMzw/ E7i+0qeyN+wdjagPqApZm/TkSGMJTCXlmvrGrRmOqk2JqiYaisnWmtJrQJ0xcxwTe4SxyEwp1rI3 0xE2U0haaTLebLIdKyTC4v3OMFaCOGN0hr3mCYzFVW9YIDCccAg3UEyl/+kCSKxdLX2Ehyna8t58 9b6uXXlLd0qFVdHLMa9N6x5huXnA8jy+XOdK7W8Fy3P3+eboEl0nA+0jAmsX3txyI29Z7jeTIPsx d5ehX+Wl985HS0/hItM5dCewSf3oM3hadPHFffQhPQh/glgfJ0Yjo9cXU69C2V+6LKqIoDaLm1lI 9YBaBWe0hZ6rCJ+yXpLodwtzIM2Q94h+6wf6PdCvpI+kNzxLjqAT5u3O/ebJ6Nd8PP3millqW0v9 WKkXM8IijsvEsIZuqtfXzmSPabjxXDTcTgNFMtJyzr8da5oHGew4uZS6BzSc9a1J1Mlq0AUymPUQ pobyELDI1IH7TUhkpLKk8XKPBG7zuYi1kwaKhPheEOtv0CxEaAUN5JGRLXwZyFxALhYUZtiBwf57 5FoHRM7THH9riJzPnZsn9ROJ1kV8J8PphZW2PhJE2frILv6aiUdKlpYZuiB5S7MWUPqsPfd9K+P1 csvluPhmnsRu0dGVm2zH+t1vjdLgSUT05sNyBpGB/CPtM7LnyFY5D4LlXsduni00b+h7jcAs0y1y TiWN79yEsm8iFY3p2r1WyufNUj2lRICT7Mc73PJArf25N7Vn+6yvP1uM/IC8MgPzyYPkbWjmy/mc IjB0SeLCJusS0ozlee8xsqLnyzPFHA3l3cv1eWA7VhW+X067kc7cAV7bk6XvhA+U9Y2LA+Luwj7j 9LPF0Q84/QwMWJozGQsuHWKUutCbo43vPPe6yN7uf+x/OzTwbFH2Aw18rzRg6HDQTL643v3Mnt7g mkr6BtA+paoaxrPFqXnZpPg9Bsmi9sIJ8n1qNhLEO5UCBvKyLmyWqIGwb9pTsD8hI+PZ4rt7jvu/ MQdglRoQcB/Y/9Hz57Bp7+xvgw6eLXR6oIPvVgsyThCGPUeRl2+KEp4t9sorFB+0ofvTJ3dK9nnZ rH/R+tMpirQEe62yPFvI8gkQ9KzRGhYUkpN6a7YkgfgmXi6CNEzljeVH3O9P+FNhycmFkc2y7nb/ FT0domDWm6OFdWPLFGqWSL3jWoG54PjBtqaIcwpLx4FDHrXt7OvwzVGjXqACbuscWkH8yvO+IADw BRk6fogJqRQZKznhWlTRga7Tm0290WrrZotno+e9YVDKe+qNrtEQmYl5b5g5b2COdvEcrCRido5G 8RuN/Dk6xW80c97APprFb7SSb0SlB5JvjNhhctiyXH8JktUX4tizX4ijz36Rgu5qqBRIVl+Iffg4 rPxqOtWp3jNE7i9sF453e/oJ1HXm29YXtvWwp6gokd0lw7rcUgmqQkZyhzEGlXy8FIO6GA8u7a8h P8tgYU0oDeH+9MqGGgXiwG1NOn3+J8SWJx6h2n343LrGnaboKfZX6iEGjzTMKb98gJprDm5Z4EoJ TS5vdqzItvwRKoYD98vPaiouLBWvAhW7rPjYKk4bwKBw0RuWfNpsygrqQ202Yf7BbF5MqpJZVZWn Ev6kXDpVyeEcOu0O9O6gTQREPOpApzzPpB9EFRmndPnqTwm4pzQf46w1QH0penOz8++B47U66vrE quPcfMZ8PP+lxupxOu4EYoNdVAlxzWxK11V8a0EX5Dz/y8yzplpw61yHxJYpgYEVzPU11EULl8gZ +xvLYyBoUfaNnyifFqAk5F+XDgwM8VZAtIVylzQqihe/wI073z7mf73kV99W191+/oDsZZ+yKmXJ zUBDIbvVAyHdCDzRhtEFOXoDk6E2Ft26oTuwqJl8+xAgxW0m1z1HntCtBS/VapzzT5olzaAaTUnP 2He4RIulEllGE+BJcUcAxeBKVINrD9rN/liS2UVMUCYP+ECAjADz8fQcB4krzT7hDpc/uB6ZOtUE WrErlIQLibMTB8cOmL7kr8y9OyAifl8dskBwVAn4wsuY4t60tsIRwtiJ5147N0teq5GTkSjUEqBi Cx/QdllNvDmlWC5QHO8KucFTlms5xf1VlNrSXuAa64P28/v+x+AloSsKvGHJ0GeuLcQQiA5zr5aB CkCGKdaEzGPveuSTysKtLRRenc2YwcE1q6qUmd6ld1FqbmjE1c6cjx2Ftxuk1CMrVdBhVZyTHQBH RVYJVN4bAhpBO8Wl3YnvBYEWHT2/ea8tPD9VGDEmUnh0qtmuy76pmwmVfOCkyqLnag6tRqPRXbkg 4jxqoI/6fcm9GI9qolic2WBCL9e83mNlvqrDR98D+zRNfhF1EbY1zHZ9bG6jGVymKIsViaoCEcBZ 0kPH6WNrXSYf7VJsKz1zVSchCloQm2fVpdPzxHdY7+qjgb7FmeTvcMoKAqcnrGpjKBSOauELWVMV hvC95TOlJj1jfIsVH+L5aDTq6OaJoY0gmHzItwwKbb7f3rUPl1cmPh7fxqiljxqDyk4qs+j4XFuD rPcC+eZQSUyutZKG8KE/0G7hXcSnk1vLvcnUIt4cWvm4l2LqMRlCzCfGoatgHP92CzU4jXVV7UTK zfT48SMaNFqNQXXowOSzar6t4dfjUj89dlWwWmkTSjViByhAiiiarFBjA15BiCm8D7vDitBBg5Y0 HHeIE9dQ5TLzVXVuS3LPMtUebSPsG3QdIXiqdrc1BuazC7LsYX6oZqyYxqjhSg2asD1BjyKY3rMH tn/lCkbN/pDrlVVwLaZ5H1u8ICHr/8KuBsF0E5cvYKJdPWh/grra6Or1X9QstWLdAbexcBUEIn5l cl773pzB6B9//7987bTof/z9/2WObXO07EkuK5uNkGtLdRYVbzezhTglC+Nji1396QMZ1sfvAadf 0rvZfLh80mF2nsCR9BzxXWxNP72aatiqD+L+1pncqiZMuau4STo2TbNeHWkq0WF7QKK1ju2r9rY1 phWgRpjs5JTSwp4Ekiv+EbnD5vbUsZgjVQWLrcFcBIs1HeiSXtDdoFUAuwJFl+xr5yvqt7gu2g5x P5wKEJ1mfXDW2sLW6MG1rBr4Sc6fq2OFBax24fhS7Xl7YP6bA/ud+z8zApBLr2RcRrDkmiaMMI1b lfgHYpQ5/eFpgwXtul5IPnyX5aVCDRGWNEcMC9/CsGVuOUYyZMVZSRsuCdxc/1n9DL78VceXuP8s kdzD/GeNQb05GjKE+9b8Z1LgPdJR2fuJ8iPDJc7EplZo92RgkucbmtmV4+Jo3OX8CscCLZnc9BQj gvERwkUOFCFNndsiUqtBG8OZ5d/YZJTgdxy6hi5szKUvgjoUEvJmS2qrpELfcdfsd5tb8IICpvjC ObGT6JOSEWLCJFyrXsVOdtw7/3TXoPv3TEHCHy3t43D7/oTbZE+wdk8U5nNyC1ZIoDJ3bNvsjjnN VWFbqG2FrdWMHswC2ARkF2RKfMZ3I9jN5ipu79a3lTKrUS2cEEX9FbTLzwcdDwNvQmWKEVYGt1dq gVvTQIkEkqo3uRP6yucoWXZGRSZDD5VrAyU8K94z49iS/ar2v71CQF461cgV7ygTsFPNPeg3ht1t ojv5p7omVhIn/a0dQ70yAcgdsMpUmGxD9UkcsoAAU59izG+9+gQ9gncycGZ3M4zCGqKJos747pxS f9lnDZasitVFb4gcQzywD2mIm/P6fFQjLQtCm4rEIwYTIGE0gHZMQvR65iF5hylNLCchsieZ70xF DbET2Uy49gL7JveesDjvC4aPpqmP69XpZMwDwnREZMwuJ0jKQCrFvTOFQIJ+GCUzQUHVlkgDUXLV Qb/VGm4TUewVFAGOb3x7sL5On1ZV2JMExoGWN0B3ApZoqlLVacRoGUqArDTNsvWcOZKos8HaOHpt L5mzNlRVO0riV8pWSqbLXTzWBiXopQSviG2lqScOta2JMp8dv07uOJei0Jp0NGSJ7uwuQcy5IBYj 1neQjgwNZTdttUWJuxHI57tr1CjJE/E4SnoNqHgucvDIxyByPClaZOM+szJbQRxQZURARnUaB6sa fJWBmJ4hjuVb76gnlYr06FWtn/v3yAXEHXexc2O5nkTV3C5R2+hb7zCfjoX/A1nFgWbPHLS3ZGbu 46HQI49WephKjip/I9xWp8DokqWDs0gkZayW6nzd4LqaXF+MVSUdXZuzqm9dG+99Ro493DpAT+YT oYpp8G7G+4zznGNk9sL9g5Rk0slDj5K+As14Rynphv6O54/ybOOV3hpaXyhR/UFo9ip02VrqF6BL Eb1LFCANvmJaYyw7m5AUn3HrXfbIsaGCX8V7iVtdxNQSRldQq0AM9K4o3wFWnmvfzJwbBz3an3J/ qrlG9Vbb3Mp6wo4WIBMyVlUTVH1YRL27mE91h5NZ3xGpq2YXzHdzSdtThii2tnELOAYUL3gxHdK0 OB87f/fh06sP74da4Hregtgey8lpNoxfmJl+vfQBeLolxMx1OgTyXkRlq4UpTRc4VODZ2mfXC0A/ 6pG39AIUQCjBBHBniftIUvpMrqmQMpFi8lfvNoejTiKPP2bKrHekfevyNx/UuOynOth+vX7W7mzh eurxe3CqsavmTVx7UM24/W6Cf/z9/6hGrnovxN7hiwMnWHj32ZSezTlc/ukrz3574SQuUz6pzViF ppAPpF3JvIIb8TFHVhrjqjr2SFtOTxDXILc+/nwoWkpc254yWdqDZs3R31UZMa54OzBdVMDbej/5 wFPCrmLeQ76XlY9EWjeZFWyOi5EePkPYRQU8Hdf/hhXGO9JzbbH0wLlxWRq3GsmMs0a3PtpCXBYc O12ltH2455Tw2hoB1Grvro8hzmz6g8bZoDrAjeErsL9ac9w4zsqF+LxbWwz5BzazrrTQDpjgDm69 e9yvXlevpOKdmyhGxZwguDnt0pUDOEYCzfxv5GqBSxcaBW5BTFBTJkPQOwTL4NNPyum2hgHCp0Qd J9olpQ0hYMkS4HB/nAd/sOckNxOfg6ySXlP4BpAjWZLItzaj8nGG3Xn3ptYDVMyoQkSaZcUPZ2to 5c9fyq0p5JlcRsysSn7D3JrCBiM2+1s1q1gXQvCBCWqpUCouPJMfbDSJUJLB1ojV+5jGl81FXD5y 2CGVP1Guemsx0VMWlokNGyKj7cPweAXT9G4lWpKrNfbeBrHpwlJPvyj3XrFSySqypDdX1VGSPKIc YxSPIYtG5CVGjDI9bRymFW8zawpUtUduDKxSp+felQN5J6qgDK3Q0gaoyg9XGpKkn3DHCKmqZqtY C6HjzY/r1zRKx2bnzzJStX8yNesKxV9SrjXkHVR1JGUKBKWcdom8BomHMZGTfPxbFzlyg4ldVwX9 S7oNwMs0TL3JkqWaaeTNhbJD2jFyZ5El41ChnVVWWLqxnAp1d84aKgJPLx5ntF3U7fJcgoZqb1sr Wj0E6NjFX3brF8kUzHHPvHmpLCVoovmUWrSunWBJivrLONYT65Bn9Dga3ZuitKwi4Kr8qyy0Koq5 RkVuEiDII9htS+ZCGeld2j5SKLyZd5PuyJutW8oq2eYe2qBhoKKujHkkE8aKD432IhT3VdBDlBhl ZUgRkUNNUrMR/XGxnOEDC3VJRQ1RmegnJ8nAqsD5yfmV4FQgG+SfUgWpyS3Zr5DbEiY8CSZBJGUA kEXQJ9mrWtONqf3huqqIWTj2cG3/A1VQIwBB8E9x99NlsUWeR7HAvS9Seaa40ke3alA9DkUN6UnU O0RRhmTkMxeIjU4bBfxKY5F4vCrI5i4pqQKURWyBjQUaQ2hdBbRo/IsHWU78BJfofNr4wkOp3Kg2 duETRtsUXCL2CBXWjsZogmh4beLVLIkHjA5K/fJCvHJB8frc7GssiGrrQKCg5m+9JRP3BdFJBsHK 3uFRqgXN4p4xlma2u+1Oyyys67yW15FN9uk0QYCxZNUsmlpXorgwQdjHqvKrQmPLHDrich0vSKld RHcXtU/isg8LkXfMVrLswQFZNkQWxVHkewT6Nze+fcPTRD/jEtvk9lTra+95HShRhhD5o+DV4v45 qT0pPEGIa9syjZCM1VVeLBBC+cUUD6hVGWoJx8wMPAycgHHaa/94fCH4nvg67J35DvrolecyJcdd 8RhZ3O1/phB0Y6qge9so0Gu5qMxr38GeKj1gyTXnE2NKcVdy1vwRkIvEbowzG7GmcYiTdwSaF5XI ITpmddxQhu+BX1pN0npqCQcqqYxKwt5wcIoCy/gv5rlKINYB2lVCu1+e03A9BeDnfrIS+syQhQW5 3OxzteZwlD0GAqF3V3eU+axuhAsuLIbguakruUq+KaVF/qA/f6C89ChfkccjqZ4HVQqUd9XBTm1c 919zlTJmN4W49FBehBSpMSh1hkg0Rzkskmy+AN0+kITPgsHMI8ZqxpSwAQ8GV7HBpdAWeqMfL3bJ VQincZgX3n2ktNLlrZiz83C2jzKmVWf7cacCgy5UsZSAj7Zzc3sFAu5PkesQOgHrLH0QHjsSHr2P w11SbPZYh04wQQgOVzBZ1n+nZRx8Gruj2c87PNx8FSF74p899HJxQi6ZD4S8G0JWXSn6vFPO/Zkr WQct/+jxzuy9cRX2npxvXHoLptuhA4/GPa3aC2sWeNoXlzJ5cM9alHYOmBv25cET87i4iUrV++mJ dL2fXBRpJNkA59u2et+AVxGXPolszFN8852HwVTH+fOHHVJz72feFA5h2QkKuqZuQVXhskue8Pd+ jiwm2/u8vELzlYSyJLxvUcwwX/26oJrYFPcm/wcvlx4vic9LZSAYjqdsFChgJfHT00haogTTwRn6 E/MKqSxcn36WL5cK6qe/iY+i8qewEfI3k4ykVYFLyYV817j0ZOBafA4fkFsnQlt7k9fUPcKS4kkA nWYHHbdZ+hBq/OW05zZS/bllKlSXJK3Sa9obePM50l6HgxQVyGnIc8VzE9YPVkALotmgBtc6rmel r0hlJ8JuuF2545brCsmTv5PPlJCJCCIBTG4KzlvaFBXrThJ9DOzEjmIJmAV+4Gy6tWRE2TSNRJok rvHOltNU/LUKIup3zXG7Ttio6LsblaFcW7iyIY5VvEErFHXmFBt9n8LL6NDYJYJEzfKLHDhRvkPR CNnH849dea5Jvpy3hDpQhlX4d+6olo6QcAmboGiFtMexoTcbUfPjnAnyF62+T7d21fmDJiFRBYol F1Ig1naNYlSRXabG7OQoMi1QvxfQ/Qh/KNoasG7KszRnT5Dqlmj85MZytOiy3OGS5WsidOjiEjC/ t5mUDVBocZfn2gnhCEDhJJQooz7QSVJKCYuh2aw3Tcl4c2ie6q9rhTfbyy7dm828e8r7CtB/BFVu 6BIcv3zA7x6IVFUh8VZXEMDCxN2DbN7fknUQs2FSpUTkk5+kEC4bKnkrqSQVk3h+psGqW2Z1M5GH mfsKO8fYK029W9cNnj0aO/fsofV4Bk+dREafdwfj/qWUqbrSCVfKGhbKVD+5otg35p5qVyynfAfs N0WNqhnQy7MDWctNQ9k2OwPtiEXE9LpiDaaMJFWiQf4AMdwgg1moEyU2V7zSHndQqvebAFGmfLMc nCATz5PI34OSB7YazXZ7VUw2Sx75Y9rX18TM7tCuBXcnvxB3i8FH7pB9ln+jh2ny7JUwBBeDowHX ElPMa4vzSu519/I/QtIs4HooJgWzZeI7Vyx3UFNe8I0f4+bXHvIP6ZcazgZ3IWL5D/wWhIUsRjhV WTcseNCZ5EQCOxWBj2qdvFoVVIuqnlAlSkav1JIH7NLSru17XoJSe7HqUv9S3r5IaN+4usLa3ySP CNaJ/22kP7986twRJW6JPlV3ls/SbIUOIdmV7G1EqaviMxXPOmvqLf1MoQjl4xdya5AwFYT+chIu C+0/YlLtcb0zll7CwlQuenLbpURiZFq00SyFFuyK1EfiTPfQuEkH4yVnWNMp1IZGhjB3noJfvaTU NvRPlEQRsPfKUJIYI5jTZKsb2nQ1m1rhIGmJViDreSRJ5lm5Wj7MkIuDZG80jzjVzlCHmdUZIWsM DIWrsPf2bCbqkiQ3E+Px7PjbelMfbYyJQPPHHjvsCpmguOoNJqofs+PAHNwLlZJSe3gcyKGxVidy CUyaW5QHF/uYYzHZU6KoBd9bIRgfQZveZLL0AbylT2oCUkRRzJglbcE8G2Y+VHtUzrbDD5FvSuTl 2pBdRchCuyzhQnSVA2y5Rol9qrWtG1qR5ZFPuPw2AyXtSp3tlWh6UAmgHgennmTqPDVIrDVqDkin KWpjc3Vk1ft05qGxNpnaSZkdYzalpUFyC3tI7J+X87nlP5yi6hPIOS7551TYKlgitQpFnongE4og l1y5RVbi9kUJckiCaAsgB5T8NdGouA7rVgLR8QooKVmTt7B9K/TAQ5BILjr1HEvcsNG2QXJuO3gl e5AhdiAxGv2MqBYW+hLiyo6cgiMTONBHL+qYpvEPOVYFyxv0QkLmwZOz+514VFh8IeYeMXm0S0Sb pP8i4YRhN+VjrwiPinB5KLTTfFbD9VAzVmNDxen6ptHuRkGRHN9c/iRA8qJRsxTfi5f2SL0mIRLz 6NQLfT0y5LLjSJoKMZi7CRFEFkekK9S45dyU95ZF/KdEJxTib/xpCYAESjRJM8uihJi8GCX88iug cg+fojIsOE9oyLhDiPYZWv/TBTNRl/4UajgoPN+1sP4km0/jmxOQXFWN4IwIt9ThlgQg+Z991IkQ j+AbubK1Ibt8/Cddr4z9AW3QkrEYuKOZekhtctEUAKyYuXUs5uJhdkg+nBNlXdY28ByMjbPm5o6m TcK1+SBJV8FiagPIREgKskpIbnLffOSxIUkahaHh5GIXQFe+ecAvqmJDlpqAOXwZsu2Wb/916eCZ YjzdgWAZ9OutUWQ+FcT5cl31grlx/rEqp9DSJW2Xp+A1PKSV4iFcEvFshJWPPcF2ckvQGLpYc1Vs Jx99BkhEWLoO6ZOwXlK8JZqaDIdkkDUrsjZkgoyiLG1hZ0LrkjXHZFOLy6ZoPRlht9nk+aCgu1QW rEgwBiSHoUJoXhJazuKKK/I0zHZ9vIrAxZIzz5p1o8lQRZEU8RjOqkgr+zyxXfjVvOJ7kWWOuyD/ 5N+ot7kKjZrduqEPiUgKioLkHw5xIc9HQxe64ghMtYnF5V2qiOnntA0xHQ/GTD07cHHNKkTjqjsU jkUwFRV0LLTW0CAXbPKIfegPpLq9g12UgYzi5ICgtGbBjScUWGDtyMnoh3OuWDkkSCSZZ5Z+Q9ij kheU2DqHKNyI8OepHl87bf55PxJSxXK1FG73iC2V4gcRS6Jx62fmuC/8wPnbQk1GdVnYdVw27EWH jUpPU4kLJI5hzjEkyENr0Q0ZKMK8f0B+Iij+Kbt3GMP7E+2cVZcimxL/sxhLzO6kFyW1iGHJF2pp aU0kRqKiVx1dkxYjqVDGaBnNLm+UVMBlsHpkQ6DY7oqY5ZJoI6ATrNLBJUoe9WGUokwsWQ923rxH ziI2Tv3vAFOhFwEGyGR5yABCrEKekVDJoJV51yG4JRXMpuiSG0AzpZse/HkVhNYjWtTuWDXM2l3n IzFDi2WwhOnyIPcOTRBljwk3aDsvCCOoyjZO4hYt3dDWzd4iwBQTmCKAKMRGgeq3I4H50Qvh+VcB Ugh6zhP7cMRAxKJPE7orAy7SlaMa4Ew3WnXeBSHsQcJle85KgUl8Jj5dwRFx99fCt4/J5QQsxclI WRej9fSaBFdX0kqJ2cnxzk6f5ZRSaRksgMwQoXqkbIOUzN4WLZNHtHtf5uMNYKlNJsyBWPm2H9+P /vL+/OO/pnwzicdjid7yceawiQE1oy6HPdxKRcshKo5B7RNwa7Uh/ZFowwe1XLgoiLutPBTsDMHs 4G+dU+wVXzJFipAr14iG3QlGAP+m403hAb2BnxP+Wm/JeFwa9+IYPmg1z0aDjbXETBICFluy+BhT kdbN2nsX7QBMOrWB/LlG7jRlvJSbKXktXHmYBSxA5jXUYOuD/CAwKRpLZwWO5PL0iISMJg8JrsZA Q7ilx7j8hEMaaiZyV5DvkdpwUvcZ62M4QDgDsUo8KY87i5wF+ykaMztAD1uAUo/8EC8IkZZxzbgR dv8ybjdQLJrC02BULGqmbq5Yj+2vYIGE7OUXWTBIFq8KwVwwgtQzHr0Uuo1A6JJUeihMQWkCt/aD hBsQSloO3CBAPxbUEnMtdPiEIp0KU1XBmHPs5+agUe/0GQIKxozAkLrGZ7dbF54FPAp8ZMXpEgU6 u42mvEciR3u0ktEjjktwZcXYI5lYdFzELtZKxF5NO1cNkMi/SjOuBIKtnSof6+5aSdIiywEFiUBf kacQ0oKJg9Q689kmE3E5jHPt8nrMmxWkLw/mz5LPnNfOkQ8C1qYT3a6QJxKQaOQsVCpdSSLSXrBc G+YEC1n5KG5RBJGwZMo1wYu8HeymcApuiVOLn2/+6pT3jIOXiCJOLHiBlTw+qYTnuBDyp6aaGMpx 47wVvJt5lpUqqHihMhHClGpF4WMu1a6c4yl83izLnVibhVQgsAwHced1Cjsfmw9TGLQvRen5IE6C V3JYqV4CzQEqKg1spHLMY9+IWOlCAnXdauRzMSMtSTg7MNLknBmRv3FmSCyl64Ia7dIJUl4nxC/j WNKZckVdE1jUg1u4+WouSUrSoVN2jTyHimEaM8Aeb4JEbCQD0wLfSzL7SsWUjEG7024IlVDYDrwB BVw30hPL4kyFOZNlF0W8V5wT8cui4ClLy2bsSHRRVtJit9UwjHRBffEhI+VNaDGBA8k7/RdqEhIP 04zPcNwX1E8dzTM4kzvVflojI+Lw6TmuCj9y4dts10dN4QkpA1+lZcQKix+z3ngi2wbWLWgVOf2w glipWyGpBQKF3sSDjaRssz5o1bt99Qo5UjMlb9WdLiU+WDHGmPxI8Q7lvgoA85liuqyHFxwuIAcU 7w6E6xXWOlQyi6x21ZHEJXH+JImc/6KhsmTb+9M5uk+FDvxixx9/GhZatyR1EiikpNAYaRRwKyRA kfPuEuo2WISlxMfh2By0uAUR9lA+dIQ3qEpbvds2inZK612/il8owP5IwJPF8LhVpBAQkbQltHQI PcQOfIcrrVObLk6wqBKch8gHRxzURoIrXTq26C7Ll/Q1lh0JOaFLxLjeRoH9btWBfTNdHUEE9lNX 5OKuOTN9z0+kmK11z20Wze7l6yRxcXgND+wVmibjWouPxBdnkkKkrKKI7RZc/cOuKiqsYAyMzll0 KX0H6qJCSFcUBO+xeDdyjcxX7+saAzGSVTURHoKtYCOmA9bLc1MZy0+BPtK/iJNsez0ETBlRcbvQ +7ROl1cASs1zEgk5pQ1CUpcRL0QW80zEA5WzJM2K0rNQDIqYJgcOs9FI/PHAhHLC9VJwHTNeu+Qe RxEWe+XxPu5oJWcthDj/NtBuvRnfxAKc1+Z8OUQaxA3C0/DWijeFx49UmXh49z36/fG71exuisTK OdIchMOTO2TYVTjqD5ccDm0BXHhwZDVrSwudue0tEdQLMA2/1UgHGVvGAgFB9i3De4QEeWoyzhsR QObJYAdCrRn5hgKsmb7CvzipkGoohNl4NEthE/xMHiFT6pKh0yusjdXMu1pSDs8qqJrUIXIFVqNh UMefXANTfqhW08WRxwTWYzyFcs6sJpWvlq3iOSr+otol4wFouKJ8v9UYDCKOXZoSSRdlaoVq7PGg MT6LkvtKj63O9Ghst2DBv1XLXQvK/HO69r25kvdsueIrm9m9yD+4YvnD3Fuxgw1wBkOTcWqNZ0zZ sK5UU6494h61T47f8QDnUA245SE8bpH5B7tOImy5VIGJ4OwzZ47cIZoGMUimtquPgvk6UmqfaFUg Tk4F2fVH5Sg9tFtut4x0Xr80BiRIKtsnWaLa5rbLhKRUDZvwfCGpX/XstktgcdlipwGpfOshxdTX CKcguu2vEyQT2lOe7oSiYB66MILWudmQxJ+VMkUjVAiStevOJ0GuQZGCMPW9xeL57jY9peAfQwVT odeW+ZfQ6opGzaokvH+f8LAhfaTozXI4CQUd1ZCKxsjOXoQMcFvCD5yfyVI0Oq1wfSxtQdeNWbhM WUA0u1R0egF2QhuSGTRkCa24FSnwgeuhFDSIqVQG37Cpj9ssA2ijbGoo5uG9TbeMCNSwMpA6WgSS 7C7yAb5KMxE5yoIcKasEURSRWAK9hGf+I+JC2Y7cPoGJzFLEKI1I3NdhCScW2TMsk4PWiYxtmNLI gXYnsD+oZdnM+WLPnFvPwz0U3hE1aVaJJSBJiTExcKnzT8eU/kbpebguSYkMEKqRnQ4nN4p++BZS Z3jT2VQeQyFNMMw+MwfNgQh3kN+w1TH1X8h9xoJL7RODTv7OgT0K6/d6idg4d6YuZPApjh1JmyXm DWYoup1am1x+rh2kMlylTbLPdhCxQxbgQcRCXhCAVirtaZaWsFygwyuwh6iNHivC/MyhXvRLPCqh VJZu0tMDR0qmrGVneGTyQ3bAfFLXWPIC0qpU4CjlRHngCYRF45RdEGOaOFFUbn/18fOrj31OvTyz IgiZ7ycQBTrAcm3SbhgjFuHIovkJA5pj3TyTUUxkZXj3qqeHo4Y5NAUTKOSp6XELwKyaaD14FSK8 3Pwpp6ZqNfFt52+mgNjKYzutOT7NI3E9PVz+qpUY3u7r/b5MeVTzhvjCC2YCgIRd5ri4mG8xkRZV qSoCflkKWWMorBNdJuj0UVKr7DrR/zKx1e9SSBUln5AmuKqWRDqgzOVMAiWlDcRZATRMK537lggx iIcfK6WiMcserJTAPGFcSN7lAho6175IQaMUmsgxLN33K4CwrxPYEQNEZh0bpwStUf6+pSMQ0QXE D+ieIzgLxRGKIEeccBxjAAX8abpkI3EeFYVRCEmZJ6Jo9My5FATqUwzqu6T7TVKnWGiU++QjnVZ4 YaC9PBbaYDTWHAHhkOymTO6UpFWyTuPZUjL2wtNbUDqGUaR8GiFISqenAlQC43jUU0Z6mOs7aVCx PAMZz0rwOyiXxA0ltgnrjpGoHE9UvZK3AO2vDpL9sWLS8SnIx+7ikYJ3Z6eQK8Y2CPlFHJoD+1xc VaIKy0iqZhyJJwDS2OxvHl6COBQTSXAkDuW7ROB0MlhixymoIqA2Hp8JTbgwOb0se5A3UqG1qyYd DgyzK2rv5vOx4nhR2aXcokMnnCaUPjbhfnjmaqagKIU9SZAl8LTsepnoZkglw/nkwi96u+xqQQru MaMNWhhQGDfoue9F0Bb8dTN2WYM7ZBbQyNmNHy249ZaIPsN3g/tCAdwWwPMUIT0Zkm+U+1N5UQ8z XX1b5P6IHCOZPZPI/UlXpBK5P83UnYbMMfrlK5FQLaFzXBxGdTtWqiKI3cNBOnPa+pTLHMHlwbPB sa+iJB924/DJjvcpHeaXECtcZCk5SVuvdwcyGXBClPBoSgQloS5x0TAkibbN/2EuVchPRagpg2gF epgW3jtga8w1ShI4XnSDVPJ4No30rDCmBQduunaKmlfDEmnom/uuWRYiVdSGklEEy+xmqce6FsCx K86+6E06hbjkyhciTG9RDZHAHu6GUjrZS04rdR1KyeZVe3Lv20Gpo8ICtustbwqLc2RhlL/XFMtP SfmE7kSkde34UMOA51AWVRBKJv+VTvcoPPJS5NOTaF20srJASZCFIAMKYXBGfNzH707oKANha2m9 FxYX0S+9zqKNErhKKEtuIbyzK+hxBiR9FkSfRHQpLyJnvaplxWknHyU1YR3wsaJ8MeiGIrmP5iV6 Y19VYp5qL5onBiI47M7my9fccCGWgusRxbd+SyFlwR5VIEpQ3Z7SWv62GAEWbS0HpwoxSFBYWHh1 qBTse4U8KruW/A1RqJbKNkaeOoH2kS9X8oSzQlKilcaRvpcwfqXRDe7y/9m71t02ciz9KoUsMJMA lqPSXVm0sLZkJ+5O0oadnl5sI2iUJdnWRJYEXZy4f82D7AL7LPso8yT7nUOyRLJIVkmWnPQgwACd sapY5OG5XzV8l18N4ra27pO7+5hckH96hWbYTz+seGPv5NENQvoHabIA90Jfj7aQpA/th/5VgcML neLSvp0+bCbw64Tqxh9O9/UtURQJYbNRRgFH0X1r7WU7RuZH6MuNWrlaVlG0RxOdPflq/4bKxhiV ddoVBg/xPJW24gUVXScU1XZFuljc2BXkOcadSNUytMkCn1sXvvkWKorSWa+kU5FAVNf40v4xQZnR hrWvNZNWTXhChUFao2H1uKpX2pRTb+KS29Li6kr3j8hUUvWgsMAMyGuGQfaOO0nqV/K9RAi95QZl Hs0VtgQpKbj1X5K72b8Lfu37omOb4awbQW7mDRUgCt/3bRLuvJl+RmbFHB45tBBTadChtxvHcbfb KpJtUGCb3CKo6Nfc7GY+HCdfvGhB5823OYj7Fd1FxypplL0jUK7MgQ2OXUA3o8kgkI+hVQvBh9V9 UQtJu1x+npaoZ2hoXeOGchKB87n52u6ndgXI1RUlzBD/nFZmYu/+WaEsR3c6ZyU/22/H9oqn23Kg X1rF021ZNgJS3F1zkta8TtJdO3MhUmhQhNTtKUeRqnJx02rWg4Vpjs36jyEnf/sVmc08z24GYNLC /jHQfxqPe/OMezwjzbMP8MJzPpzcj+bTCXMM1rvG+EXxDyqgg9KPyk6Zp0ohFCqfgyd3iiFzqLqk WgxOAr7kOVo8Rutv715E75IJ+gDxQpcPSOe5e76AGfSBslgR1KHew2oh5CIuRuBOXK/BrqQMBsCk FFGY69ENSrYHhBLCFkQQEht8SXEdOcjryfWhwBV0tEQXruG7G8IXOpiOpzeU+LfAqeCm5N7zOKLU HSX2X4/RlGUlMvdIqovusmKkBYfX5AWqvg4FeJ/k8Up+F05j9Z9w4xyT4hkA+QLpV8peZvNRjQoC llLlxmA4RhU//gGsoGFU+Jdo4oswASEtvGIiNbbPedDEY1TUHmi2mgG8FOkDqVj8JgUESfKTdq2Z 6h5J1KPU6S4TVeit/GOJ/HBQJW5fNFCVmE1Jm9RBmLsSINYFI/wWaiWAgJaFaGEwWY4fDrmd5fAL lL8xwveUwIDHRB8D5BBQeRkmdIliOYYWeSm56IzJF+2ZRd6B8OOKpHK4FfEOQlQYbZz05yDXKK7j XzQKIeXMFEUdyyT0OwHOEBgKqEFM86E1dFB2xK2FHtc/2fEGszI6qUlXmpKvPakoKqtQF5ES7jU5 G8P9+ns50w1IrXjs88v3784zxYfQiwqmUmuHEWkgYCtw7NrDsd0LQleworr2cu5zMIFiyRnEPNyF Dy9Q8kEa3WgBTw4llyT3yWisplvhQVLyJH1CLaBQPgohSMagjl4gAMzh1IiAOCNBQ07xiAYUgi9c U5OASNliQuJIpkCEsHiY9G8hDdG2OEj6Oiq5j4Zvo31oCB117HWvAfgjirUU/IBks3bfC5apfADM 6kVvO3owC45vSRi6D7mJ+Z4PsqPBAGGnKTXe5DZAUlch7o57pygxJOnZyYdT9B88vLGgs8msWhvB 0ZV+l/TSOYje/21aRf7VReUSg3iW/cMXhKDoDgDP2PRu5rpskMS1kmuWCs1RB2Es4Ska2Ohla4V5 mInd+1d1v76xpTWm/v3DtF+VWTDSClLGiOEX05pT8ysyC+ZJbBGJAz4mlLnoAvbP51fjBCbA51co P1seLUbJD8/+uC113xP7BwbIFWjC1/TLwy4/rC3u5iMpU8/EjNW9aBattwlkhZtAOnH5tFWNe+sB VztQnpc0CDwuV5o+QBGT6cXNuLlNI3C5trfRWOb6PQYjFL9hf3QtDHGuciYO9AXdsKRHM8NFDS05 rscnJ8FZFqm8ljtW8b4EnYGhAJPFqbQC/6eKnuYSMhKOKwowrK7GPPYJtiT4ZvrxSRS3W01hMMjx 28xYQU3y4MHr0vIvO5x8TiZegTd2pkIWhcRgOBtPH8jOUWfnZAE6JlMvXQObDyaft5VVMeFJ6Iw3 vnMW3ZOcQcS2MHqziWk/088TvccG2f5Xw9tkDGtGz5FWxY7bhMY0Ym52y/X60TN5HXZPrrk46G/W QUEQOXq2eA/A/f1CdVsttMZatRYrfExd/dCQo+XDDI4YW0lP6a8o2IM3HCqI5T25+fE///HfKSr9 8x//E/xEpVuOj6QX372amOZhQSw9J/HJLbfpQ/L8G1UEW+jjaCt0Ye3e/YX1fW+0vhtq0jgnxTHv 45hMcceKi8OQywVth8tPi3xit8cjBEvTTsgPOB8y1yD2LtNP2J/IY5IWzESkeyNvr5B54/H28Pg6 t83DmHD00QR8+449h9Y5DYrRR+548AfGEvUyyE2yyccQr7lRhHxsxXStfHaniEbBi/1++NlSQT0n CgFEc+ht88V19NIWDwbYtYDYVl+BorLPQ9Ta5SqEjNaemmJuQxAXURVhQujrGk5tdThoe6HlH3lD W+BE96jZPW1wgHmrAykl+V/rVKJtB9INnv5YYEk2ebklqY97PxKHKMl3ax1Ol+mP3YfXsCOO+ki0 9RDKlRyRsVj1b6F9sliATSTjEZSzIRXS6BruAYRerkZj6pusmu2MkwfwaoyIn86XC0ryQOAQjWw+ hbBIc7VuRYDB/LH9gOmS+kWjBHOIOrkreKkR8+ojCoV+O6qZdvDuHokY7rvzW85FBLDPNWBcnNNr ctStHXfXTS01Q+skrvUa6Rxct6HlPgtntRiftoxS+VFhMSH95Zz9FQR8+62AAYNhSm00L0qdH/ar Oi3nGzDZqsvAp8HQ4F/hsLAinRNI3zl8zIhy33BQnYhHNK+SfwFBCbqksV7IQ6LgHJDv/PxcvWOn ClpQO23VWsey4MsNeAOUAj5rRYE7w4AriM1TMIWUBnSi8dnrIYDKvSgYC0O2Vq+2G6qgFh/AwFCi M07bYo8Og412JMsgkN9wTSEgrg7j8iMKB5NHiUuxRdhTgBPLJaLvmpakIHoABk8tY/b0+XWfBryh Zs+R7eXM2zQVYiftSKwygSDHQ6g/agRlPs4E1T0uVxpiHq/0XBxPl0s0YIVbjXoA+a4g6zjokEk1 nN9Fwq63XxSktovqO6ZVl8MgQC9k+Ng7UgByHCWt0rPfCXxik/Vplu0cYpGSmZA5Co8NYvTc/Bmk gIkCg+mc01Zegjy19BtrSlyGOtn9HNqiuUcnSsWtehUTHhRwNOwxTbgMO1ZvZMHpZhWbhPXkpgJH OwWkqPMAImGAn3lOC046k3BvDUkUqAoMLqI7rVE4SUkXQoaQxyF1Cj+nYivhN66+sHFJAYzEq9yT +lNRGIrmJQUWZsh1PLlEaetSaM60dRo+qmMdMzlvlT0rk9q8lw6C8uConE4zWiwwc1twV9IFwVgL cDU/CppgyqCgOCUHb2VlPgLkXJaP7RTVIZcYyZMxMQOYJ8XZXCV953pVNH11mS2uCn2JnO1aEpF+ SSEcyKceGqkNX/Ec+TscHIdnHxdHkul2OJ5FvW6YFqrN066SulOMsk2W4F+P3NF6M8GF9E877k0R FCFpATDgwGAihT/YCD4pGGngPsMat9R+BU5/gHCFXH29GgUN6nq1Wa8Lae5RyNELFAlehEhCCxuA XY7pzpDyFnbBa2sHcvo6Lh1avwXjWFKDdnTRENX1cndQvGgew2e5Z+ych1AtCEFFuiO4btG76Jgc yBIO+vbcwsEkBbcMFVipjm1wc/VHTbDGxuPM1eSf6PK/elJD1R7rIzMUZIic1Ubb8O4vfnjm97x2 3qFhLSKr8ABcygDuGUsK6w6zcXnsxTdZx4SiPjDO/MUDX3kCzDYDbcg5t/Fprd3s6W5jum7ZfSRA 2OvjcdiDzInnZ6/fnb9897b3wsQfC/102eBGP5cmK3hEqrRGGKiGUkdKeluOLJAajmaNpJeYK8Aq ZxpSF7L7kD0StdAqqJGLpQmx7NRrmTlgYncfyeKCLsC2WNqzMSKw3Fde3ldFV2cCFQcpkLtNCd9s l6nWLfwqovPjFXL8xIvsIeJ/Vne1UzfYP4qxKdoZcJf3lfWuZV0NJsJAFUTYWbbe6lErZZkaj8YP 1EaIzggcGwyh9FOCIjkQVHtj0Vj5pejfRexN2MzEr2WqgyU0nPzH1NQvcvmPofLb9CHMQjdULBhQ Ep3fziIZ3G7F5RPZANq9JM5sI1uA0q6oazZ6NyVowY/0PQ1OjDpQaMnu7nUPo5Nr/IhIFXtA7C8o pkxbzCdBhy0pcNzbwss+ekcyA9QnzZBiQkMr5pheRJjxG2Fzyd5gAAS4g5J6+yNDYIB8CJRdDJM7 7vCQZq5DbnJ6LDxGQEOFUESRyHiUO9JQeg+YdlSJm21u+0S92G39PSTpZKmoXitFw4ikMBAsWYkL 9uvjSmmab9UeMCcz8qwiIOMVu5WVlHdy+m/KQQ2yClzQOa4W0o54n6auUEMEoKd90TomhshYINzP 8BnDZQ6fFQoabI1bgeMETrYUGJ5mVmtQ0sLGINbQLtRuNWXGfNy+4o2BB8UXxiQZlAtoqvMEKdqY swE6hqNktWBWKmEA1ycl9GpQFvUwKqSQ/v4czDS5n45EvJLLOohviKdRz6QefMHCZTjh7PI0UiGy gnkTpc+fVnewl0uD/nS2KI2rpXvMUxARjVK5jCoT2mrpLkEqEnaa3JUGq+VSPn3/BXmSeIpKni7O 3r4Vkuzk5KRVrhzGyW30/F3SL40mJfwHOwEAhC+X4iecbUbxArp7ud01cr0VMZQ9kO+O71ZhrwK4 lxgylGarm0XC/Z1bKg0gcYBaoL8qmQxYsqeX/s5euRGJWpXwzxkjonWhj1Aze/MYXsKJMrwK18K2 2nEDupSiq6KLY4ptgtIeyELM6WYlS3c2S/UDf4e4UW39H3seAphvDRJ3W57EfQe+DxWFj6gEZL99 pLDuZHBDTVARqA6eo3xSa9Vku8zcztHy4U2vz7uB7Pk60BnBre4YkRXpK/1yOOknMwwDYRfUSwto kP45GYj+bXcGiOumKxdaGFKHpLNm32QP49YAkaZJXXKtr6SSg5ArtzGYe2UoOgMYFb6Vi26QythQ VARzRmWUwnJKp7T4Vqd9f2PI5IbSuoJe2l8bnCjYQGBb6uApqOBuvn1k762jOiD6XrEvww0JOFjX E1J8S2W/7l7s25fHp6QYST1oQLWqsn6YjXD25yNXSWXEI5gMEQBbV/8blc2enWvEoBXNQkShvIiM eshAs8d1JqBq6zZUpMWp8gkGCC+X4+Fk2P+EYdvMBV/LnHDfBdl33SGm73u46G2iVp3UdzBVqnEl PTQzanAho3sElNntwwIOr7ECDbQ7+AUA77NzoWb69mNv3o1bIWFc9EQK5kOSi0qi0NVLI1rDiG8f ld+kVgONClYpdjmivn1Sq5VVP1t2NonBXKG7ke/4Raf7wjbhZar4Hy4OzLdE3SndNhAPpHT3ytjb LpxBYR1fmuhIZBAm92h8jzrKV/fJGIgq5D1+OyODk/9WU5PQ5Rua/3RTkP0CXsMk1UcwbzYjkoMj Js0zJGpEWhU70uqHlSdH0a8ImTc0wYJdqjSh2sAITf1iThJX6+1TzlVddsykkwKvbXpj3q1kWRLz 5EX0fHSIQQSyb8eLA+H+JbkB7g/Vje8cHryrBdKcVCUr+61T7UuUgZC5fD8SPUPgdDGlTeikcbVc qYfbxT33ve84FVcQK/n0b7E4BbgQCtfECWbodTL6QkOB06dojhCpqeSNl+lb6YHV474t0B3nH0FW C38tEnH2Qtrav2c3kZf+PVk+q3xghn9P60SnVdzGkn+lhkbmPkNhz8vVHVxBKHmExmhmthRwy1UF 51Sb1Rx2NeXh3K9bTjIv3btaryl4CE6fX9VbhLdLx03+Ymjc75acsknO3TRl/fDpk5AnswVOwbQr JCLIIzAOsxEpiU5Ex+CQJf6htBxW3VYsOkKUVT2tx2Vup+WeJPr4w2H/vg1ksPHxXxMC4Eaqz5Lr fi2u8GfAvbOJnn4Dpo22IaT7Q+qqVoSI8cE5TR4CUT1LUVhk1a6xlqKbC2YWUOVgXRLqrnEWSozK wFrA+qJkLJIDwlWdDO4TxHRvWDRgzABa9ml/uYKfUuuwA20pXXabglcD35TkL+zn/xMxFFwqX4Io FSYlUwGeLdwsX+FJF6hYIEaCiBouEQYtjdtdsn4yGXDW5hc0ZuGMznSwDOel4Q2Ru8I2L1+S+AMP y4HlZeaR4fLnw1cmU9iFlh9Ord9Ul61yKgj2ldoFhZmTJjTYWVhU2NBglwtupcmXF2xy+YQs1bwp W/s+rjV660oHg8I2PbxbOKpunvaJd7M6mBMDW8sN1Xop2d9UPIN0Uq1woDBmeDUAoRSnqaVgtUSL 6AQ5peAHTE9q+kaCPogU1DwZpd3cjpVaHHygQCM860h658EciKuRZ4d0OlgQ7Hzqo6vOfIjVFzSX e7FcDR7I6kRqKRG+SAKWHXQsKfrkiGDi4S44xm79ArvhGArFHkVJnS6xbjiJQgis5a1sgsCdiW/R R23ZTfzAxXWvMySL+j7NRmK9eYpKnt0AMNxYbw8npVTVBdo08gx6OFFDJ93y5twgXjdS833yUaft SP8WslkpPQSqI3W39X3qEYzVnwP7qP27gWZeTxFepKmZXVFZIBHVTif5kygqPZFk7bvIvcPcEj/1 eqVWF0O5N2Fm7tulohvzhrWvPepkVEdtg2w3isxLn56k+CGRlinwLh51FDfozrkacT9HBCeZDJJ5 Tjrm/s9ImVWUEQs9iVQyfxBJwxqCfn4ePhQ2VRJhFzXYINWvtXda6aK+jRBpibQGvfrhq5UugNmb RQlOJikdu+owBkKqP2qc03z82+GcHr9eOkFDtXRLFfzlbZqduk63hk4+QAfnOeX9Ukdiqg7RhrSK 3sdknlPSl5nwaunmTliHCMMBa/NxD6wL81raEdnBT7azDT3yINWiZro6yudXyrlteOK1IS/kia/U y7VGGzMeTH+48Yo9zkAk58YyfuD8ijXOIK63yq1mo2x53Y2vWH0841al2W60WvIVf4igMGCI+3AX COp+oXCf87ZsfU8dSYsKWO1EtV84rdmJN1IPLoa8sTAPiElKFUsebH6KjsMo6NS6e16O7i5XE3Fj +X79HISwmqFKhKirUITavcH7NJ3g0dvzOh3Ygcv5vOh81F+xWxdxRcxTJ9tfeX+FrxZsh9Is8X+s XsMip0CNjBbzL9FHnhwMFKKEm1c5f01fIT2g8bBwjNfMsb94elBJ68UnhPe5oQ6pG5aeEaiSRe0N MIrKBBDswr+SFZw48x+evW1WwYnoL9BXhj88q5TjWqlcKVXiD3HzVbX8qlz+L9YgUkZAKsvxaaXe lK0UBH/cBTp2DqOffaDc41cBxGDF934O69aTI1FTLJp2S7UA3nqlxFOwX08DMaAFfoNbJhahXTbX hBS77Er7KS/bc35STBv1VtVsCrQ+WoqG+6Qt996KKFNSmjiZt/qjrrgavilWpp5CHn1FIJIpgym5 YmyWgb6WVaTlduxKIJMiAj94Ajf236c2ySvdQ9eNanp51OvpMerWTHVtrY7gUTMFnO3qduPkuC3Y 5+7YpBs7ZR8DkgohsLaPK0eqCc7uttTRjN2AEErxbn/AgQwBiqnwRoppskcGoicYH0NdP5BjrRpm qDiKtJBFZHP7fu3rAp3N1EWvPhZdr9DIlfMgOZ4qFKgFZEQRjmTaa6aO5OBI5uNh8+7RMl9pyPRf VsDVhhg/AiFE9ZzGSgttfFvrb2cndRuHNTuzS1p6Nk/Zp8zrnB2hPdmm5pllvmr8kO3HJ7vYXYkI hZGaMNor0IWtJa0sbjTL3dpkH2ekwyDNTiT6cuke3VEB95lJC7uh+W+VdKwMx0q13aq2oECagtqQ 6rYrRr7CCYgeArVcMZVKuxK3Gu3QK5YrRm3McmgYG7NcMeqVQAE3/EfghZPkDqYbu5XkWQI5ofAw uF5pB9xKiKA4XwkAua6rTuTvEhsLQaxucUH1SgBidffttwMQQ88g51lCELNuHxZzu1qO49DxrduX XrXg8e3bFx5CwN5XyG5tec18RcrBGpXXv9QsjNV+scCs/WJBU/vFu4Oad6iM7fFcr6ZcX0oT137x wgBo5oEOsMn3ixcGwA1Tid8j7w9lWB/1P02mn8dUnsTeN0uhdwDI7wzdhyz4k0pbt+H0K0o/kWtK jkfYdwruQSMq7jZbJ6fER4LZ0Y/WGr0mwdHFu17062tOl7WQY/71dkXeyOvpeDz9TDbUbDilGh3p psT8P1RJrbgocjSZreBZB8CXt7DH2dVsJX5q+hfbAo1a71jMTdoV7nlh++N0mKnIhpu7YEH5/nbb +TEZ3tyM7S5X7q2Bd1qsbH8bc5NVZvxmipi8kyf0jPSoZsyiEjfUWBlzwW0vu+18QLOUjOvZvTPP fe5lX9vc51fniJerBVo7vYGDHLUKx8hbRX3JZf92jKQyeHz8yLhHCe+J/n84jC7no8Ftgl1dZKtg 3Pfvwsx9br1zjLmvfTtP1L23LG7uc2cFsdO91ScH409oPj/MdCZ0b+5bgOP2fHKfd975CenomEH1 Z8JHqmTaWujsF5iHPx1eJEjln48Wt5PEztveM3Iu/oCCygXzFWmhLf7oUmza+Ft+doVXf7Oc4pom uU+outlSFJk48GT+0G/UW1e33FXKkyIt8lRF3OdNoZbqGgEiTD7NTz+qex0cda+DA2eEE+Hr3rT0 iuiFpvCJSs02L+wHWnT0NC4y7HjtPVcuCt292bAdj9LBZblwjFcsx2O10m42q7WmFXYwXrEcjwrF Hu/a2R4u4FWd92IKIUyRDfAPIPM4sRpel1iD4VkE/7ToGXIujtGsFkcs3K0UiRrrkxxPp5/QFIDD 42ss8NPzsrP93LIMc1h2XqMP/2q0RFzXErnpDsjojI8b3a4oBlg6Mu6LCj57KTfr/2hyfk0Msf0b CG5SJBQZk4dRF02nbqFAHlDyNxcfHInmHxSmu0Z3qmXUQ2Iwx4dQJwRz4rQb1SuV5kH04woB7gpa ExaIFvlnUJi/iPSUNQxluqQpaopghTggd/8NXZdWzrTslKj3r/00L+QG/1I2Gf4YvckoBO6L1m0D scOjxXCwqcoZ2JKY8fZ+6+28HT6gM9mm6po4ikAh2fi4dJzgZNGJasj8bnh3hakIt6NZ9EH1Zj5d TWTcEQkl6ybvF6JDKFWl2c1hbtGtdY6+NZ+iOecZzs8GLO3h4sOMjIcfnskyHMljLjQyUn8SlH1S rpWtFJXL5QNciVJHfKM+JOWs9AguO7fL5ezVy5fL6XS8OBwNl9eH0/nNy9vl3fgl+xhL9LfSbHSH LtqiF3XaTRopjwZygYel5yEIIkWdiPKF8ZBF0zp7cSPlQfRzf3kAuowLNW0yyU+Gca0/ajzc/EVQ 63owh6TWZXLFKYL4r4JnfzxM5sT6kcmL9FDRHxmn9T3Rakh1zftEXFEROP8jzYrUR7yPVGIl/vyP 1NtSe/A+gi5Hedut1uoyxOVfpdXK2y4AJ6W1d5VaU8WrvI/U41beduuNOG+7jbIKwHk/1Ki18raL +oQ86Dabzby9tCrlPNABo/L20i438/bSpkRmVpe8h263q9ntjofXyxT90ZQ4s4bxQNxyEIjxRKXp AL7xRLXhICHjiRoKN8L7qNccNGas0ag5rs94olVR8WANYsYTAEfOPuJy2YECxiJxue0gU/ORuO3A EvORCrYbhgmmnzgQyVyl1hDEDg6PQzMvXKBJEkWskBV/jTorCCZCB5oehHx4kS5P/+diNcYfkEs9 FbvQrSsJJH9w6sOIKrgxmRs+X0hxsYLmC5ELGL4Q/hv2yasqrZr+S8Jof43rt9XrnDafntMBc6HV iOsNJM+I8zvf0FM6+I1qtRqrCqY5LsYdc81aFOmzpGm0u/gfJ2X4Xofm2qp4x1w5jA4zRV1TBrLP JleCL7nVgt5h9zA6H6NTEkUqaKbkJEpHnDoad0F/5UTQQ1LDxLYPovfT+yhutwopFhXM8a7yzTAw NB3C/IV1CPknxjnhOthc4w/dGg4QlytNLzTp9mpH5SqYmX8ZN2C9Jlj2hjrvRku0WRiPqWMgyiv5 Hn7hbrco8qFY9ZmaNERKMibZINSErIHL1RVak6uWhjxZrIBijAZ8OItPM3bsTqq2lGbNls1wvlZw UaT1cn7dJyCajdDBKkwldlP4WQOcnKzn6KTcPOXUJY2wTrpxo8uEbCOY+TgjmHz4UQgm1HMqHqmG VHSjIrrdjO1nxTIZVOQ/Mw0DBGwKGLzFWPVo/unT1L2ujlr2E+pqCNuN9bhycgjJkZmf/fzy5H3v hTL8q47jqEUFQknQ82Hc9OIPk2a29S6Zo+MgPAx14yROFLHmF2vsxvxlZ+wmcERCETGKz9g35Ok8 L8VDIMdWQXvxqn7/jvs8R48EhKszhrWBa/oldtA4hV56SJGATnYQHc3mozHdTUaaBQBj8krnPcbH tXbVbupl/VG7XPMXYY+KFWgb22oZ0hLne8QEtgCtksHevUWQC+WmGL+tQ9+6+xTCglDkxsWlmRnx nM50RiONmeujkeQsepdM0KiQEvXoNkSJBs/AE+3O186Tt7wVjKPqjRZ96kH+gN7oNCbvcjKdzkgD vZTTWOz9ia0oUo9qOPgBvssuPvOSnRdnKT/aHZm/7IwATcYjp3SLQ/DFQQ38GL1P5rgZ/VocREHp Y2izD2BRwUvUwHTB8/vGGuGx0gGaYc+WhO9NA25OUDS7zfrROnVPA4X5y85Awad2s1sGRbtczbiK n4QXQc9k1GSXHdQYA3aaNkus3+A6hPlnPMNSIWQNh1j7nAvcgnSVOdFE/VG7GvNxyUlSX/7WnER9 yaFv2dEJyXUgPBrwZ/hA5VgoRXP7nQBeSA3UfsO/XTd6sSUhAwYXQ1W3TzyK2ukvqE/N22SOPpw9 GoDRBf/yfTGDAuBh7+UMMoUDBBfgAJKw4N40lTAnIe4jL9k0TN4ME+pKKm1N3Vr/BmKhdhWCjIVa SetGYNOuQhCxUOUnctrSVhWCioVKF5cl9jQ27fdjyJpG4OKWMWKKIy+WF8PJAEH4wTkk5zGaEn4S 9nHnbAKGf4fmIBvGSb3FCw15VgUeJFlh79QHocGxfSduyop/J8GpP2rsyXyc2ZPWM2Az9gTGK4zs dQ1/g62rgjX8Ta7hBzRxMMNvpHcFaHBgZqMViV358cXhfBHSHgzTZiriB6rxt39RoM2yUTeDy8hN yaVfJ4hlTRafitfwLjsH9maehj8bX8WVZRo4NNlTUPCqWtkGDgKWGjouOz8jTsftd5Kxy6xU8iF/ a5v0lhB4yVgkEEDJjfzPsN9ncwh48MwJZPaFFfyEfRI3blqmtPOr7CAp+FXtasXB2ADPBx7LmYLf KHYyku/532VhVfC7mbNlYrFMFoBh1vNt8l59FLr5C3NlqXMQAB/NlZssWwue0MuVnWeyVCNN0pi/ PO5M9GmZCuZnvJ3f4PYEs4ByWHr/S+9jdHIIT/N8QLk+B9HZIRyfkteyw1QLszcQ5SjR/Anx8mQ1 AMXbeJO9z3KzetJzuqbNX8TZxcOb36d2dqYmNw2bLhFN/rE+XK0eN1vPAq//RlVaJahwS2qd1V98 jN4dRj9hzgGc/D8eIg2MShXI25/V0dcvMZs0wKbtQzB3CRjeSUfcwCf6SimZ3w1Ki/T7pXJ8uPyS UfIDJ4ieD7/MkIA0wHwimVEUx5n8ldTHvE78QI864JTPv03ga3bL9foRPaW5jZvVZhNuftqR0kCL Z34skPox8PnHA2AJ+cyd5Nmo1WrttRtMI0/zUIyicbXSq/f4SJuxnIIoahuqRV0HCGr8fkEjdGkU jIVf7jXW5QkBjMmoZJm1bubJHZs1IgQoVbbL2+RW9wRZO7I0TwlngfEUnjmeT5NBH3YFqEqeiT11 ln0LJxLTk8CGBb4paCSZz0rAcgEMpAIRmei4j6wdknqxmUwH/mn7jOlwazhZyC0wPgA8m9+4CIuV oRBhWdgpWETcrtYRj9kbYXlA+VjSEps3qUoX8a3jSv2EFWRiIkxvGmrshd58iEk8TYI+cMO/scet 9BZZcvmUsqCSF41UnNim/Z4Sib2Xxxca5p9MJ15xSOVXJHfh5Wo2m86XNoIbOz6q1rqnKjsXviny 82rUyrl7o9l9o3S3GmcqqoyV9N12aBslzNHDNhaYQW+Tdm/YJ89xZUvStkG9hSLhJFjjCBT8LSDd LAjpB88QYlbx8lOZ+YuHylQujZZI9D2v8HteoUzZNVGhSF5h1ZGZZq7yJ009hF6naAXG4/QSuWfD 3glUBa5/k2lg61/e278M/r6C+xTJAMszdmXqr+0vkS1Z9EejH551p2jcOORk4UybO2z09gjzgoyn NCdx8ZS3TUqNnBq6aSZfCDVCureVUqap7ebjwrIU9Rkkyp1qhIwtyCKcdBZY3oxgldGXGRGs3NMs zrFFclDDusS/1r2dVA8hqybNeMWqr1NNpWXepOsriB8YX1ExAusrmt/cilFov8jPpMLYADzBMuT6 P+KOxIu/RtIeLlCeBwhx3ECda70Vu0Js/YuIl3wltIE7/HR0s5oPpfEj/C/5xa6aMajwNwNbaTHn LwYG5FZToJYOkqi3mlwlVhPR7+AavyLmivxfjEVDQ4n74bPOm1XyeTiKPgz7t5PpeHpDuTuGefAd ag6o1au1cvR2eJP0H6LeHHE+pG+gdG8Yxc36d/ABZSQde2j0HPQ9PYg+/GfUrKOy5SD65fLo//73 O+DyAXc7nWC86HNM3XgRVZrNqN4CIn6n1zyEO7lLRuNX0XjAYuE/bpnpHWI+5L8E7L6zaAeL/jWZ I7fdvF+Hs9P2T/nVvk1Uk85Pq7vk/wUAAAD//+xY226jMBD9FYvnXiBA0o1K1G6SVn1oFSV7UR9d GMAbwMiY0vTrd2znQtS06kq7WqnlJTLjY3t8PJ7xiWDnp81QjtSvGJ03w1JwHk+FIGhdlRBYVQlZ Ni0i61SDSg3CXlGxaB5Ytm1/9fqTqbUxzYQy+gN36rtb4wRiWmfyJXzWMumZZ8aLhVxlgFM+0iyw 5lfjK5bUApQPuLLBZLRIEAG0kpcVo4H1nB6P79ZuagzuqTRYtR3t8J53fzSZYuma8ySDPcbUGp+Z Eqdv2+QyL1MmU6BSAJlRsWzoqmNpG6lydMvrQlJWkB8MmiMyviRfPNtzO45aHH1fdHS06JjmlGVD 0lAhoLhY1jkV7KQA+RFI+uRJkzzl2bAqaYjltRRQgXgEa3STcEGuaZWyolquyEc4Zwznv1N472nK ecfILj0cDiHPJz+hksQ5kylZYDEGSfrYjDOOsdXxt+NvdAcNuedieUTu7olj247T0dOiZ119GOak i5W6fMesCE9Cnv8fllSyZPq5T2MJSmHsSQFxxQtZ7YmBBcsXdWFQ71cKrxQm13XHWy2zJyE26W1P 4LTh7xU43+BJHt5TWAXWmNeCgSAYtYcEzj9ye+D1Bt6Z9ZYu27n9K0QutFwLocAz6jajpOfmZCoI 5WxbDI3obYfJ/FBULXCQgjpub+JP9DmgxopAzCEGfBWGSiEblR4ZgW0RMWRRYImbyHHNCcSc42m8 a4RnRry2RsxEJdsr+G+v8ALfN3jl8TZW8OKyouZ1ZfrKZPGMfU1gOb2eZ6tLl2LbPzPtkEf4ZnI2 2FuqKJW8RJtnEIIlKZLmuL4e/MCl5Dl+92z9nUGMvYOemVmTuRtrqNqBk1q2k03IM5Vj1g83NYf+ O0IymcEs0e2Ih9eCRYjKWAEzJkP03u1rJIaCiQIdFQ88WukGDqlzvDGj3wAAAP//AwBQSwMEFAAG AAgAAAAhAMe8OvqFBAAAbi8AABAAAAB3b3JkL2Zvb3RlcjIueG1s7Frrb9s2EP8+oP8DoQ/5sNXR I6/GrdV5sRy0Q1Yj9goM6z7QEm0LlUSVouz4v+9RLz8lc1msBpkCJIpE8u74u+PxeMd37x98D80J i1wadBT9VFMQCWzquMG0o/w56rfeKCjiOHCwRwPSUZYkUt6br356t2hPOEMwOojac2iYcR62VTWy Z8TH0SkNSQCNE8p8zOGVTVUfs69x2LKpH2Lujl3P5UvV0LRLJSNDO0rMgnZGouW7NqMRnXAxpE0n E9cm2SMfwWT4piN71I59EvCEo8qIBzLQIJq5YZRT8x9LDaY4y4nMqyYx97283yKU4eYwvABV+F4q 9oIyJ2TUJlEEX3tpY0FR16p4ZwAKEsUIGRE2eeaS+NgNCjLCMLb0XyjvFJSnprxVQWo1EcDCBDMK 0aIN5ufcdxRNO9POjO61kn/qkQmOPb7bMhCf+ue6dnOeEhmwhNaQLz0Co+fY6yh9SjlhiipaWNph 5k5nHvzyvM+SeB5diD5q1gmeoegsno18x8VvAAsY9HhjdLvgeDI7qFb6laVdG9cySs8VCWSFHrnZ i4MxZi2hWZ7qO9Evo3RiMQbs+TIES45CsIkhx4xnppOO/j0GB+ZKDbYCZ32ocG/tKMQ2EA8ZiQib E8Vs3WLwPkH0dYnQFtVUXjzOrFLwF+Ilq2QDskSy/eSth9AFXntJTzznZoYFyey/UTLxMZnCopZi CnJzNiIPfD9z9KGfMC66reAGjkPXD5NVmjR3FDTsfrZ63ZGF0Jdf0cm3mPK3d+kDffkZ3Vn3t1b/ 0/1dd4QSvSfwZAs6oAOhv7X1u2ivuJ4JYFev4g0Gw99Cimpsi6El0+wgHX2MvWXZZBNJny3ah8B+ 7tgbqBtP44i/TPSfnamfoSEJOfHHhDWIP3BTN47uXc7RJ5vTBvBkq6kD8Av0B503Jp5t7nUgfol6 xG4QrxHxK/QRBzFmLzRq+Zf7Zg1e/A3qkzFrEE9PDHU4lWt0h5k9a8KUesIUXUPdkLleg3dNeOtg 3437hvRDHc5EN+CMHxCk9LEL6dutU/HeM0CWcio5+UckxAxzIpdqkUp0CAEfIQlJE1VpWqQqyXQo EdKAspvgayxlT9azAaUBBXL9Iu3a+BTnfieb34DSgCIXFxyylMbT/gBPK8qZv/WNi6uLopy5s8Sl Aroi1f6Co7oGrM36a+W54D+Cxc0Ni1qrf1fVKKXPB2V1YGG9a7yKsiuUnhP/BcXfrcKv8zqr/Erl 8bhp6K83mMgXdyVlrsLnx1fMD9VwpVAsthLz2AXzE4+/RVdleaJ95lHcDShm+hf8PMntAEPTjz3f R3jvF2dTR8+wn0zBqC7LjKqm9dsp41+/UR+7Lv0L3Ho5UsInuY6TXtWrvtlTunarU2/SG1rhEktu /uxPBv7vYTmSWeSX39aCoAOWAoFB5t3Xwo8qV7BtGYK+bISQi7cT6pcQ+HuApyTxF5LCPeGeMOje WmWuqgof2eD0oF70jXDtiZYrN//ZIAtR4MHLuxvaylVYfflU/saxEGB1i1gEpZyZ3wEAAP//AwBQ SwMEFAAGAAgAAAAhABkwKWtoAQAAswMAABEAAAB3b3JkL2VuZG5vdGVzLnhtbKSTzW7DIAzH75P2 DhH3FNJDNUVNeon2APt4AEZIgxYwApKsbz/ns1tVVdV2IcHGP/+Nzf7wpZuok84rMBlJNoxE0ggo lTlm5P3tOX4ikQ/clLwBIzNykp4c8seHfZ9KUxoI0keIMD7t0FuHYFNKvail5n4DVhp0VuA0D7h1 R6q5+2xtLEBbHtSHalQ40S1jOzJjICOtM+mMiLUSDjxUYQhJoaqUkPNniXD35J0iCxCtliaMGamT DWoA42tl/ULTf6VhifUC6W4V0elmOdfbe7KVjvfYD91MsntwpXUgpPdoLSbnSkzYrdzzBQ6INeIe Cb9zLko0V2bFDNNx0f+1eRtsHp1y0wF1LgTvIj/PUtSn4WQR5KXljgdwBE2qzEicjOcsbnFWy5eM MFZst8UuGU6MpkJWvG3CD89AdsOy4mi+p6MNVzv+z1N8TYQAE5Rpxxl5vRTE/qPnKvmGNlS7vLb8 GwAA//8DAFBLAwQUAAYACAAAACEAvHdW72gBAAC5AwAAEgAAAHdvcmQvZm9vdG5vdGVzLnhtbKSS S26DMBCG95V6B+Q9sckiqlAgG9QD9HEA15hgFXss20Bz+w7PplEURe3G4Hl8849n9ocv3USddF6B yUiyYSSSRkCpzDEj72/P8ROJfOCm5A0YmZGT9OSQPz7s+7QCCAaC9BEyjE87dNch2JRSL2qpud+A lQadFTjNA17dkWruPlsbC9CWB/WhGhVOdMvYjswYyEjrTDojYq2EAw9VGFJSqCol5PxZMtw9dafM AkSrpQljRepkgxrA+FpZv9D0X2nYYr1AultNdLpZ4np7T7XS8R4HoptJdg+utA6E9B6txeRciQm7 VXt+wAGxZtwj4XfNRYnmyqyYYT0u5r8Ob4PDo1NtOqB+GsG3yM+WKerTcLJI8tJyxwM4giZVZiRO xkCLV9zW8iUjjBXbbbFLhojRVMiKt0048wxoNxwrjuZ7OtrwtOP/ssdXZQgwQZl2XJPXS0nsP4qu km+pQ8GLVJ9/AwAA//8DAFBLAwQUAAYACAAAACEAOPezgnQEAAA/LgAAEAAAAHdvcmQvZm9vdGVy MS54bWzsWt9v2zYQfh/Q/4HQQx62OvqRJWncWJ1W28E6ZDVir0Cx7oGWaVuoJHIUZcf//Y6ipNiO JWturQSZDCS2JPLu+PHT8XjH63f3gY8WhEceDTuaeWpoiIQunXjhrKP9Oeq33mgoEjicYJ+GpKOt SKS9s1/9cL1sTwVH0DuM2gt4MBeCtXU9cuckwNEpZSSEh1PKAyzgks/0APOvMWu5NGBYeGPP98RK twzjQkvF0I4W87CdimgFnstpRKdCdmnT6dRzSfqV9eBV9KqeXerGAQlFolHnxAcbaBjNPRZl0oJD pcEQ55mQRdkgFoGftVuyKtomHC9hKgJfmb2kfMI4dUkUwd2uephLNI0y3SmAUkTeo4oJmzozSwLs hbkYSYyt+c8n7xQmT1e6dSnqYSCAhQ00YmjZBvpN7jqaYZwZZ5ZzpWW3BjDBhtF/bzkOEDNt1yVT HPvicfOBvNU1TfPqQkke8ETBUKx8Ar0X2O9ofUoF4ZpuX+ugW7XgmegNfbIvVw3m3mzuw5/IpKyI 79NlKiVtNOZKaKL0GCKlQcLuxuEY85Y0XySDUIPklE57XKoVKwbzETEwcSgwF9JKGInq/XsMr6FX qXMvnKx3lS9pO2LYBeGMk4jwBdHs1g2GdyiMvq4QQltilUo8rgSL2C2/d888ULZT9NSfvJ9jOeT0 1ygZ+ZjMgJuVlILhgo/IfYFy9Fs/UZw3e8AbNA69gCW8Sh53NDR0PvW6zqiH0Jdf0Mk/MRVvb9UX +vIjuu3d3fT6H+9unRHS8hlJuRPSgZzA1GhFugetZxLYh0t5BdjC/9yKRF4hi/OuuzFGHWSiD7G/ KhpsMpHPFu19YD937C3kxLM4Ei8T/WdH9TM0JEyQYEx4g/i9sE3r6N7lZ/TRFbQBPFlq6gD8HP1B Fw3F08W9DsQvUJe4DeI1In6JPuAwxvyFRi3/cd2swYu/QX0y5g3iasdQh1O5QreYu/MmTKknTDEN 5DDu+Q3eNeFtAr8b9w3phzqciWnBHj8kSOtjD7KQW7vinXuANGtUsPOPCMMcC1It1VIp0SENPMAS ojJVKi0CRh+cCGlAeZzha5iyI+3ZgNKAAiUJmXbdl1xtfErjUxqmHLwkN572CTytLKT+2rfOL8+1 womrFNDlqfYXHNU1YG3WX0v3Bd8IlrA3GLVWAC+rUVbeHxTVgSV713TlZVd4OZLlH4q/W4Xfyeu0 8lspjydsy3y9oaR6cbeizWX4PH3FfF8NtxKKeSRmH7tgfuKLt+iyKE+0ix752YB8pJ/h811OB1iG eezxHuC9Xxynjp5hP5kBqS6KSFXT+9sp0l8/qY9dl/4JTr0caXOWHMdRp3jKT/YUvrvlqbfKC1ru EgtO/uxOBv7vYTkSLbJYei0I2sMUCAxS774WfpS5gm1mSPlFEQKc2FOfjcijLH9aIOmvAZ6RxHFU tPI7Lg4D56ZX5LPKgKoape6dINPchk92KciZb09PxohHB0+F/feGWIgHmZT75KdllSEyPBXc/hcA AP//AwBQSwMEFAAGAAgAAAAhABr2Oe+VBQAAlDQAABAAAAB3b3JkL2hlYWRlcjIueG1s7FtZc+JG EH5PVf7DlB78kKyNJE6zhg3L4fUm7LpsJ6mt2pdBGkBlSaOMRmD+fXpGhy2MQItBcTnSAzqnj69b Pa2e5uLDg2OjBWG+Rd2Oop2pCiKuQU3LnXWUP+9Gpy0F+Ry7JrapSzrKivjKh+7PP10s23OTIRjt +u0F3Jhz7rUrFd+YEwf7Z9QjLtycUuZgDqdsVnEwuw+8U4M6HubWxLItvqroqtpQIjK0owTMbUck Th3LYNSnUy6GtOl0ahkk2sUjWB6+4cgBNQKHuFxyrDBigwzU9eeW58fUnH2pgYrzmMhimxILx46f W3p5uJkML8EUjh2KvaTM9Bg1iO/D1UF4M6Goqdt4RwAKEsmIPCKkecaSONhyEzLCMdbsnxjvDIxX CXlXBKlHRQCLLriRh5ZtcD/zpqOoalWt6r1zJb40IFMc2Pz5nWtxaVTT1H4tJHLNJK1bvrIJjF5g u6N8ItgkTKl0LyrARjwh9kXzBO0ES979QjgAcI/ED1gPXTIaeGjH9scZGgTuBDMhO5caSHIshuga 3oEUFBxPQo0Poq+uNlv1hiJB244xiIcnvlQVT2ITGDbBTJjToz6EF7CuKuwhn42fYdZszpNnzs9V +YhQV9KLbZfgeOVywlzCEfj/lG/HpT/Qz/tNKT4XUabte9gAb/UY8QlbEKWL1glE0oVSZozZYbTk 9qcAL4mVnMJBitvL3bE6qjX71XzmsVxTOI1Au6PUWjHK8sWIwd2sr0DcNYkpZgIe+G105YaBHSIo tteUiklJNwQjbib5FJPk+O+zND7gNozS6ZAJb+crDwzne8S2bzlmPPQjcHK41f09gNnFSoGbNXjo mnFIEGP3Dz8HxF7YRYTA6GWuNgfax21OO3zwLPDg9jpcEo2pbfbnWEAWHd1J5CZkBiE7CQ3AMZOr 5fqc3ZGHLNtdjSTj5LHHsAQcby3HkzFY3u4o6Lb313DQuxsi9P03dPJPQPn7cbhD339B4+HN5XD0 9Wbcu0NSZakDC2ONS6+FA0RCh9ceuVaFvR9PxRkMht9ECmHg/dXsIA19DuxVlrKvG+1dYL927HXU C2aBz98m+q/O1avolnicOBPCSsQfeFfTjx5dauirwWkJuJxqigC8jr7QReni0eReBOINNCBGiXiB iDfRZ+wGmL3RrOUH580CongLjciElYiHXwxFBJVzNMbMmJdpSjFpiqainscsu8S7ILw18O8yfEP5 oYhgounwje8SpIywBcX5ta/ijd8AssyQVFfW6yw+8TDDnOQrteQqdAgB95AEanb5hEhqKBm1uhKU DXXjEpQSlLBIW74+GyrXJSglKOXss54cHGxKLhOVTWu5R56TxUr7x5Feb9aVzLWzXAldUmp/w1ld CVZ6/XXrd8ELweLdlEc97RMRS6AZK8K5g1HWOrDw3py8/vvV513roT9YWTz24vOJzd+jZlbNJVnh hjgkM62n6+yJpt9gO8hKu65qx9Z3j0j45nzq6NXqkxk4VSPLqQrqZ+hk8S/eqY+9xvsrdJAcKSeR rS15umQy393tZazck8OuD73NhbX/PSxHcos4L32SUOzwFN6NPSTnVL7uGYJ+VoYgX/V1umGH6pZB SUPgpoNLSmfQX/ZsSyUjkJi8sNG3X9dbDV0mBVGHpJfRXAyKHKTxtVGNWzJjenk6Nvdos3wGHUJX M8rQJYZ2eNe/Xx0YygM2SkpfO4zKMQrf8JzSA2tcQNe0TaaPTdOaqjd2NVZD83V9q4Npaisq2ORo CY7RW9uncIwmmH1f9zVam7KD9bbS8XiMzHdoBVuU9+bK6nk3WcLXtXcI4mEtxfxZS+m2kJca+bz9 tK5DDUFKlRUzUwTyBLJU13A8AWz/68STvvid0S13FAJZZQopf3ZZfYOWMB7+U9T9FwAA//8DAFBL AwQUAAYACAAAACEAm5Ip1BQCAAAdBgAAEAAAAHdvcmQvaGVhZGVyMS54bWy0VNGO2jAQfK/Uf7D8 HmI4WnHRhRM6DrWqRBG9foBxNmBdbEe2Scrfd00SSqEFWrUvieLdnZndnfjh8ZsqSAXWSaNT2u8x SkALk0m9TunXl1k0osR5rjNeGA0p3YGjj+O3bx7qZJNZgtXaJRUGNt6XSRw7sQHFXc+UoDGYG6u4 x0+7jhW3r9syEkaV3MuVLKTfxQPG3tMWxqR0a3XSQkRKCmucyX0oSUyeSwHtq6uwt/A2lVMjtgq0 3zPGFgrUYLTbyNJ1aOpv0bDFTQdSXWqiUkWXV5e3sGWW17gKVTSya2Oz0hoBzuHptAkeEPvsEnc7 wABxqLhFws+cnRLFpT7ABGOc7P+wvB4uL2644wD1oxGcxRhtVJI6Qftly5QydsfuBpN72h0tcMGM PQ/YaDQ4HE4h59vCn6cvwtFs2GdPwwZ5YfcEX/yuAISseJHSD8AzsDQOEdskFFyvu7BeRfPPIRq3 YXyXTZr9paqLOFgB3PmJkzylryb6tDyGrhM//qg9WA0+wmXmPrD6hnuPe43Rzoz2DrOES+mLVODI HGqyNIrrpsXz3q5q4qu2/b2Eo/7+C1v49xNXcoEeKi04sBXQMTmdxJGM85aO1hXmt7BceLwsHPGG OMFx+ZPlIp5PidSk4HYNZPp0SnBt1OesfzLI4KLQwj82++SZvRv2j83+W0tfVtu5vNGJT7zcx98B AAD//wMAUEsDBBQABgAIAAAAIQCWta3ilgYAAFAbAAAVAAAAd29yZC90aGVtZS90aGVtZTEueG1s 7FlPb9s2FL8P2HcgdG9jJ3YaB3WK2LGbLU0bxG6HHmmJlthQokDSSX0b2uOAAcO6YYcV2G2HYVuB Ftil+zTZOmwd0K+wR1KSxVhekjbYiq0+JBL54/v/Hh+pq9fuxwwdEiEpT9pe/XLNQyTxeUCTsO3d HvYvrXlIKpwEmPGEtL0pkd61jfffu4rXVURigmB9Itdx24uUSteXlqQPw1he5ilJYG7MRYwVvIpw KRD4COjGbGm5VltdijFNPJTgGMjeGo+pT9BQk/Q2cuI9Bq+JknrAZ2KgSRNnhcEGB3WNkFPZZQId Ytb2gE/Aj4bkvvIQw1LBRNurmZ+3tHF1Ca9ni5hasLa0rm9+2bpsQXCwbHiKcFQwrfcbrStbBX0D YGoe1+v1ur16Qc8AsO+DplaWMs1Gf63eyWmWQPZxnna31qw1XHyJ/sqczK1Op9NsZbJYogZkHxtz +LXaamNz2cEbkMU35/CNzma3u+rgDcjiV+fw/Sut1YaLN6CI0eRgDq0d2u9n1AvImLPtSvgawNdq GXyGgmgookuzGPNELYq1GN/jog8ADWRY0QSpaUrG2Ico7uJ4JCjWDPA6waUZO+TLuSHNC0lf0FS1 vQ9TDBkxo/fq+fevnj9Fxw+eHT/46fjhw+MHP1pCzqptnITlVS+//ezPxx+jP55+8/LRF9V4Wcb/ +sMnv/z8eTUQ0mcmzosvn/z27MmLrz79/btHFfBNgUdl+JDGRKKb5Ajt8xgUM1ZxJScjcb4VwwjT 8orNJJQ4wZpLBf2eihz0zSlmmXccOTrEteAdAeWjCnh9cs8ReBCJiaIVnHei2AHucs46XFRaYUfz Kpl5OEnCauZiUsbtY3xYxbuLE8e/vUkKdTMPS0fxbkQcMfcYThQOSUIU0nP8gJAK7e5S6th1l/qC Sz5W6C5FHUwrTTKkIyeaZou2aQx+mVbpDP52bLN7B3U4q9J6ixy6SMgKzCqEHxLmmPE6nigcV5Ec 4piVDX4Dq6hKyMFU+GVcTyrwdEgYR72ASFm15pYAfUtO38FQsSrdvsumsYsUih5U0byBOS8jt/hB N8JxWoUd0CQqYz+QBxCiGO1xVQXf5W6G6HfwA04WuvsOJY67T68Gt2noiDQLED0zEdqXUKqdChzT 5O/KMaNQj20MXFw5hgL44uvHFZH1thbiTdiTqjJh+0T5XYQ7WXS7XAT07a+5W3iS7BEI8/mN513J fVdyvf98yV2Uz2cttLPaCmVX9w22KTYtcrywQx5TxgZqysgNaZpkCftE0IdBvc6cDklxYkojeMzq uoMLBTZrkODqI6qiQYRTaLDrniYSyox0KFHKJRzszHAlbY2HJl3ZY2FTHxhsPZBY7fLADq/o4fxc UJAxu01oDp85oxVN4KzMVq5kREHt12FW10KdmVvdiGZKncOtUBl8OK8aDBbWhAYEQdsCVl6F87lm DQcTzEig7W733twtxgsX6SIZ4YBkPtJ6z/uobpyUx4q5CYDYqfCRPuSdYrUSt5Ym+wbczuKkMrvG Ana5997ES3kEz7yk8/ZEOrKknJwsQUdtr9VcbnrIx2nbG8OZFh7jFLwudc+HWQgXQ74SNuxPTWaT 5TNvtnLF3CSowzWFtfucwk4dSIVUW1hGNjTMVBYCLNGcrPzLTTDrRSlgI/01pFhZg2D416QAO7qu JeMx8VXZ2aURbTv7mpVSPlFEDKLgCI3YROxjcL8OVdAnoBKuJkxF0C9wj6atbabc4pwlXfn2yuDs OGZphLNyq1M0z2QLN3lcyGDeSuKBbpWyG+XOr4pJ+QtSpRzG/zNV9H4CNwUrgfaAD9e4AiOdr22P CxVxqEJpRP2+gMbB1A6IFriLhWkIKrhMNv8FOdT/bc5ZGiat4cCn9mmIBIX9SEWCkD0oSyb6TiFW z/YuS5JlhExElcSVqRV7RA4JG+oauKr3dg9FEOqmmmRlwOBOxp/7nmXQKNRNTjnfnBpS7L02B/7p zscmMyjl1mHT0OT2L0Ss2FXterM833vLiuiJWZvVyLMCmJW2glaW9q8pwjm3Wlux5jRebubCgRfn NYbBoiFK4b4H6T+w/1HhM/tlQm+oQ74PtRXBhwZNDMIGovqSbTyQLpB2cASNkx20waRJWdNmrZO2 Wr5ZX3CnW/A9YWwt2Vn8fU5jF82Zy87JxYs0dmZhx9Z2bKGpwbMnUxSGxvlBxjjGfNIqf3Xio3vg 6C24358wJU0wwTclgaH1HJg8gOS3HM3Sjb8AAAD//wMAUEsDBBQABgAIAAAAIQBOzkj1eC0AAGvg AAARAAAAd29yZC9zZXR0aW5ncy54bWzEnVtvHcmR598X2O8g8HnbXdesKsLyoC6ZO17YXsOyd56P yKMW0bzh8Ehyz6ffX5Fiy93+xWAwWGD94tYJZlZeIiPj8o/I3/7L3+9u33w+np5uHu7fXtS/qS7e HO+vHq5v7n94e/G3v5bvxos3T+fD/fXh9uH++Pbip+PTxb/87r//t99+uXw6ns/82dMburh/unx4 e/HpdH/5dPXxeHd4+u7u5ur08PTw4fzd1cPd5cOHDzdXx6//d/G1xentxcfz+fHy+++/NvrNw+Px nt4+PJzuDuen3zycfvj+peX2cPXp7nh//r6pqvT96Xh7ODPgp483j0+vvd39V3vjUx9fO/n8H03i 893t6999qav/6C+/TvfLw+n65xb/meHtDR5PD1fHpydW9u72Zbp3h5v7126ebv8z/bys5x9u3p8O p5/+oZPfsW3//vBw9+bL5ePxdMWCsudVdfH9TjhcnW8+H//tdLPv6rvzT7dH/uzw+Pinwx0b/8d3 //Y8my+Xt4edN4733/3t3QV/8fl4f/1w+v329iJ1+7+vb2//z8/81NbVAAd9uby/XT8er37kc/u/ 4JGrH58/sf/wX/j6h9N35S//375+fPou/7+cO1v+8OHd+XDeV/zp8Xh7+3z8rm6PBzb+y+UPp8Pd 3YHj8vLLy3qdzweW8fqvx7tHTsPxzeny5vrtxen3118X9GnfwT8f7o/l+TSVm9vz8URnnw+wUF2q 8WXdz6fD1Y9/OX6+2SXA03PX18cPh0+3578e3r87Pzy+Nhmar3xy/fCnh/O//vT48XjPd9fD40ur q48HuuIb7x4PV4x/fbg/nx5uX5s/t1of7h5PMPfLpz9en959PDwet5fvPf3utw+XT/sPXwfw9Obz 5fHvsOjx+uaMGHq8ub47/P3tRd830/Pov/9y+c99fLn88PBwvn84H/982tn69V8MZF+g774uz69+ fp4b/b3+/NIW1v7W0dd//KqfX/762s0vGiIAHw/nfSyfno4l/+Hw08OnMyvN576RkMDXrMCXy/0/ /sIMXheuqkquxrp/WbOd+o1SVfWwZqc0c9M5pW1L0KYrw+Zt+nlYnZK6LQWUfgy+k9ZlDtqsJRj1 0LSNtxmGYGx1NY+ttqnravPv1G3VRpR+Kt5buw6+P3XXZl/Ruq/mrwfqV3ta93X0nb5tfa3rfshf GfufehuL71yd+s5XtE65DUadSh+0GfrO59M0ufJRs6OD99b00diavmxBm2HOvj9tldpBd66t12Fy SpOaoLe2G32329TWPtN26DbnxK6qss+na+bJVxTK6nvaNbkNvtMunc+n66rFz2nXz1FvQ+p8Rbth CuRO36zF161vti6g9FPj8+kTrKg716e58RVN9TJFlNw7x6dmW3ymCL7F9yf1c1p0bCn1ydsMVV37 d4aqmX2mA7vtp35ol9ZHMCCQfEWHfnu94n8lQwZG7fw2pHXzsY1ofs5vY9MFp3FsYQRdt7FvF5/P 2HeTn+CxX+ZgBMO6+hqMQw7kwVTVm49gqvPsI5iaOljRqd3arwrYr9Z6anNwN05dF9wYU7/loLfU BDJ+SnnxUc/VWvtuz/Wasu7P3HaNS765nSZf67lrX5XQX63B3HWBDJn7FPXWT5Xzzpy2ynl0HvqA R5cKVtSZLvUYyKqlbVtft6VLm6/bMpTBR71W1RRR8uza01qj9Omo16bufRfWBhEbtInk6NpunfPO 2sE83lsX7dzaDYvvz9rl1aXl2qc6mE+f26hNWYMVHergNG5o3t5mQ4H03d6qvPkabHUzBW3arfL5 bNzBzjtb4jbRtd6GbnUO2YZIuuRqnTbtLde58RHkpgr4Ojfr4PPJ7RjoiblDyPsIujHQNnJfF59p Ts3ou5DTuLi0zEMXaOul4jjq2Eq9Fu+t1Ll33inNNga9IfhcjpZuDkZduiUFvfVroAmVNPh38AZV vXLVTnF9B0rf66ihLJvuD5Tsd31dNZ3LgxrLrA56azGAbH9oM7l1WFc9h9vb9NWiO0ebsQ6+gzWl 5wdTs816FqDMbv/UNaaRSmUom1tgdd3Wk69O3bauw9Kmd60GSnaroK77plJNta5T63cJlL6oLobS 27u8hpJGPVkoVWlVjq+bup2dE5u663y3G0SIz6dBXOtdUjdd9tu5btI0B99BD/E9bdLWq+Srm2F2 bQM3RRXsdls1QW9t1Q8+trapOuf4thl73wU0JLeZYLex+C5gOrtnAUYsfp/Wbepb5512mKM1GMrq K4q97bdZ3dXb6KPu2t79Lrh30uhjw3Z2GV93/bI6H3R9DjixQ4/3s41aFcjeLuUUzGfoBufrbkh+ z+GUmgNJ3tc5e2/c534713h33OtR9/2anEd71sA5Ees0OHPo925N1anaVl+dVGNK6L2Q6ql2uZOa wbUARGKTfNSp/dkJ/0v7p06ob36XpDS576kequw2YD3UgfcYSmA31gOGuJ+foa3deq9RnoJbE0Hu dkk94vVwbWOs24DjR9yjziF4CZKfkhF/lWre9VT1wQimuiq+23i4+qC3ZizOO1OzujZYT10kladu JKb2HJP5FYdM3TT4/kwwoo96Rg/xsc3V4Lp/PTfV5N/BNgzuRnyGvcvEuR3ct15DiUbdje7VreeU m2BsQ+tRkXqp5uJ3/VJ3OaKs7jGrl6Z3D1O9YMu4zrd0eHh0T5fUBFrakla3qusFncKl2IrX0Hd7 rVuPL9RrPQYjWJsx0J7WtkTf6RmcznQd6kBarsPo/hD89BEfbPUQ6GJbC//qCKCMLmE3vFIuQ/B5 uA+l3rocSKQN76TvDxpfcg7Z0ry4fMOuD7Ro7Hq3xLHd+Z+uQW6XQH8j+uPRpDq3gX+0zt0Y6GK5 mxaXB7nLHi/Bcq4COZoTJovOp7RTcGeVvsour0vqe+eQklhT/86wVjofsCnjqjIEgyW57oIpVbnf Esroml2DaZT1XsDf3PnqQJnc1sRkGtzGwGRa3F5omOqmu9DsdpZyPJTBvWxQgnuuadrB/WJQFvdx QSlVMLZ+HH3dmhRYyE0zBDdT09aN65a77e46BRTEv3FVg/N48HVru87laLNbUz4fbCY/wSxoP6nG BSVNzr3YWR7fbroKms6nqyY/2wQkKpewxIVK1KZrXENpOq5t1a85CcRJfWxpDmaKXeSSvOmG1W/N neJaQNM3rVviTd+tbmtCKZvzQapQo3U+qR4337kEX6l8I7o9rX5KcNW4z7sZqukFePOCUvmGQ4Gy ueXaIFtc9jYwYtJ7jiPXBrs90EglOW2W2c/CWI2OKWnGagpOycgxUenfjPgTfRfGdg5OPbqTe07R qsbG12DsJ/ePNlPVBJJiwv/lvDNh0alV0EBZnA+mevNoXzN1dQradIg+5dEJmJCf06nvoxGgI/la T2iQwQiGOVq3YfWoPEGzwPsFZQtuzbntg1sGu8TjgM08VG61QVndXmiWKkBENQuecufRpZ4GlwdL 03oMrNntkqBNH9glzdIHXpxmSWOwbsswuWaHOVnPziHYMm6902ab1QZs1rp45LtZiS/4WVhxHzj3 rjTx1SEiHsx0HebG22z17PZps9WL+7ybrSm1jw0kQaBbbi1auZ5G8DZufYDVWgLJl+vJdeUm14tr +LDH7J6SHbniXrYmh9KS2QT6NZRAkmNjOD6kyX3jXjYo2+w6UsHmdwkLxf2JTeH4+J1VCJupfMO5 P7g/vgXx6VYBlMnvOQICrd+aYB0BmRmHtFX3M+D3l74nKJtLF8ILvWvrUBa/G4HmBbH3neLer7Ya tq3oqOt6de0WZX12rbOtu9m1p7YGEaXnZ6f4bdbWw+iaUNtgPausglIcj7QbEu4tgjLXegNCyX47 Y3z0rse3DZaR6ol4rwm/6FoTtXK/C21y9rHBpC57UVO5N/U7bRNgzDCZMFC9DfEFPcE0QfAEbdbO Z4rHwbV14Lgoy95bQsNWSlfNjmkkul08XgK6ag74rWu7LfhOOwZchWXkXra2S8U9Zm1fJ9e4iI3h wtCZYoC5R6btu6Xy3YbiHrMW4eI+Lii9e0FbIkNu/+x4AfdftwmjVuX1ThkDChBWX4PUL+4Xawci gX5KhqZ2D2ALCD7r/QMlBzxKxMYtV/w+WEC6c0M3OboWu6h3DRLK4pgfHAtj57s9ongHlJYkAR3b SBDBb02iPK77t+MwbC7Jp2qu1T/aTsCi/WxPuBN9t7GZ3GMGMGIO7pIJ/g1GgDvCOWTqS6A5TCBy nUfnug0kElbO6HJ0HoDx6i7gEXIPYEuMJZD+C7AaH9tS42jT76A3BLfZ0hTX0sA+b4GMXzg+wQgQ Ia2OAFSlo1HbtV0cKYuRVSff0xVPlnMvt497Stq1B0TrYwO86Xy9wgeuI4HM84gNWSwBlnrPbwk0 B1a6+DndiCf5+dmaIBsCXOk8uTzIbXF/Lzs6Os6BWEWQx4KHGP+krmgBtu6cWKrS+3yguF8Mfybo ff8OSl8XUEbPwmoLOrFL/0JOV/Ad1ieYD6kavnMFl6afBVYguGnL7lD0+aQu0F1KWhzP1xYQuc69 ZKgFp74MpdWTBeQHF6CNDQr77RRUF+WQ3eXt+9Pt9o/eCx22jO92V1eAnHUEdR1YEh3gL9/TnTLq nnZ1N3m0HMrqdyOU4mcb6VZ5LAdKOyvvdIR//DbDZ1gVb7OHeXw+TRugz0hEmIPVgeIYWtqsdfCd IThZHdg814SIIE/ZOZEVmH23MUMd2QP4bPIMPiirxwFJsBndroey9c7xbLdnWHYdZpbeMoT6gkwA KNlvpm4XLr1yfE9c09cNR6MjS8FZjIuvKBRHjtBmck8whlHanA8I5DtaGE9a51kkUFKwP7uwdI5P zZpcVhH49myvLhFjcbkD6sk9Zl0CBa/3T5eG5DYtHqHJbcAOlXz1UZNv5r5BTFDUTuUDfF9ugXWA hV3rhBLkY3TEjKI2BHlcxmMXeZy2Gwmk+7qNuDaC3oiT+uqMfe1eHIQBXm9dnRGkufPOiCak2lOH /dP7yZoq+tPvTGTnuqQAweQxyh3bFOwpKLfoO5ys4DsYRhFlc38VKXK4+nQ+cwXm0ykoG75uRIY8 5trNTWDldHNPsrx/px9cJ+8W3IbOVQtBfp8PtoxHk7qFVfARLIAdax3bQuA5oozulSLvZHU8UoeE dxuww5IIpNjGwfLzA77KIw/d1hWP/3RkSbi122VSyH11Mp5gl6OZWLWfn1I1JemKFqwmP/WFJGD/ Thkq126pzND6mUPlBC5lI+grEKw6AijJvQRQJufEnon6ivYVwB7lHSibo8ahFJcUSEQyZnQ+NR4z PSVwNS55b8PYdK3JYln9lPSIa78bocwuQ/rdG67cCyUHK9oMAVKWlBgQlzofvOFuM/W4jz1y1+MG 9cgqrlt8p/odjBmPQFHmYXRrqu9qcjm9t3pzBDgu4sF9qny+JOeqLvWVamn4tQmy+AiGwTV8bLYh OD8kFxbfBZjHcQ7cWJ1LWChIbB0bC+fWLlUwtmANeuKaQW+J8LJ/B80hmM9Q3Bew59kuvqeJ/AH/ TiIyozIRVXkO+IBqCu5lQ22gsIfOB9+66/49SCVHwkAhLq+94XJwGd8P4Ax83aiz4H6xHr3X42b9 gOspGAEZiS6rgD051gO3XHb0TD8kDG6fKUaOn/oBg8UlLMfH9YMe5JVniEHZPFrRg8lyTz35lVUw 6rEG1qLzIUfbvXn0BkomaLN6ljZtSuOrMwItVQ2yH5vRIzb9iBQLRkBykt/OaPHB3QiqxnN9+3Eo Ab9RF8FtQNKc+kBWTXXE8RMl3XwNpja6ncGNuP8ArWoL1mACKxV8B7+Ly4MZFcXvhRmPTEAhx8Wl 2AwWJ/hOYn2Uq+a0BCcYivv5qBWzJecDqlC4R7NfqtH9b+AscGrq2HZLwke9dKNjJ/sFi8Xv4AXX gp+SZcjBuq1VG+z2yqhdwq4NsD2dD2itNWhD3NklBTEWt+cIaoKa8++AMHZ5TRUKjxmRwzh6NlFP jMWjfVCS2/VQIq7awFf5KdmivKmevAaPgQEZJ8Sga0AWSaA9QfGYRJ8Bege9JRy+/p0U+Pl67KxA Jy8E7pwToQSaUAG777xT6q11PihASpSCMQdqweaTSMX2mwn/+eARwt2z7vuTKmAgKpFShdqpa512 O8tHXVdj9t4oMuCx90S2pt/OUAa3TxMp8V5/B9WSYIquW00EVfeUNsVxXKijOP69tyHQBuFDPMva pgGM6iNoms3x/oDtJ/eCpqYfPINvp7jvFsq4+Hwo2bM0PmpiBcrXCcC/Y36gTMF82npxyYeCH9Rc 3J3UftNCmd1uhLK6BgklqK2VWjKqnHewaf1GpwhgoN0C7KFCha4oHOr5WbSZHAuaMOdcP4AS1OxJ hKDcEk+EX9zSgzK41rlT3LNNqABN3mcK2r5zytB4LJTIxxxIJALFwRr01HrwnaPGgOvXmIC9e92h jIF868kI0bsRZF6AwYASZNbBbdPikiKlIeCQNGyd6mJp4HD7CaZ0k99MVOzZvG5EGvo6kNfYc4EM oY6NR+XT2ATI+URWjGfEg+8KchGgjJPz29jNOaIEGPQ0kXfo55ScFEefUR9jcnshTSmIL0CZHWuY Ztytfp/OYNlcC5jrIG+KdIMA+ZtmfJB+SuYOtIee0zl1URsS/P1eWIBAeG8gr0LK6pp3Wijo6nfW 0lH+U0dNFknlfEB+stuaaaFIh/PBwmlQ3T+BTnTkPJTO880SOSlepwRKUJVmRxI4LiCtVNVwibQ2 2W102pTgrifGEtya1OfzrAvQsMVtzYQtE0hy7maPyieQZI46IvEfsKzuNggvr6tLDaQ54BCQHu6h xXKuAmmJTe2RfPK6O8/y2TO+HWOW8l6FW+ez181zvs5VCfSdjIPWz1yut+AuoQqfe+bAWRDe9bG1 3GcRxaMV5K6BxfQ2O9YioAAqcQp7GswU/IFLS/J53QJLpeqDu77Ui8f0wLOP66pjowpfcGOUNrm1 m0pXee4llKBGB2WKAxwklOL+6wQyLtBHOb9+/wA0zH6fkkI/OV+juASV1AZKhXmsDb9cdh8+WOHZ vSsDeTlu7ULJfrIGahl4bBdHfec8uqMGvbIVYPvkuguUzWMfAxjeaGwpQCrRpvg5HephdhwXiVaU QTIeJRGA1FSnNEH2NCkCledvczV3boUOpAZ5jHJo26AqNJCfzfUqKMVl/MDBCmaKqAr2lJukU51i AOWWfXWw59znMKAmuv8NSlAhHcrq2joQJnIodH+6dnZ7AXBT5b4NKFMd9EY+rd4/lPEMsHkDwACP kkJZ3WcHZWtU+mNidF7LgOUct6AN4Uu9G4k6Z7+zoBS/60l7JPSga01RaPf8oAoCrPE2VLvwM4e3 yjVIauMFdQ1x5QX528PuwtB7jqLqjftdBsxQ93kPiHLHEUMhSU1nOpCsGFAAOkQUMpG9N+KaqsMO TChY64FDEnxnWN2DMYzUJPM2RPs8f2Ggzp1HCKGMHpGGEuCIhxGzZNY1gBLcGCPYIj+nIxnPqoeg 7US3JnUjej8/1CCPeoPjfH9G1tTP6cSKuoQlzhVw4tSujrKmGBc1jXTdJrx2vjozeaGqQQ5k7bq2 PswYH2qJUzO1caz7Xk3VsaBQqMWuo8aqdruEqjgBonBYcMf7bi9NtNvE5wIdaUG++NgWcJ1OwT51 xCfo6ymQbyuQG79PQe0FsmrDI+Mz3QgwOCdu+Ef9bG91CXTYjRK1zr0bQUXnKjCAjogiVFF7XBNK cU8jbvop4LdMLo9zL6+xeOUXIEdVcDciX916522KtVZ7bsAyCk4W0ZKAE/EitS7jC/V7fT6F4GXQ Js2BflCGoLoXiVaj56xCCRAqIzqNn0ZKiSaPbyP2gPHa2R4BC/tZgEJyrLdBu1XNYaz6yW/NkUDk 1mpve7lzHxsarPt3AMIQoPPeCE4F38EOjiiBtk4JVnzo/p12c0zwiHrt9zaXZoCQ5EGY2u36keC/ +/ChBBUYRtjatXWKpVXuc4AS1MlCbZjcv4MzPAWrQ3DMa5vQJsgr4KoPMNtjR80plXwj1ac9SwFK 8K7VCIzXdSQo2S0jkhR6jxWM6P4ey4ESvMNBg9VjEjzlQ/Ez5TcKpbgkp0RiEMkf0UYdUThS49ql 5Zjqzmv6jejxrcpeKKtXNIJSXHdBIAI70pkmJIXLA6DhwVnA7ZH9bGNwewSKJHpAZjoCACru3R8x 9byiHpQccCIqkns9RvR4vzHGsQny50aqx3ukayRfxiOeXDFtrfoBlORVKKDgmNLVAZvhOQLjvqRq LxAAS45Z2Cnu53umBL0RRXAOoV60o+DHiRxP594JoKpzIpk0brWNc5QzNFJLwfWDcW7nQI6inzgq jDabR2ygZM9NAsgWvFQ5kpfj2Ihx1/B9deYUvGZHai4hIOUQsHme/wNElOeRvA2vSvlNuzSkXXgb lNtgBIh45/gVpcK5Cs0ykAe8BuaR/JH3mYLzAyXgt7Wf3O8y4iF2z8K4kQrt8m0DJ+Q7t+Hk8tUh zhSs6EYBVLV/RqI8gezNZC35iuZ2CmQItQw84jlm4iU+6twvgc5Hfn+wC5kYWDA2YAbOVWDmAv2A uINj3cfC9aP+g7HwPK2OgOf0JudeKEHVRwpfcrjtLEDZ3BsxUfTeNYeJR2QczzcR4/E7mAKbxe/t iVdx3PqAAmhNR41jzuPb+4XhuuWEU8pxkBMF+f3UI8KCujhQqMmiYwNjllQ/mHBxuYUMHAqouffG fILe8Lwox5N+imWvvZFd4hrXBF7a70YoQX4JlOw4ByhBzZGJm9496FCKv01Eec3saG4onBOdKbAa z/8B7tK75j3h/HJrCkrxvPepo8CM8wGU4CyQ5+QVhEn1ze4BnDqeUFFJAYV3ZHwNyDKNKMW9eRMJ 6R6TmPaSpb1+h9wol+QUqA3q90IJ8jF4lCd4yxRK8KISlC2QVXh3VucQ0oncZ4eTj2qvOlOOqcfN JmpMu3ZLsLHx6D+U2a2PCSvHI5E7xT1MQLLwG/qoce+o3jslYg+1t8F/HKwBHji9AUk8gX21t6HC 0AkowXuuFN2nVrG3oSKlyzde3wnuOQK1jo1Aje8cSwCFcfsIyPn21SEMF5x63DvuCZ6w9ILbbFeV XQvYy7L5CMZqDU4jGWKeSUOBjsn1+Cl8c5hk56AOLQ8tBb6NCQeCR0mh4ALUtR7THKw1MRbHCU2I 5WC3J7weq35nShioSqE6uWdH8WDd7PrbNFNrVWMsUMhx8e+0QTWsaQa2ofr1NCNH/SzsVptzCLZZ cAOSNxVIy4W8UO8NtKPnuU68+OsoKiiro46A589u1++U4M5aiHD4nhIZcq/utLS8MaC7sPDIT9Ab 4Szn0aULckknkBGerzmBqnQLjKcTo9PIm8PB6oB29HeXKZdDxXWd6UpukM9nHYbsXLVVi/sCJurZ ec4qlC042xtvZ/hdghXqHmeMn6Cq4E4J5EGO/C60CbILeeAguoMz7nDXxbBcA/0Ny9Xri02gEwMZ n7sl0MV4oze4ATPZkq6P8v6QI4wpKz94BJfn4rDblHcKNVB953hNKODE0i6OyKX8doClpphqkG08 Fd72Un0HoPnkq0OwPKjTCIW34G2mpMYSfHdKuzqeYkYRcl2ZUjqEGLy3tLjcoU3YG1GeoLehZNX9 Z9LEPe8dSuDdn8lR84g0bsvaNUgogMx0przE61KMi5Zz4m3AfPpuNwCZVYpRgqh4du4MYs41ISiD ++MpPY0vWMeG983jZjOpSa6tQ5ncd4viQG1f/Q7e+IDfqG3i+WY8KRig3GbU3mCme0kyX1GeIXRv BK6I4MXfZ9XFe8MSd0QuMJQgTjuj2PmNAUClC9aaMm/uj5+pqOd3MBQknO5CT6EhlxQ4TjvnXmL/ jhNCfds8ljNTN8+9ESh2AZ5iRjvw2PuMieFVRqEE1SGgBNhWKEFG1bynl/i67SmjejOh8CFgdK1J 93KMDIUqiyMGeCpmDOQOkSm/TynWXNx3yzPjPACkY9uDVi4PSO5wvYrSz4hY7w0/n0tLLPRAJgJu cu12xjoMRg2gwj1ZMxEw11CgjI7ngxLkVsyg9ty3MY+8g+trMJKXM+vqjOB7/WQRxnadjyTk0XFC 81Stji2a95drVVeGEtQkm6eGCmM6ahxJjneZoWS1AYHsjYFUnvfXYvQ7WJS1r+gMbD1og7D0c4rg 6f3+geL+nZkXKNxTMs/kjnlvVDsP+G3h+RKXsFiUHn3h4c8SnCwQhYEMWagPHnyHdMCAAvjYOZGM b7cKZmKH2Xtbgfb4qV8BMgcU3rTwnSN7zb1slNtdPONgZgWCk4UNGHxnIyPEZeIWVUCdyQPzKDYU qngpX2dKMPgpydUWSFhyx4KTRR5YoG1ACc5pBv7muwA+0aNwuHRzoJNTBSNYa+w594fMmVJUwQi4 gHx1CtA4X9HCVaJeKVxs1LLRXSjUsg7a9MHLJguIQs+03SmLjg3K5tGKBYPfdWXcVck1Lig4mWw+ S0W5Zj2NUHjzyttQI1etj6Uic1dXB0pg5VBYi4tOv4PLwfPAFgiO3oSCp8J7wy8WURbHiwG0CCrD 4eYLNCHEdfBOCpTgBcmFR3o9y3Rp6sllL5TgLTko2ZEWgECCqg1cC9Ss1nXjqVmXOzxhRiDd25Dj rzJx2Z8kc65qSZNTzWHhMSxH9UNZXEfCCdoF60bFD7edF+KnrlsuxE89ogaFalS6Bl0FztopbJ2v Ac9NLUFvZPkEFM6c98ZTJB6Vp3wv7wXo2HricwGlCTKUl71oqvMOZba9uhdlgoPq+gvFKl2SU0Qs yJqFQu6JzmcvdqSSnNT/zmNTUKhq7r1xGAIKjO37Q9qha50LjOjopr34QCCVSbX1TPWFeKPfjQtv OgXnFMe251pRKGx2HwoU6ojp6mAZeeQBl1TwVtlCLcTgLgGw7BjAhVegXOtcxn523O0CVDaQFNQ0 D+7GkRwkvzFGisn5PQfsKDiNEzN1DgE+45UelokqvX43UsfTqw7jxlodNb5MPBHi3DshEFbdU6qe BCeLkLS/8bZQ29i94Qt1SoLbmciha4M8x4xzUMe2u6Vc8vHKndtzOJ7WQPLxkpznki7YWQGPQvEo D6792fGwULL73xYuII+OQQneP10WSjS5/rYAQffbmTtzdO5d+iVaA6pl+qlfCdcHFPhabbOF+iGO QqTkSRDLgbIEWsDaV57hwlOqPICqvAPFcd4L1Ug8w2XZqP7pWg1xQEe5LeSoBTzKGUmuRVONxGtv Lhv1vVweoF0vfkqoU+KZWwsUR03wYN3myB4oJeBerMbgZOWGcqa6C5n6xi5hMxn+fraxDj3bayHa F5z6QhqWr1upR0czLIWSekEbvDgqyTkKgdcQJZEnomwNcIe0jjmFUtz+oRAIjkPvDQCErjXPz22O KKRoKlaG98b7B6rZ0SbwEXNhVZ57CQXYnH5nrzWh3LtC8QxLgv+z50mszV5hTL/DQ8XBGrS8Uq9S bOVRW/fdQgFm5t/pikdjKbbENeNtqDGgZ2ElQ8xvZ54H7P3MQZncYkHAEjLREVBayzFzlLud3LdO qi/gfe+tA57nlJ7iqE4hg0L1kBVcp789AKV4LR2CWYtr61wYQW45lMZ1JCikIOmoiYG5n3ylRmHx 80ONwmDdWBy/51ag4cnPD5Uqve7Kim0WcAhw8tk5nhiY46u4NAOrAMrq1gfpGEQYdN1SC/wroBD8 dkrXu027Avx17xcUbAnvrQ/wLrRBD/A2w+Q5HCulk7xKLxSe79Xehpr3VANK8OIipZ871zr3otBu m1EUmsH5d8DDOo9Sm9WR5is5d0GbvXaG7xyJu8GtSTaeR6BWXqLy2xkKPlqdD/ZPsDpTvzYuYako 4dFlIC19cAfPXHO+bjMP6QQUPCVZR4394wiVda9C4RwyU3HK+Xqm1p7LXvINHJm9goN03R8KFe18 1MMayDfc1MHduHSRPFhS64ioFXSg54kDegKapmOjSmJ2TuQt7+CWWQGV+ExX3j8NvgP8zc/2ur/y 5mPDm+enEYHtubEUUAmq0fM0X+CRWXkLyy2wdeOhyFnHtrUU4w0oc6DDoiU67nalFrxHUqBwb+p3 wA0Gu0C1C/eUrLyS4l5dKAGOC8rs9jaU1a0pRAsYIh114S0FtcRJ6yapN2izBDofeI7e+a3wmpDz Dja1VytbSxv4LaGQLulj47IPKDz469KF/CO3tynvQsjGvgNldlwaxT+D6tPb/uCIatFblZpF15rk zyBnaAOb5xG1jWvOq8Vs1PvwzGEoga68od97RGBrQJsUXR1iOW5v0yZ7tHwju97jC1CCd6B2ip8F QMm8CeNjA36m9xwpckHV1K3pmav3xglWaUkbbH5vk3iuzClDcozm1qLh+wj255B9PkSd3YdPb8Wz VRCwwU0LhUCTjhqLMuC3tu38ntuAALo3b6MQlGsBUHg9ykcA+szXmmokbfY2w+YY541EDce6QyH5 XnujiIt7NGlTUtCmhee9NwA3Kq83lGivYrlR3Mu9UkA9Fr81NxbUPZo7xWOhgPqLZ8VsIEEdnU4p qtUjHDzHHFTt3osbB7tNpMs1LsTE5HYwLsjkkSEovIqmu7Ab785vxMAcf70R6XK0CWA+Cm7od4h0 BXfJ0ATvRFK8N5LXJH+6X5k22b04uFR528THxrqpnghMKfANQsEvpb1RpsptGR60DXLloWyBpACF 6LV0Nurue8QGSnYPxkaN0eBsk0bvfjFSYijmpjMlfdqxHhveREewQiH+7731m2M9NrxVXst62y09 l3wzSfQuLQGue3xug7IGbToy9XTUAKOj3nhtw/WdmUIcTgFc5Hk5mOHZva0b4JXgrl+Q1746S509 crftMTDfn4VwiWt2xKaCtcZuDHaOtfG4zEYtxGDdqIXoWbMbtqZbRhvOdUdMQwny2qAMwVlYW563 VD7ABRhoG1TXDzge5KL7E7eNTCeXo1uVg3UDH+l4io36zq3v3P4is5/tjdCHnwUqsjgWZ+MK9LgM lOD9YCjBC4UbtVo8prdxzQS62DYAgNb9yVg5rkHmugn2FKyWowM3Ym3+wueW0Xdcq6GCSqClYVW7 B5BQXyRHQ6sa10pxvBhPdRIo9dXhOVW/ATPaurchcufojA1r1+M/UErUG8k8frJKF7z4uxXexHRZ BSWws0rkZdsKRoHrSODmA+mPluh3MDBipmprnUFvrqo5ADAOcn2hrJ7DAWVzLXqnOFYKeMrieVMc hSboDWHpWmcmRunrBmXz+js7xaUYrqfJ/de4dIu/kpXrYXH5tsOiPeONRw0xmnR/GiowKFflhmR9 PdukPXaOW4dCDVT/TsJCDSgkXTslqqWTedbKLT2KNKJ2am/EXFs927Qpro/mtp49SwFK9tOISEye EU+CcnKvIZTB9V7EKOLf50MWlt5ZGUM8OHPU6ww4pOPFEf8O9qRHRXIXZVyTfhTUNN8pnnUBJbnt DCV4+QxKUBEsdyEndtT+95kSC3XLiNIqwdvgeX+33OXb/ti53jKZXLxgranv77ZmJhbqtgyU2X3E UKJTAsWzZnEr50AiJXzrfk6JUc6qh1A2CeVBuZcab25NZR4wcbsEyui+28wjIW7tkqiRPPqS96cZ fOeey/TqqEGTO6oyj1TtVnsbA4NnCbw3HtVQLS2P1B/1dduLsAYUXifXGz1TGi7YBYq5OSqMZ2vr gK9BfLrXI1OmKrg1wXW6nZWxkAO+3otR+YpSIMlzCDPv3Hk+LZTg3bFMjcTO+XrP+vO1nqPq0zgc CGjpbs8Ey/1mIj3X4zIZlINrqpl37txPkUkWcVQylBLcwaRduAVGGkAVnLkFTdX5bQFq4doGbxK4 3pt5n73zdQPPUfv+gBIK7m2AaY6AwNUa3cHYwY7byCuAf9853hHofQ0AOnisIOOjds923t8EcEmB kzjQ+Yh4BjrFBpzcNa4MSsc1B+4LR7WQNtx4lgKU7FZ13q9N3zmuwNnPNvacezDoLfDIZPApHl+A QkEsPY1Q3GaiTaStU3/UMUyZ7IXgRi9R3a/Mm93uv854NgJLgpcMHIGXCxAvn2npAWfrGhDFcJs2 816BS4rCw4GeEYKBHFR5g5K9xgDLubhn4blsq2pPpFH2Lq+h8BqjzZSl5qp1CjnsKuMLKC7HuxQA A25NFUJtjrgpNTX0fT4Nupieep5lIESoo26A4uieFiibz5RHgv1mok2AxGQBAj8FlNmlcgFs797W gr8s4B0ikcGoiTt4zbgCHtaj2DwEEtSHBX5QR9/pOcS61iRDeMwVV02AAuHB4cB6L9hMwbqBBXVk KUebBzZ1bD3PfKuMLzhoXZJD6b0qQOEFWMepFmKXXs2n8IqZW6FQSGDTURO5C84clS+9Klqh7qSj DJ7dVXqbFQKRngtXiHQFXDWkQFriysseXyhEphx1BCW5N6IQ6fIIB5TAOizEwDzmWniewuONUFBe dBdAU/itWSYUO5dVU0ORDO1tijK7KQAR1Bfjog/qbfDMRNP7d0CpeuSBQtaN+2Gh4BrTUUNxq63M HHv1ZFG8qnaESpn7ybXOMvOoRtAbLyGqrlyWanB/SFnA6rqMJxXa8UgYP6trqoUKA17Tr6DHe2So oHk7QgUKr6bqWq8EHnwXQEg6EobHxAEGeG9tUH2ANkHd8AJEP7iZqBDl2mBZU4DEhEJZQR/bQOm8 gLJ6RKCsQ5AVU/DTezZRARbmnvqyNaQN6Qh2wIvfJWAMAqnMG2Juaxbqy7jfhWfPeLpCR0DOrEex EUe8S+BtyFbZlLKrad5mV178/ikNMVzvDY+m7ylRJo9rltJNrsfvFPe7QAlqtJeC+ysYNe98P4/6 +y+Xp6eb66ff/fbu8u5w/vjn0+t/lYf785u7y8+H27cX6+Hu/enm8OaP/MU+17vL96cfl5v7V/r7 44eH0/EfKe8+vX8lfvfdC+Hp7nB7W06Hq1fCw4cPL5Trm6fH7fjhuePbPx5OP3zr+fmQ312e9Nfr 44f/9XNvV8f78/H0P08Pnx5fev1yOjz+/v6an18/CIt/7e/m/vyHm7vX358+vX/32ur+cPrpH0if 7q//9+fT3uH33xboy+X54/HuuK/QHw73P7z58rJKx/vv/vbugn8dD0/n+enm8Pbi3z9+t/5pb/3l 8ur29O5qb/bHw+PjzXOr9z/Uby9ub374eK73Zmf+dX04/fj8j/c/NF9pzTONf+20538crvbJ8tdf /2P/g5f/5K++/se339rX39pvv3Wvv3Xffutff+u//ZZef0v7bx9/ejyebm/uf3x78fN/7r9/eLi9 ffhyvP7Xb/R/+ullEa4f/vRw/v391e2n6yMscv1w9fT7+3fnw/npeY2ePh4ej3DC4dPtGZZ8uHz+ gW1+/uHN58vj389vL47XN+eLN0+PN9d3h7+/vcC196Jpfv3z28NPD5/Ov/jjvav9rx9/8eub68OZ PXo+Id//ojG7/eXl298G8+XyefD57v3x+t3d4XT+6+GHl1FfH69u4O13P929f7hlOZ6PzG9eJnx7 83R+d3w8nA7nh9Mr7X888xNfOJ7PcMLT7/6vAAAAAP//AwBQSwMEFAAGAAgAAAAhAJyoTDoOAQAA lgEAABwAAAB3b3JkL19yZWxzL3NldHRpbmdzLnhtbC5yZWxzhJDLasQwDEX3hf5DMHSZOJNFKcM4 Q0lfsyiFIaWbbIStJKaJbWxlHn9fLVroQKErIQmde3U329M8ZQeMyXqnxKooRYZOe2PdoMR7+5Tf iSwROAOTd6jEGZPY1tdXmz1OQHyURhtSxhSXlBiJwlrKpEecIRU+oONN7+MMxG0cZAD9CQPKqixv ZfzNEPUFM9sZJeLOrETWngMr/8/2fW81Pni9zOjoDwkJRMDeTItzYPvIbIgDkhK9nZCdy2bdPUcc umZJ5GfOpXtZ4Ii2ewtkNUw3VdmMEEETRpt4xIP7I0TkuvcLcW5dlX/4aPJDVZQFfSsVxtOP2qs3 /M/jiREOJiHrjbxIs/4CAAD//wMAUEsDBBQABgAIAAAAIQC1NQuStzEAAFOdAgAPAAAAd29yZC9z dHlsZXMueG1s7F1bc9s6kn7fqv0PKj3tPGSPJF9kp8azZTvxJrVJTibOmXmmJDrmRBY1JHWc5Ndv owGQAHEhQFGWaONM1TgiARBooBtfX9D46//8eFgO/oyzPElXF8Pxf4+Gg3g1TxfJ6tvF8I+vN6/O hoO8iFaLaJmu4ovhzzgf/s/f/vM//vr4Oi9+LuN8AA2s8tfZxfC+KNavf/stn9/HD1H+3+k6XsG7 uzR7iAr4mX37Lb27S+bxm3S+eYhXxW+T0ej0tyxeRgV8PL9P1vmQtfbo0tpjmi3WWTqP8xx6+7Ck 7T1EyWr4N+jeIp2/ie+izbLIyc/sc8Z+sl/45yZdFfng8XWUz5PkYvg1eYARfYofB1/Sh2g1hDdx lBeXeRJdDG+Th9sNPru/XOX60vNcbeQ38qVltPoGrf0ZLS+G8erVH7dy27/uX11/Io9myQJajrJX t5dDqPgbdpz/FQawLodDS9VGCzQFCt/SGQJaxHcf0vn3eHFbwIuLIcwyPvzj/ecsSbOk+Fk9u40f knfJYhHDeijLre6TRfzP+3j1Rx4vqud/v8HZZQ/m6WZVXAwnp1OcgGW+ePtjHq/J7MLnVtEDfPkT qbAkn/83rzsmAwUK6YrfxxFZioOxd42Jd40j7xrH3jVOvGuceteYetcAHvecj3PnGkU6p7O3Saq1 dnRumXNSA2fPqwbOnnONeYTL0nkUX5NiGTuXvt3MCr8KRZauvjm3//ZhfR/lCYhLx2mjXDf4r3/G s7+QSiKdzm1z8e7rxw+Dz1lMpXgRL7xqf15G8/g+XS7ibPA1/lGQyrkgXpCrnfvyKR3crqM5iIN6 J9ylw4fk230xuL1HqVJv5nRkWZW05ockx1GInT61CTBa7X+zRKHc6cTytY/xItk88I6qDHR65F5Z 4aXT4+bKZKCaz5441lS/edpck1BJ882pY031m2eONRXZcWrjiTdR9n2gWwhT2/q5TpdpdrdZ8jmt L76pbRWVlbWftS2ksqZuCU5tq0hilcHlfA6AQjM7tjFXPGOubxt2xTzm+rbB17nI3IqNELVWJuZW nPnK3ISNwb7EfyYEp28nRpGzP0dZ9C2L1vekLSck9vdNWuAOKIq+iTsOeL8CRJrHA207Rwg0nfrB ZgNHYZkKZ3FjngpnuWNuwlkAmZtwkkTG6l4iydyKjUlLCYNTYpITUxuflk3gDmBswsakWmml7gh+ 0kqtbyOEKq3U+jYq1OTMmE+H2oqNELVWShZRW/GWVmoTNmmlZVS1CW9GVZvwZlS1CW9GVZvwYlSl eitGVVuxrc+Sy0RGVZuwLdGyCZFR1SZs61PLqCoA82NUtb6NECqjqvVtVKixWMmoais2QtRaKRlV bcWbUdUmvBlVbcKbUdUmvBlVbcKbUdUmvBhVqd6KUdVWbOuz5DKRUdUmbEu0bEJkVLUJ2/rUMupx XW1x1Jn5XqbWtxFCZVS1vo0KNRYrGVVtxUaIWislo6qteDOq2oQ3o6pNeDOq2oQ3o6pNeDOq2oQX oyrVWzGq2optfZZcJjKq2oRtiZZNiIyqNmFbn1pGRUOzqKp5Mqpa30YIlVHV+jYq1FisZFS1FRsh aq2UjKq24s2oahPejKo24c2oahPejKo24c2oahNejKpUb8Woaiu29VlymcioahO2JVo2ITKq2oRt fWoZFf07WzCqWt9GCJVR1fo2KtRYrGRUtRUbIWqtlIyqtuLNqGoT3oyqNuHNqGoT3oyqNuHNqGoT XoyqVG/FqGortvVZcpnIqGoTtiVaNiEyqtqEbX0S/90yHohuNpFDx/5WT1NTE3fXFevUl/guziBE I64j8SP3prgt1twW6vRO9tirNP0+KN2jIpmOUN9waySZLZMUDdI/G63bR+jg3tRCEmyr6uvv14N3 NJKguXWcXLV1xU4OoRlilAUJYcCIGChY/FxDqMNatLFDBAYJRYEQG+wBCcx4D4EULByCVCbxEVAX I0TYY4yLYATEf0OYzoKXGY1GV+OzYybeIB6ENFJEM4x2gb+83DK+K8g31ynEphwfMdYxFTjjzkFT gfHknIlDY4nphIkqU4nJmKNRY4mT84aOHo0mbHMwtXF0fNLQ06Ozs4aeAr2YJcr0lePpSUNPT2CW qCPS1MbJ6bihp6ej44aenh6fNfT09Hzc0NPp0XFDT6fTaUNPzyajhp7CEmvo6fmIuwtMFDs/GTX0 9Pz8CHsKbAqNIFPkNHoAeCG6K2KIWJtAR+DXMiGRbcKPL5slPIh/RPOCTlyyImxHOKlkIWiX8RxE lhHWy2qxZNfpJksg8AGiychHqjiyqwji6TCGgcWR1UqSGDLxEXJ+/gvaQNnAl33+65pErknPWJRZ 9S0aagYtCIFkKKUaxBWWIQKKic0xRnSJIqqKzML+zSIIDPudxHkpAmwFkR+652bBdjw5enPyhpKe Efl7HK8/QUP4sdXmgdIc/vG+FIi4IGCc5dt0U5Cp/fDnkn8e1x2fOfjbhhQTIykYd3VKijMQL5NL B1Iky2qYbC/0pQ5W49RhgYfCuibr8jJLIHqPzvh1jn8T9ldajygCoCnkjZaEPjISmmG3Tgmt2Uz1 a04kNJtxX0JjNW9CSwTmsm0bAh8bCcxk6/4JzGbal8BYTSHwbFcr9cRISIbO9k9INqO+hOQyVd7q OCG1rN/Fyjw1EpShj/0TlM2sL0GxmtvK5FJiGxankdi6fZsZJPZPSDajvoTkywxXZssd5sy4zBiE 3T912DT5UgerKcuM8is83mZJnRuJxqxL+ycamz1fonHQIgu7EtfX8I+0HTvy6vwebAJz0D2IRmAw CbBDHmWEHlErFJKzQoOy1ACLISCrbDAc9jI8WIVe03KSBQUembkINCga/m7o81fy3mrLGGARihzV DvIY9KYelrGKOIBitmRWj9nyPWpocG4INTpqgFn8iOgHoeB1vFx+jDK0kaRrIIyhKNHx6Nsx6LHw r1pTs7Qo0gdz/QwDzLF5XQNAYrEz9CcZhJn2sIpnccai3g30/5QSe6mySiBiHp8bloUr1R37VuqM Y/xP6c3vVB3DLsEBD+yUIiuq/tbWQqPpC+ikUQq5TsPewlAaNgyJ3NWQosQ+HsZiOx8PFzTO45Gs kOV4iFoPUoiwQx0cwGP91ODBLXwlz8UYLHFXjWbI+TKOUOwZ7ZByCZ0hUi6htUTWiuhMkXIRrS2y VkRnjJSLaK2RtSI6c2StiM4eKRfRGiRrRXQWSbmI1iRZK6KzScpFtEbJWhGdVbJWRGeWlIto7ZK1 IjrDpFxEa5msFdGZJuUiWttkrYjOOFkrwqyTaJyE3QSNZuSEBYUGyCPQimonxf2F7EtYZDxi9mmy kZisnKwR0Ya5lR3sJoWTAKrsuKOPdbKDSRuN7Lg5Ho+umW6KoJQ4VfCkbGXD/J6++r8vRCbBIFsB V3D/qPZLei5R11vR+WKyXUabIv0Sw24M9kVsQ8U0/IyjLCw1ZiY+cfC3XAlBWGp8NzILaZ03cpEg LPULSuvFkUl38MKyFITAKgBlLoaLtHJzjkcj6g1rlIscEDLRAnAo/Zyl6d124kb1EdBDzUHcVBBw HLAZ3/claR+wmV5oad3GstDaITbrSNw8vhZhGNNxdiODVPcZkUHtXWcB8pjw2SToh1pJFvRDvSTT Bq/UJJlOP9yJDOJWFIsQ2k4n0xvULrMigSHfxnOSHkgxREm2QpPM6tpWyL3GW9rWQN1UPetE9rb3 qiuy19c4GnRMknhL5jFtfGCtSDDIaSX7CzHI7UbgMr2HC1z46xWGBuJFjTch4qV9rImfeHk7Onlz fEWdBMxVGsRLEC9okNZGIcsyVRuGLBcJ4gXOCTibsGSdkvuzthAvavQVES/tI6/8xEuwkF8MgztR rzkF8aKnCz/sILkTd4JeuK1jC/GixiQS8dI+HjGIF8l+zGdIWgvy/hrEi56NgnjR0+XpxAtfmVuI FzWol4iX9gG9QbwE8aI9oCnL1GDsNsiOlsFQO0Ev3OS3hXhRw9+JeGkf+h7ESxAvQbwYZIfuHLgs dg/Kl8ZD0tqKl6slXNKBifLrgdn4hubQb4oh8nUNKafixzzlgRiqMD6mZ+VRLIN1ivykMVIN8fT6 +POrdPFTP1B48bTj9Jys+SaHAyC3JIFHPZnHl5vrd+NXqxQs9KsUnIiKVxMKDN6NB68Gq3QAhcgf Ukw3o7yt8r0pErUxvFQ9BY+bleewy5MDJPp3BQHA2tkjMcDk5aAgtz3oxiUG1zqvVBYZLORAYDHN 0hksviAbYoSlM1jlsN6uFqTjVUacOgfGtMAA7sJg+XdweL5jgKuWistl8q3MlEBOjJAsBYybGjqv 56ZrdptJvc/8lpOmiTCtLXOGBo2RlnnNMf9ClZRhzA/Vla//NS+FPY13h97xxVhGYfITxt1NMF+3 5hkuF2/XU5xv1nDB1jxL1sgTMFifWbYLnHI4OUnE9ABXU2ilTlVsUJbTrQoQO1VRysCygLk6P7o+ Z9zHnH/lzMI/qonn3Fi+lXaTsylmmLqHWH842dZ6P3GlTQNNGiWVTAPN4iepIj4AF9OUGOWYJYqM +dnv8nV3blNYU7Qxzknw18WrbCcg7mbQWy35+EZG3uuWkijpTQLGWXqypSZl5BAXFFuR6l7HlyFr gO0k5Zne6pRJ/eo3OiTMGNEpw9JUaXVJTZABfdNEysalqOC58giWk+R1I02nJHm/yotsg4FguXap SQWaCNRqrR2dTN9es0XE1sgMPtTpMEm42ic8zAvXaOkWACkwKEs0jRNAw3e+k8LyEVu/hmPmOuE9 vZmenTE/rsBRjYKLA0ZgdXZW2cBOhusPOyXj5XqtpR55rqNZSyR9ORqdj25oi2y06+hbfJXF0fcr ch8aPffFSFJHPTz/Qo1iQIjtpTIM9J16no1IEHgD+sWOqVCOWEyExD4K7yoEMK4R4fG1Kp758Wyk cGfUUY/flNSZ7IM67KPe1MF6QBUf6pQaDVexVWKQN6hjG0/hV0e9fXdoZfch1gQQU0TFgdx5cCqL /aA59oj1k8zItoNUDztUgzSFD3c8SGEUpRpTaaw8waOo0NBnMHQfdUCZ35sky4v3K7ivVU0AUREB Sw1YMZ2Y5MuF8ofvtFMsdke6QnYTyKY4lpCXI2srg2scl2VEIgD1HY92GSPZ6EhpKsgjmsZ028Ur zKCNWcUpNHAun0SRKr5DpwPc1VTaBkh7bRha57PZLJTkwLqOJpsO0iavGBmeTmxZx/kksux6mZI7 vBVcx5/rBNY2C4Ku8TKf61ai6k0E9yLW4Tw+bOp1K02lMj74ytS3r+Bu9OUt2B6jYpOpfabvB1WB pv47ShZzPw2mWH67cZ2oZRJ17JibcZIpcwlW2S7/2dvVn/ESbrW/XCwyuHNemfOYvR9ErEBH9CsT Dd9lkCL8cwaCC5JXTc8psLoH49k5hVX3Yt5iKHV/CwmPiZeCvn6E+z7hanmCuMjLy9X8PoVz80Sr IQ9+oFkaDsmUWUh+sic05xUFBiLnTM7KQ/YGfTDK5wlcZ0+zxtKP5uJvKaUarJNWQIjPy5cYlrV6 lKycloy+72xW2NIqDSZegwVFsMrozAwPIjaEyYWONpNEz0I36XKZPsaLd5CIPiOGAmWxqiWQLo4s XW4Kc3KrMUws5q85g5T0dEXADeP8IZHrkDtui8GQO8gv53BB+k/VEIn3k/OXupllifLKPHlVmjzH oZqll94Xg701SAja266lQysRp183pIPXiWY/w57jm1bLxE/8WvqWLtR9i/aNvGnVtzr/iqnXK5FV e0oEl/iIfnmHHE0GCWs5WSXa87JIA+F9K0p0NUv/F/+cpVGmGjmxl+XbVn08tNkyC4HPGbESPkRF oTH3IiWkEkgNJX1gZaMgUpzLVFJbrHxd2nvVNFSGJI9mN0J9WzPYdHe7gZER3kYPa9g56igQScfe 7XUJtd2cyQC+wsb8mIGkzfTjE97vdYy7n+V/RHClAMkuq53n8m0rKnQi0IwQqgJX2LlGjpKwEkCl 0Q1zL3SIlYjx7RP6mBR6ggCJSbgRJJOlG2VN2Dw5UsL0DfVZx4dIz1r3ulL3iRmHbOs88mBLsw7p r2rTIk93YMcSla8pU/86HIdqlMJxdG+IEscBWZI7nxA1/QYOpDn/hqNOUGrk0kBYhGSXK+tE4WIc CAaSPL7eEYeAuaDzGbnaLJex6p/A0bB3TUy/daA8yD5NguhaUA5s6q28bWQkdCAGaUBfOgiFHY0T 3f4wOkaF7cdpkBZsnM1CY0fjrDmdtx+nQZiwcTbLlB2NsxZXuf04DbKGjbNZ5OxonIbYExivSyRF 6VAk/HkNNykkq40KNVEMlW+bBJHvJvEkvkRxfAYJxAfoIIN2M0QCWYC42yxVPgaD8OGvHdIc7maI iGY6GqNB8JRjbBY9Oxrjlmc/xKVqEDrlGJvFzo7GSDDQlvNo0MNQ2LB3XYsaPcQpQzE62Ptpxw0S hr7cgXwxjItHj3U2LoNYYeNqxjS+i9EwLh731dm4DKKEjat7QWIYFxIQxH9n4zKIDzau7oWHYVxI wO3H9RG8yuCMNdzNwt7iRdYGE842NpL11SIjxpgCb0dCfx5z3YG1JP91McQr1AmW4efe0J7FHMoo yNjdSa3qlvcqtaqNpxK5ddyv2wSNsKHn9+Vdsut5Qe0r4iDhA3fJEvJIEqhLbWiSAaBuyaiDgdJr Wndi7NY/TlfFP+OZYkygbwb/Be/+orUJigtqB64F5jGvH70g5rnLFQkU0LwxuCNgGlsFD9ARvteH TzL6sLddb9bi2tkSGn+Co4tEbOhiqMg7FBrkZdMYdhaSpPfpfgZxR4W1sjZJWMpBmatvo+WmiLTe V+HV3gisd0RWwVx1Q3v1pqnLvqBGXNf8BhYiZe3X3OkXyG0BcR9qXCB7jD33igOb0cG2OdZVmhJu N7MiKTQeq/JFE0XdusxiqhTzAQ06fnytO87VeMZi53sQHEME0hDMQI7Ikyvkv5InR+BeuoNk37l6 cgXfD47eDFiJgf4ECxYTNyTfdQk9yxHhVHn8CWIhfTXeSScV0F1JJxXgudSl1GtyCd2lJ1IJnr/T 3IY2wZvUBs+iZW6DJ8KxlNClvpa+wnnb3Max7iY6qQ3tZSdyCd09dFIJbeYluUR5BBLWAEw3Yky5 hO4SOqmENietXEJ3BZ1UQnupklxCdwGdVEJ7x4lcQpdxSS7BbhcAqcyZQpEyE375XE2cEwjBpTlU f0ZXsMJo5tRBJCgCebpMFkREMEXgekT+Rx5QVeAG/2NE4fWBKrdE+mGsLr1AFs9TfEkfEeewEBtx M2If4IuzCqXkwJbRGreW8jvzqzSDy69QrLlqUNh5NpozUFl4xGaxnMwy/n3IX0KFOCh+WIEpfmLl Sgsqssls2aYqWYDVGPAXQwkVCVFkqwRdRnnB6Ymr0EwZJ5VWHFk1qdC/fpEF19l1ujStM+fl5KhS i2Tr+WriVGtYTUSS8rVuNjWIdOnxclrF5OJsXEweZPGTHrLg8qvbM+5cPbqScxuiSKz7rOmZOy9P YQ/wo4jI7n41e7Y282ptMnyCIIGLOhKwWB73YQUaREJrmj/LBQw7L6rEBM/gP4CyFBsCBreqzKq3 7SupIarMLMNALSIMiwWVGU6j627ok1SioDIPJXpoU6HLJYLKHM3Bpg5sHN1BID+sMm+VGbVE0GKu otXiNvkVc2HLLGAgX8H3AA/hvCcCSiovFj8ionCiRkjwxMcow1/ouTMUZdsYvAWvFFFfa02VeMNQ n4tkQwNEdZsty87Qn1SZ5srqHpRqZ2WnZ1u1pOTtahMuVwRay/ygD18tDc5cUUl6GcpjC8L0WHuc gVgbv0uzXy4KpIAW3dRqccXIi9Wtfo8Jq2J10Zb4DMQeDKElWFZDuBSwrI/jCmCZ+cECWK5B4dEx uz2mMHmPgn9JUg34fUEEBjKnawf+pWawjCXAjPus4bTqCmnyLT2D/QDVC5zeuk/N0WovoAs/KCsj C7+6LdCeCGp6ppUQj5zjbLQgTI/RGsLgf0Dif9EpJxlXuSvVxqnb6c9EFJeSw+BSJf2cdNlPiKI9 EXU8B+e5az+DWkHisEXiCmuorU89qBX1sLVrEGp5MjcFrbHXIWKN2SMN+DhoFEGjwD3HsD60l3g9 gUbRZFwXoqsE/Chbl8Z4kYkmPIo4TOkhQsjUkBZwaRS37ns3QDdFsTeCrR029t4Y/su72xD9VMko 5WM1ZLgsEq/CLKXLQqft6BL9IOD5nJnDwmyTIh52EjdZcVJ7CM95wJzOwS/gB2/3vryinyHxfDwu LZSbHi8rIUKMLRvRFA2ppbnUY0lOIQev9ASY3XG59SsQM2BpA5Y2RbNwLB1CWeiWZcBKAUsHLB2w dMDSw11hackwWVldnffp/sNq2LiqTAB57QAQO5kDGMZ4AIiqa8xbYbC17vL4So/RpISzNXjSeRXu XzmzrqKOLOF28N0jYhGWQZXfhXfcT1Ec+CroSJaoqoYkw4k48I3cP1hdC9ZHTo5WErGK/yjtQhBp oIuiZ2qFKSyIax0hJihoHSQsGjMBnIQz57L1fQTXdVvXx1Na8BkscJNxDH49maWfxdlrAp+fwlEA trTk273heKpDB+ju+wwcDXXU7oC30F+gDTGqWc1r9k3kC3qzWO0Qf1Ce6tPAoEiXypOXNKAyjPuW qswDMPemtHcOXAO1946XrNoGW4jbkr1JOast/0oNBbHSdxt/W9ypZt7EOPMBx5363JtYJhzcDAc3 IdmkhMRCriOZHk+JO/Gg3eHgSRcvu80W67SxWeBk8/efDZrclak9IElyfWiVT5csGBGUCWb4eijx 4SJJG88188zBYUkd4en9QFv5P5qw5DOAjDCVZcR9aaUUbNf9dm8gr7omawsW6jVE65ss1EQI3m2W xiBz9j5EmdttkCEyRsbGQVeQ6fGUuoLOKmU0Bz6NTkFOFlIGamWjrqrbAI5FqagasCgVTvUTuBtg Eb+DPVVjZjdDLEJ/QoBno5ao1lWksc3Mp8UkiMWcjdw9QmZWoygzT9qoRVeKPZCnCchCBLTgIXhO xANxsi3xBDSM1hWLff6wLewdLSYVJ9dMBFzmPd9geuAQzwAPBo+NceUcPofAcspeIbA8vxiGEI8a OD6oEI+WpvaWyJQI72cFDOu3lxHk22Cz6wAY1ty/5KMl4HZz/245fwdnO60DdBLv2TAPLxpyksE7 RwF7pJs58PAMh+Akl2URwCNR7duBR2N4MAePIT44gMcQH2xQHfp7J5UY6mqMAMR82Q0ZPiw2VZfq VuTj0oDNpupSv5VNlW1cIBno/iRSs6cZSgh0PiGMPieSHzJsgdW8wdDVDJ0bbFu2yTebsxFKUqF8 6LaxRhK6wBvJ0NpAUTM3HrkQ1MJMLtUPHG46LGmX+RBst5pIhu2VwYOnoq8u1wacbh5WxhtTr9Ml eR3CAqhXE6IruHVcCpkNYQGypS+EBcj02ENYgOjUAakgGsdYLAD6HIHB22eyFrGYEdm65K4z76UW Z30FTmzgxqkBy2bsUJ/uZCIxegFM1cBBrZOeCzzmDpy1za0lT9Ii3czYUWq4/rUfiIfMs5fpsB7v 0BUp9w9bvEghoWqO414oLUSL8gsnRecpy1W92hc+a9XsXaQsl/R/4sPqwGXzMhO12D0SNeRDTRna s7l7t2+YRCo89/Y3EJ3NEquCKl0IVQnehuBtMCj0h+Vt4EABFywAcPhbE2ydqXTl9ZqwFR5oym83 vQVt6xxkkh3WM05k/xi7MbK4wWdANpSSVuICEa43ElME8lXGibatwrd/Cpq2VJEwMFp6TW0bLaVm gSZwswzzYuRs8CL0jEhBfSnXyy7UlyPNPQDwwa1Owe5cfRmNgvoinin3kjpBfWHqzfvFxRBT0jCX kyVaCtWXECwV1JegvgT15WK4+BEx7+xsKTphTB4pm7Oh+fiqS23Z1eF+cQ3/usUd5fJ5Gmf1D47j fb9P9QaRks/InRXUwr2rhdvwZc/UpTY6JcxPUB3h1lHVyEUBT7+s91pTQ+eqY167QKKj0x67UB3H O1Bxn73nC2RCKx+QMTMoC+sLmUGDEhWUqF4oUWhHFq34YCe5gsvUb5NfMUf641IPaspFH9w8cZYj Nffu929083QQGqJz86Dk0zoTnw3O0nkrXsCwO4eXan7OTk7bHCC8bAu0ToZEmKyih1IWoy17wIzZ gxMqmWdRHi9+X3F5jWVCCvaQgj2kYGfIxQTFTkZMVTGdwDk/h1N3INuJdSua4dZOTtMmq2/AbNFd EcM5y8kxC2lIVgt4Sg4dXAyPjzAQDuqtSaZZ1NfLf+z5iASRstwm3OKIhFjdZpI2HnEQG7DYpJ3q tzJK9/7wbxl/A+tNCDOpHwwQQEnLXH62+TX5DMTp7ZlhtTNA62uM7jHNtMZoYeWBCHwxhucXMOzO tYCDMTKTPb4UrLjl+xpHV0X8sE6zKPtpxO1CEbpYAnTnaks4+kxgogGqhqPP+zv6rNhIAWe1t5EK ERDWzDVjU+6bKuocQB3mEzfEZDi0QGWe0CUY67Mx4s6E7bgWUh1tipTpdX0BJ5JBt54mk4WIgyjd Oqh3/C7NfuH+xSgzJ+mEuJB+BoSTcyRhaH0XdJs8d7pNtnOxg6jxw1Nvl/G3aFUYoBR/G1CUBTWE BDIyaggoSqbHUyaQEVFUkx9ZBCSVKcU/uYdo3fSvLRu//OtLtk3/6lZ0aDK+MSCAUtEKDpsb6Ck2 ZIF8wgWMu7oDcx6tyZnZ/kNLMtO6DDTeW/b/ZsnCsF/jq7BZh80aPGJpuMUiqvtmDys1wPabtXw8 5JiEA2ryEHN1krpNuZLpW1feqH1rS9u0b2XrJt08ausW3VS9jxt0qy3FdL0o2VNCDlF7jENQAWWV J6iAMj36pQLK4rlZh7HtKy61bTuLS33L3uJS3bq7uDdg8A80N9DHHYbrMpK9vAsVUBMc0tP7Mcm0 6vQ9eFw6wAGL0cgiTbTzMxt2K0xiyoOHmCQkwUNN3+TMDphE3oMDJpHp0QNMEnbmx9ePF8PxCKMU 6E7BMmZQ0FBGEdCfLPb56YyzovMfutAXLz+hltfWbIn5dR925WPxB9g9C/EN4aolMzwzFoHl7hdg QKCaKR8YwriQDCzAuHCO3RCR+rwdFs22EZtpyXh0SXTP79C25PR9q++hefwEqciZ0XoROvoECBSd Z1Rysq8VcyGiZdt53z/gkkxrEIoq5Zcl4ckht4Aw496QHk53i/G3AaYlC1PGIYRpId1QgGkBpj1n mCbGccoWCiekY/HCOdUPxr4DN/Ztd0QlADKK5TEthZykouFOD9x3aLKnraNg+22DfCpIbMGGW8/A 3nOWmZAyPPe37JlyJyFkDImTAmQMkPE5Q0Z6zdifJM66BWLcEnDaEIUT4gyI1eRdfnxdEhf8z3gk VfI+g3cr+XZfQPjSYbqntzAOOq2c/VsHTbu4MbqsExf2wYIX47AtUA5I+CwDFlaPJCwEjZsNfCAt Y1mAN7smgOTZZLbkx0lW6SrG8ydwJTwKDMtBFFy8pbHetJThuT8gPbWcjBtglkGQbSEdEJ+1kA7I clYwRAz2LmIwANJFHA4idHEQAUPYugBNJZLWqElOu2z/QFeNbNsZjo0s/QyJ91LjJl80ZJ3aIOuU HjwNkHUWIOvw5HTMVBjToZ8AWfcHWZkxwRJJxFLUt0vMJOvnTmaqYGC1Ze5sxg/EMhGiL23J77lQ ZpczgJdaegIEdDOx2UCy01KXTFk+tqidm7GMpskaSi43uG1p+eIBs7QEwdzXdlH2cE3Vzd0vlBQv Wp84s+kTZ0GfQBRm8MqHQ/Myfg76hEyPHhyab7X9N99UZUPLvLYNxbnU50EFnpZS/vnWEcRyAy3s 57SBoC4IkaxN9vNaIGV134KzzrB/eCbFo+a1e9zJKURYF4DAtrotQJMQSbQw1MjIUz32iIiEa7yS MdQxbpfx0QfrawEq+QVDfEjywpTSkbwLKR0pEjZZUgMSlJFPQIIyPfaFBPH8CJiOOrkbyYgVLTY3 cosiZR2zedkM9qraNrDo9PlWaJF/n+w6PTTtqpkDm3GWmEiwBhfOMFUCmU1nwGCbNvO0k+8webv3 LdaK2tittV2itqYgzH6fyfKCb3iv5bO+wqmuBXS0ngjhnt3dV15LJ6+impsdrfTclS4vyP6VRtOo 4bk/wjclSEWEHxKkhvN3xP4QrgJ5jRZFKdj9cDNrmRA+Y2eAEx4BJDa4ZkTZ1UXpRFi9EJg8F2/g bGGOtFG6h8AYMk5N5Us8UXUqgTExblJMb9rQGgMfAjAGatJzlc8fGKuX6XaSwSwA4wCMGXB+v7gY fo1my5iAX1PKWQTGIeVsAMYBGBtCYA4XGHvA3jaG7cpGaYNyRtBMqnMjZ+tIhApR9RB1P0HWV43p p2bSJpNQhmOE4GOivqFCKYRmiCEFbTG4ExscrrFNq5uoSMriOmmxzg6XHK1sj6Z0sQixQrrYALEC xAoQCwPg0LQGaWHwv6bYAaedZWuEZgkecOpAQHjUpv4UqRZqCK9j26zTdO9/67ZGLTCDfWmclUik ja5steObsn3ijh+yfYYdP+z4L3LHd3FvtQkWJHiBwgXbfu/ydct271I97PZPt9vDzhTMNjqzzQtI DtQKlZhSPiIqCSkfAyoJqKR3qMQUAzVmQeReMVBGZ5DL1t9j3ALStI/BW6obCWJHTjSGJJu6qzXw N52VCNCDZaiqe4w6gx4WHN4TOwxhKufjqnJYV5Ov7bBOxpCALTkAENUxG9NRgcMWD54pyoufy5gs KvxHGe4Ghy6XNFs4eS8F7piyISKaC9kQA5oLaC6guUdqjnBOichDlW3XSZvBYFXbZoay7F9VA5b9 z+X7L9MOpUaw7BvIVRN64I6hjo4fihFDmhAsZ9xs1MScmGf/tPYCf52B5p6NmywWS44W98Wydzzs Nd0y1mdcIh0q6mFyHsnrrB7h8NUItFq5fISj30oScbyDz2rXSpIpxSMqSSHFY1CSgpIUlCStkmTW Mipne49N3o+vqYrUIodjr49e+KtIQCkUk8l1Dn+dQZlNA3ZZW/vHshKkyWtJG/33by2k2bm+1A9S e+HnoC6VgS8z5EzIW+/DmfvnLK/pfhnqkuhA6Ui29Fxdkhy5RFnasbr0OUvv4jxP0lVE78RdRQ8x 6GeYEQaPiw+kIpT1wg2xnERS0pyQFFVOAhqSosr02FdS1C5OhrtAqmegGb3jjC07z1xG/zJVKzUc aQ9nnvpuOq7rWWTb3/HGf5s8rJexKQU6fRuSoLN4SoO1LOz38v4W9nuZHn3e751czjZzl0MDRCMO iVx0F0g2uPlsdDdDlUMKy/Ayhoj2wgbKGEMo+k0WIJdfrCjdwE35j9n2HjIgozkj3HGS5hfh9uyL 2uY9mvKUwgb4d6jb+3W8XH6MMjysgLcnPEJyEeLypslUFz8iCmuZug5vx6MzzftylzHU59Gahgbo 7l52hv78TLvl75CD6uHcq+7cq7g5aoIPa9lB/DXlF3T/Rmc+Ns4ZmpsaLbAYdX66I/Urtq+rkMbt 7Ic98/CtYiIa8TJiDds6izuRZp4Xu/drkanpB9v5gSt59lzIBWuljXJgygHNlIOQBTooByFO0gT9 e6scXKXZIs7ySjloi1HEjUd2ljlBnFK5aPv97TAW1UZEYsyWpaoCmtKB6k0H4W0jkTo3N0SHdEYp +8dm1rhGdLft9lzC7WZWWPxt+Db424K/rQh7bu/23FuSpmGrS4d7sPU0mOy698tU5pCtscL+tx+C N5zzoogmvbZ0dQJh+6eLtC3Xc6oQhyVcVgGW67tkubwYSsDDnZySWa+BntuhSpjkfhlVRMtdA2W2 xPs9I4wcf99AGpt8MvudK/m2f9o0sCFGDmzLhh0ZPPdPLC9Z3pXZ8mDlClDD0/qIuo4xNIFqQiE0 IVgfgybUO03I46SBGU+4bJkWnNZcnQjwHsYdbqeB2UBKT5QFr433BSlRXnR5WdqQFdiyS7q3BbYv SYmy0pPcs+N3bAUFMZrPhAsYg6JAo+TaxTc8H0Xh6338EGOAjHoomb5DjDwLp5FBgqEblWCqEjWH 00lyQG84nSTT41DDl0WnfBWsJYcYHJNVnq+jecxCmzGT4MWQh7faMtk217VB5ebaFtWkubI1ha1r dUN6p6bqfVSLoM9+1qd/xjPToVd4FTzwwQNflDvoyemYXZBkOiIU9pTD2FOI//wWtoNk9Q02BjiQ MtEdeAGjj4eBSjhKmG6KPMZ1kf+6GJoMTPrNx7euvPn41pY2H9/Ktc2nXfVy8/Gr3sfNB7TX6kyS yxIkg+Q1ni6Ur+9ZlgnVdLETbfZ+k9uJ7P3B5xR8TmHv753PyUXwop2x3d4Pm2Lbrd+zqrzze1aW Nn7PulA8WcRl6qtWtctt36t22PWHu0qXFXb9iyEmsISt3XTUjez64Zxb2PXDrh92fbiF0ajxT5pM p7K9WdZ8HSrLO793dWnv965d2/3l+s22Dlq93P79qof9P+z/pdMG9fzS+4O/iCOcrhEWJGC7NnUd ZdG3LFrfo3OovDo1gXN3qhcZn+r8x5/S7AFyYeOrf9+QHwX+OwOMzP2sEOVwNT47PqGl1tRdT9xR 1P44i+/SDDxTk2O0QkZ3RZyB2XBEi/9rzpuZxyt4Q58C3yyTVfzhzyV/i8Vh8Kx5ZjfKbtJVkUOZ KJ8nycXwMkugt/D7/hJQvPB7Djmd6Es6Svr/mDT/8fX3OFvx70zYjUj5L/7kiFlC8l/X5EvoWqbP oDvYD/hrcLtIkzDf5EX6gFMHSYakaflyc32TfNtk6tTAmwF7Rfss+/fF+Wmck+9xvP4U/6AzSH58 ABqTewOo95BOF5sfid6dDJDcN3W1WS5BfyRfFKMYyCDxOir23m+k05vp2RlzTbDlIQ9utXmgixL+ 8b5cttSbAUNjr+FfWLuTwV6u1+9UnE3GCW8G8Eo3RHj9bvwKEnFsHuj7FUwWX3Lmmb4cjc5HeAK5 ZI9yxMmyYiH2UZkIeEtyRYTH1yrrYb3OqXOsXQVIneN9UId91Js6WK9z6pyYqcPkbC3QZ8drh33U mzpYr1PqXKXJMs7Wy6jQC0vxvY7JRD4y8VcePyTvksUiXmELsmC9PB5PjsdkicK4XOQ+liH3ln9e RsnqK/C0Mrn4ZoCvmvosd+bt2dFk8pbyC5N94J2lCS0qLaa0qqxJbsNjvqMJfly5xNkp4wZjifHk XHUGy42Mp3wvNbYyGXMYYC5ycs72X2ORoxEoFUg2c5Hjk6buHp2dsa3f2AoQjqEWc5HpSVN3TwAr NXRX62qXqav1tdeKHMNxUTtdTs8h2N1eZHp03NTd6XTaRN2zCSRVtH8IFl1Td891iWbkQWvjuGpF zo+wu8C+MI/IKxVaLeEP7LsEgpa4lfz4slnCg8qznawImiBxhiTwCobHJV2ZnrEOUCGd1O1mRbBf DDffXuZJdDFkz5A6FeycoIgBCSPATv5sGaFnv2ri1/2r60+sAz6QtBRNV9FymaZ64cTeuYknq+h8 ez0ej87pOjAg+K/RffoQCRC+ekAwPPtVoxUPTBFpVcK7BnrM70FRmhPNAyalpMd1+vAA+siX+C7O 4tVc3Wqi1SotogKuChpkZSHsliygp8enZ1MmoNmQqznept+SalHvt3aTEbpckE0Ie1uDEeLuCCv+ O9AEFR5GD9LuNRCMTaGkBFpHygWnOEP0GbBMwwxZRwqZZP4Vz9UdVRhszoroxiuMi45JhATKS+vi 1ox/Rj8p3c3mCxrepPMNWYofo7UCG/i7AXmpG544ndbOTybT6RnjTIYj8vtSVSrlpxhYCkuDJiIg R7fpTtMo/ipmZgp69cDM3dusHYm77Qo4UUA/bR5mwPALXONGLZWXGlSsIPIKQHGxLR2vnF8dHb9h +phBEF6nmyyJs8Gn+FHeLq6iAsS/ICFrJQkhxUe4LiqZw7GSxIlsh1f2lXj16o9bMgBPLrVQ+k18 F22WKsPy59hdWYa+nUzfTt5QOrLFSfZgEuIWv3nLRRQDD9WbT/U3i3+BBeZL8u2+oM5vlGxu+7ar YUnyMxLGoDfFkm2c98Y8Ac1Edl3O6yxdbObFLF38VON7pZcacp9OTidTtiIMi/NrFs828/u4GHy8 FVai8jhZATJasBnHT0kEOjkj/6MTWxFozL4trlD6rJlA0l5hWYUEzZ2dThWJyp9jXy17o7xAxyen k2M2jqCFGZWjo6CFMThVbqiokActrK6FcZ/BmB6gpD8vQeYzRY3Zz5myxkrhL7UQYemOtbivyUOc k5158AWUFb06B+KeYxy1NIKd2mMUOcoO7KHZuW4O775+/PAZlBb05hQGsEMKDcRSBrBTb4wK803y OUvSLCl+8l3vnIFLKwqd3owuj65pE4adR0Q20HalAreARZ7bSalkfULoAe4SZfv4lA4IKiGvcDpV OjCt3uJLO568PWLQ0LyXSGcbdQY9qYDOnicV0Jrz5BI6a55UQmvMk0vobHlSCa0pTy6h20PkEjpD nlRCa8eTS+jMeFIJrRVPLhHOy0j00Brv5BInIwb9BAghl1BNd6INjjEC8DXjnCcQIm7QHqyEdZvd DnQr0Dy1lh947ma9U+UVl9s1wHs+vamZC7gpVZg6GeXopJRcQiem5BJaOVUrohNUchGtpKoV0Ykq uYhWVtWK6IRVrYhOWslFtOKqVkQnr+QiWoFVK6KTWHKR4HbggEamS2duB4ANZvFVoR0NAjViSlGP 3s7mSsxan8u4orp9DCM4qtdNKrQZAl2dTa9PZWNkkC4RpHyV11xQp/W8GNTpujrd2qk5LeVFA6CK lsksS2RDdeXrZIrwdVXKIqz4pE6YZ1oSX+yZAqZ2oCYL3h+tO4C9R2AlKMc1oyEza5dikQQsUt1Q dBkI32Lar+RaO387HnOr6JNAWoW+bcFqqTN/if9McvCWKipz+QL3i/sq6saMRa02hOPJ9OiGLZMn oVVluDZb9v3gPwAApFv+t/8XAAAA//8DAFBLAwQUAAYACAAAACEAGOrc0uEAAABVAQAAGAAoAGN1 c3RvbVhtbC9pdGVtUHJvcHMxLnhtbCCiJAAooCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACckMFqwzAMhu+DvoPR3XUaXHcrccoad9Dr2KBX13ESQ2wH2ykbY+8+h526407ik5C+H1WH Dzuimw7ReMdhsy4Aaad8a1zP4f3tBT8Cikm6Vo7eaQ7Ow6FePVRt3LcyyZh80OekLcoNk+tZcPja MVqcKKW42dIGUyEYfmbNEz7utqemFJujYOU3oKx2+UzkMKQ07QmJatBWxrWftMvDzgcrU8bQE991 Rmnh1Wy1S6QsCkbUnPX2Ykeolzy/26+6i/e4RJuD+a/laq6j8X2Q0/AJpK7IH9XCd6+ofwAAAP// AwBQSwMEFAAGAAgAAAAhANTllRhuGwAAr0ABABIAAAB3b3JkL251bWJlcmluZy54bWzsXe+O4zhy /x4g7zAwYGDzYWdE/fdgew+ybN9usLcZ7E6QIEE+uN3qaWFsy5DcPTf3KdhHyZd7hHufvMC+Qkqi pKZEiqQoyc2++IC7vhElWVWsKv6qWFX87g9/PuzfPEVpFifHmxl6a8zeRMddchcfP93M/vXj5lt/ 9iY7b493231yjG5mX6Ns9ofv//Efvvvy/vh4uI1SuPENvOOYvX+C4Yfz+fT+3bts9xAdttnb5BQd YfA+SQ/bM/wz/fTusE0/P56+3SWH0/Yc38b7+Pz1nWkY7qx8TXIze0yP78tXfHuId2mSJffn/JH3 yf19vIvKP9UTqczv4idXye7xEB3PxS++S6M9fENyzB7iU1a97aD6NiDxoXrJE4+Ip8O+uu/LSebX 7tLtF+DzYY8/+0uS3p3SZBdlGVxd4cH6jcjg/XbJwPwV9RMyn9D8zepLDtv4WL8mF4/W/NeT9xYm 7x3+7Xf5q54JAV58D8K0vc3O6XZ3/vnx8Kbxrx/vbmZGccsxi+9g7Gm7v5ltiv944exd/vDhcX+O f4qeov3Hr6eouidnzj4qLuPbzofTvhoMFk7gLQITj+yf8oEY/lQ/BjKfnqubEb4LBH5zqC/eRbv4 sN3jodOv56/7+pd/irOcENAOp37/x+jP9aNz9La+/s+76lf20f25fNuHNCfrDEwp/1b3wCfM4P+f kgyU1TeM/P53z3fGx5xD+YvKYfjXw/b4CThxM7Pc6vZT/n54DOgt/hLMF84F6pqLFf52hbnwlsj1 DMeueQJfPcFcPL9/grmw7Yq51aw15iIfHn8uzK65WKvPxWYdhKb3zKtp5sKq53qCuTB87lzkw+PP hdU1FxvludgEtmGaYUFMoazTzMWzDRx/LjyTNxX56PgzYXfMBJYKpdUCGWt/Df+tpbb3TNw+7vfR GT9PLxbLYpS9WPz+29/qn32xxeLL+xSvSekmOZ4zIH+b7eL4Zvbr18NtAnAG1pkAFmjywg7WKGI4 PsKidBfdb2GxzgmC9ad4p+I65HTNcrlYK6xDprEILHPt1uyeZJafTSupbiPN8rBlSL9ZdrtmuTRa CrPsbNahs0YT6zJ7gRtploctcPrNstc1yyUXFWZ57Qfu0p3aYrOXznFmedDSqd8c+11zXCqiwhwH vhF6C3eAJkv5cPVyQNrrcVy4Z5eM5TXko/nCOq4Dt+iaiAUmVGEiDBQGG9MuvXEVZ1oGHjHnYRxd GzQP+ukaogMmBrICe7HhgqOHr7dpfPenPJiyz4MpmOHNqIm1tl121AQk9Xza7yCAYhsLwzBwoEAc RyGnHkSHVDLJyW142ubC5imNymQ9iKBr0zlD+e83WGEVVyDsCNHGPEo6AmuSWhs4PgHJGNNAaowJ k8c0jtI3P0dfCsZimN+6mmP91qWeXDMprjnjc+333/7am2+epca3f4OgWx5Gh8By7Rw1r/UTKyxE TQ3LBW1UsVLQOMuGyF1OYscydQGNK35fO42zEYTRVBjTVqSJNA7rFylQemic7Sua8KZ2Ya41r/XT ONiSahlybNpfWuMcV9GUE9GYdrCmp7X2KNbosMa5lqKtvpDGwV5qS6D00Lhi80XFUjW1S0XjIPrX a/eJ3n4ykLd2ndUSL+xs70WMbI0l8je2WW6cNF2Y9qSNAN8U1llkmmrLyXhaz0K2+YbhIJDfG8mi ha3GiAtpubZI1nXV+DZcy5sOkrZI1vLVGDSehhW/ryGSNdQYcyGN0xfJKprssTVOWyTrKJry8TRO UyRrKtrqC2mcrkjWXSia8OEa1xfJ0sk7hmn75oKfpiBGsj5yjbVlBXWgC+BrlU2lCZJFToGRXjBi xEKyOXNGde37I1vfU2PMhbReW2TrLNT4NlzrXwuyRWoMGm+d1RTZGpYaYy6kcdoiW0/RhI+tcdoi W1vRlI+ncZoiW6Roqy+kcfoiW0UTPlzj+iJbOhXasJDvoWWZIKIao90YyDVNn49swyBYm8jGiYP9 ApPNvNxfNmFex4FTc2swTaYnSOG7KrEH/gLALIpXyCIOH/y87hqOfBSeqoGyDasVvrso4ejcWpXS lZ5bPizIfJngr4CFaKKkVykmTpP4MJivkokOAs6a4EpypLMYJsXzOY2KL57DTZIYdo/AwjHy7k2f W4xSDKuwcDyYoA8wF0gjSBdPGothFVZeSM91gvICTsMyw+N0MazC6bH1XifwL2CpA1mRHFNaDKuw dDw7oI+7IGKlx12VnHxYhZUXsgM6ORgCTrs2d/EqhlU4PdwO9HVJ6JpAI/Rte+Nzk97FwXa0XENa RsAsGQPO4J1c31uFAQpxwF/skjSKEloZ0XP0T7kVKeCPZOKv19ffHuoXoEWR5tQ/lL5PvkTpT9H5 HKU1kaS/NTelyubJrGfk8L1mkCPgcMlQmDC8UULFudFyCEm/JIftkU2RxaIojT89VKWiuOqSJMk0 WyFL6ANQriyNun4RRN4oksQVT5tFD9XYoEHOgh9JZM8QBVqnEzqnN0mWy4/9sUmi8OFkQueyKOIL nW21rIiU0NH4bBKh81j0cIXOQSpmgUJI0wmd358kv2UWWs44W+goMDKZ0C1YFPGFznVapqFD6IC0 XjmkdOk4xAsDZx2WkUXV+KS98F1j4TDrEWsw8LLVUdedd8BOZXCKXIUgPK31PiCFSAy8XPQHWdxy u/7VUded9xl3pbEs/krTGcIfz7GnsJKhQ62Gfd15v5lJhulJS2Vfd975Gudcd97Za5x73XlX0jh3 oWjCLx/motvlIHtloMAuW0upIlvP8wNn4fLDXFdk2wL507mHCoEwAcBlu4cU7JzMPVQJhLWxZ4d7 +EoCYSKkyJ4hCtxNJ3T9A2EijMcmSe9AWBt+SQmdvoEwAVhiz5DWgTARzGGTpHcgrI1AOoQOSOsV CKP7riF34dkOGhgIc6DSdGmtmP2gWmvkS7UJEjSBvYBbzsqny5kzakhHKkWRdC9BsrTePacQiTaB MH4v206BGu4kiPANFrRRxUqhfYFl8ltgdzLo7z0QZi30zleh4JgmGme7sO8NBrNOjm5teHUK1Nga R4M7PTTOsRVN+XgaRwFFLULPLlK01f8PM8RIbOD6iiZ8uMb1RbZ0t1nkLxdoaQ1sE7Qy/CC0F/wS lIsHwgRpfMjkJkwWwyqGdDw7oQ8WFrGyLM8HeazuJDUE5cMqrLyQZdEJPVf8g7/AMaowyvS42f7F sAqnh9siffG2gKWWzU3rL4ZVWDqeHaCimS+GFwSstBE3nb8YVmHlheyATphexGnIqSrTW6s7SYtr 58MqnB7bDujkBVSMgr/AGsq0Ok6dMVzdSbK0GFZh6Xh2QB+/oWJQBytdi7tKFcMqrLyQHaCi3i/o 2ws47RncxasYVuH0cDvQ1zehD2AwLQiX2zb3JAxxLYpveKa5ckS+ien6ayRbHt9I9mfWx+NzDqM7 dn3DKAcdjlwj/9rrWwSKMrAcHqT5NVTECJjQt3K9Y0NNBPUnKWeQq6ERMWBY3TlbCih4/tLJBgIm DKwYZzOBws6T5cRI1ukImNC3mFtKFWi0O4kqyFX2CBgwsPSaLQUUQp1OFeRqgURMGFY0zWYCBR8n UwXJ6iEBE/rWM3eoAjCjT5oF4Na8wJQ8vtq04AxC0+Ue01vkanadwxQuIKfTYlYayTU+eTydmrW2 FLgLTieM6bLH+/vajUzOAJ8+McFe8OHD+ufVj//+Zo7ev6nvkKxSLpz4+zjNzj/F+UHilc/f0Uim N4aT4wof7gJHfkD9eALHxEHVsmbcUCpEZ8nHD0U3Kuj/LykhmBtzSzeG4IZlPSvzmQwpD6zszZC5 rRtPcMeEMXhSHnirwpO5oxtbcO3oGGwpU/IV2TJ3deOMbEih6PLAaYngsTpc0IXCgqUemYuiWgHW 6upOMsZZDJPhImjElVt2uH2cFQenVorlRNjzYhT0hzyzIo/JjbyDHskNYZ/Bnusv3o6X5AZHNsaB gciBJvHdTReLYZIbEFEZKBt9ESN9ypG59NfmCm86dR1hz0OMznLlr0w4kK7qHgMEVl3hB2OjH6Jt ftJhf2zUGxgtWmXaYwuq7NFOHKBYMkMJGvXmh4f8Yk+/ToIbmyEjYMWSIarQqDdPTKPVNkLIk222 i+Ob2cf4EGX5OadvsAnKbQA+04wxkjf+bF8udKvecjOwrt2GGbyo2IQrr8Ttf1N37Lan9kPZYbvf h4zr5zT+HLXeeJexriaP5z04V617s4ftXfKldTE63CZZ+xPiwymFExRbtx6TD2mS1B5iSWN23J4+ Jn+E84Rbtz9tj3H20Lq4S/ZJWl+Dw4Pxrhp4FqftDixLPYRZ2v7az1F6bN1ySrL4HCfty9lfKF4/ Vk8ek2OE3/8UpedgH3+qn77dZlHOOjwcHdqPgH1P805N8JcRPB/BvSh1aACU7q1GudYAnZNZlhEc jJIrw5C0dowZwcUoGVPW617QxZhaaGSdDPH67GFdVufN3OvvgU3NHlmvQ8yeMrQ4iD1zXz8OyXoi Yg6VnSOHcmi+0IFJfR0U+vAqM/RDyzPK7APVRgMOZNBCq4FrowEentAnW7oRUhF0GOisx7lQrpNO uc8k38x2G4OXqmPCXaHI8+D1qGMSNUboFKzx8hGpxIcXy0smJUfUXqGTMRfSOCpT4gWzCxt8a/dw eCmNo7Mo9NC4awutPCTKaBMp6i3x0hpHJWRoonGvp4WWSR9eZS3XtrtcDUS2C8txl6bN74lh2Qvo S2+U6PrxsDnU0TZO385vsSsLkSfJZAsPUlLI0I6s/Qu3+/g2jfNno212DrJ4ezMjLpbRUuIKK0qa /zKEEW9md9H99nF/zr+eH0BjAV6FTQtgkEI7+WrDDP7Cl1PFFJdJtwU9HoFgZpMtqn2pgOC+qbUt 4eoKkQJvG+feK+3EtGf4FaXSAqIcYYblenQJZhhmrIjiw1RVd5LwqRjOlXh7/ASx+ZuZ1AyzwOAI BDNzZPuKNITleAQXw70JZoG7EQh+RSmx44j0KAkQxaFA3Vv+ojOD2EaLhbZGmGFmkkNfke6b6tqh w0B4r1RX+pwd2zbXbuiVezSqccElpD4sA7PcVAczD+pYpS88rxxB6IZLtJY0pEUKLCfZRK52ibSM yGh7ljnSwmI3TloRhYSmSztX6DGKlI7VoAJzk2WRM/EPnVrWmFLUPlejIylc41KhBj1m+1CNDs1v 0kMFwKaTOzkI06DJMltpQVI0UYhkMrljghSB3FmLv6sTd5Dt8btos5dY7cpsGnLntPdzpeSOgg2T yR0TSQjkzm0fEdNh7/oiA+zAkkUw0HrWN1ZhmTWoigxCZ23bYcBHBjbU25j5+eNy8IwTa/nf//4f mWhL5TfBX4AnVNDgGRZUN5JypRqeCdJ4uy8COzhr7fnfyuEWb+2EyEBh/tZxO5OOw8iB0ZfOeO0z 64axksA2rhX4AVrhlXTUbpzjsHJgXGdyVhLbk6Hvm6DyRRBTR6mc6tDvsaSSQHOBFYR+YGnLSlhR Kw+KZSqLYbBNXbGoyaWSAJEb23W9laOtrRwY5ZqclUTALIRmwWEJrnRU8IEl5ZOzkoDNcIQzNHTf BLqu4AMjc5OzkkDrrr8xF2iF13QNV/CBMb8JWNnXSaDPL7JXNjLs1QaDblUnYYOCtb3CJX7NwAZe +IqkpxWU5K8sY4QU41824S/RfZRGx12U1e4Cuff4n3P0X/UAZ9e2WvPgL8uP6Fvl+NxJabpwpJyL Jax7lAs/iviT5yR2h/1Fp36yYxIEpsedfsF/70E0J+IsGZ8UEF0kFHYTTeUbdjj4TT0h0HfZ3ngj SXQjk3qSDdoiQbCbYFH+IHuWCYxczjLu2yZZxMo7xl4uwimY5SL5r5toUW4gm2gCzY4s2pIhUBHR +f4Kh+j29ouUaBO4c0zRHmejNj+fqZtgUaIee5YJdDi2aI+yWVtk2XUTLUrCYxNN4LiRRVsyyioQ 7SJFjkP0NEdAmfQRUPZ64eVBAQxPVBFXEKI19Cgq39KxYeuYKHRsB/dHEhvWa1i2ypFabxbuBnna Rm1eUVgWLde+EQba+sevKCwLcNowvA22tBr6x68oLItc5G8WjrasfEVhWTjNMHAXrrb7Lq8pLGu5 6/XG0ZaVrygsC1vfduB42i47rygsG5peABFu7MZpuOy8/rAsfZqWg2Cva13VabOdhOJqRwNT7IJB sQ14PNDl5fx1H0Hfz89VjDNIz/FuH/0a7fIeLvimpg8hF3ATpHiWPwMNS9/WvzEgGJsfndrtwRVg vavDKdtn7VkD8R9RWp73Gmc/fdoXrG0F3EqO5hTPi8BCEeXTiWbZhlOiAPI3c4vVSLBvHnW/TJ18 yxJLQBFfZ8+qbKGHoFHiN3ObRSCd3iUIPDzvCVQ3krlI+Si5v97qhcemUKm1T0tS5w6Lur7ThwyD 2/gwHybJk5pA2VoskYjO3VFIzBP2us0OaufzSZEouwkmkNG5Fs082UIq2ytHOIujxDz7RkykZlG2 2Y1oFseJcA5su1nNIvztVZJCH7fjmL7pLRA38VQMXtAKYwYKvKBtjEdUEAt3twyNYS+ec5RZ9j4f JQ3i892cFU0WpwhVyRyDwH5LthSBvUAJb4N3DPqQwT2+rRjuPYWyoIQnnx2IpPeanXcj5ixo7WbF UjMoC0lEIvrNSLiE7yvAvqWCGvbCJd1S+s04uGRg4Loy9800BFlcwhNTaNxX22d1z8d06tI+lh0t hntroV6YZGC8nD2Dk2KSvqbGgjxTjqkphiUmsSckgWzrPHxB1sI4S8+3N0bZ35UdTxGfAGitNj4U yj479vDtdJWsbSygv67sms3ZdP39t7/JKBLpTlLeSMt4d+YgjtfLiyqh1aKXlygVrZMxF+rlRSW9 adJZiMpmkxWo4ed+NlcmOkEOC9qoAWkFjRNlv3UK1ngaR6XSaaFxogy5TsZcSOOoXDxNNM5uJ9m9 lMbReXt6aJwoKa9TsMbTOCrDTwuNEyXudTLmQhpHpQhqonGvp3uehVEliWxdY2EiZ1HA7K6Da8TI 1kErd22Z/O55jhuuA2cjm07I9RHlQm1caNsK0dLSPbQL3nQ9OOSKLxrUK0UsKFQ5WSsEydIKkiTK hZfKJqdx4CYPqCpUMXLlU66zHUmOrDPbhLUUdptO6OTKIhokLVSi1RSwmkzoJIseSJJsF4K7ZMhB SuhoKDSJ0MkFzkhyHFslkEnBl+mETm7zjiTJRbjxQFfJeVfYKzcCRHP1yYROcrOuQZLfOv+vQ+j6 xrnKPrbZ8yFQrrFcuUurPN9BNc61CFYmvKbsyNvcZmux2RilTE0uP4hkaf9A11A0oAXEv4ax9jez 33/7a9+46DWMdTOjgvekPl3DWPmWQVm1TTLmGsZS07hrGEugcdcwVofGXcNYahr3isJYOBuGDGN5 CGoM/M0aL+yqwNUwXCMMw3Kblw9crxu0N7OyHh/HVEbdSSsT5WEKOCkg5Dp7RbZqWn9FtoJ19ops O9bZK7JV07grshVo3BXZdmjcFdmqadwrQrb0AR2etVya3ppbDSHeoLU2VmD6G/4GbQnnrsj2imx7 nP5GbRJrkpZxRbaCdfaKbDvW2SuyVVtnr8hWoHFXZNuhcVdkq6ZxrwjZ0gfMeI7vOqHJPXpOos63 7D1N1/nCcWdVEXEzlJsLobidITe/Sy7joKo8g7+Q90AdM/OcmV3dSEY081Ey0+j57hFKfQXEzeUy DKvP7qBPUAnrtU7QaiVkshN1ZEt9xQTOmTmH1C63iEZBpahpNht0QA+ssqKNM4tjVPsWLWTeApFz uVxEAZ2CekoEh0U1pBW6KonplK36lZpMoHMul6MoItXnFnCbJnSRIRUzl2NhVxnZ4t8epM6Z+Yt9 BRjMCq/G0vQgG4ykdoGzw0A7OQI8Sh1w3gOpFGCYWKB2nMpgMDM8gqk8XMKKcSiWLQ3uN79A8Vwu BVIg04LWe5ZnN80Uyu2WUKhli4VViJ4zEyX7SregT14hC6R0E31eGpPdN7USK0Bjh9p3fOTAGXfA VfVCCy9w164JzfSKtzRhDdCBM1g3a88P887kCkDn9Gve7A1eVaCVcHtqdHgjz8jYxJ8e0whaldXf wtmqFYgnTyFzWADf09Waja7b2Ga7OL6ZfYwPUfbm5+jLG9xLIZ9mfFocY2SX0Q8ULL6tWFFWyNyG WetK3P43dcdue2o/lB22+z1wl7p+TuPPNfvL37zLWFeTx/M+PrbvzR62d8mX1idFh9ska/9UfDil cPBg69Zj8iFNkvvW1ey4PX1M/pg+ZwqXn/a0PcbZQ+vuXbJP0voaFLPjFQZA92m7gyPp6yEsOe2v /Rylx9YtpySLc0FsXc7+QvH6sbrlmBwj/P6nKD0H+/hT/fTtNoty1uHh6NB+BJQ9/ZB+/x0bgVIF 6tNlv4+Dwqfo10IFfSfLl2ei9N5d9Pp2O+nIsG8W32hVSySwsJM0C9Gu+kjABAHWLYbBGPQrHdGu XknABAH+pSFR7Q01EFFTFbSqcBIwQICFi+HeUqBdTZSICR6ElzDAr+4kg08Fbu7NBKpCe7JVgekc 9F4V+rZ+7lgV+joH9KEugNeRa9tlZyDV9NX1yg+8/IAHnnNQbvK/VN2Vjc+y7WditYNcpKpA+bxC oFY7ANUgCU4KaQR9OgS/uQZoBYdIcqy8v0FvY6YduCFJsi2kQJJ2UIUkyTFapkFK6LQCHg1yPBWz oB2MIEly7ZZZkNqS0g4UkCR5qGUaOoSOXuKPj3ncAP73x7ubGU6ZI/oe/3gHg0UIzSr2N+F5uDWP xzWewyE65nPmooRnrOfwBhH7uWrfhfUc3nBhP1fE8Tq+E+9eMJ/jfSaOgjIf8zjUYXzEfKwIfHZ8 JI5GMx/jzQFuQM18rAqBs1gJ9jefTuZzvCmALenO54rzNjqoQzxZ4TATcWSFN+WIIyuV58DkC0dW TN70IY60ABHYV2H+Ikde6q0e5oMcial3uZgPcmQGooHdnwqf0zn5IFCcBzlSg3jSbXLExuLJNxz+ 0v2p1YYnizmwcdT5oMmTOMgEUXyQIznVGTawVfIvEAiGCHYeMa+6rlaOEjVE5EATY4VBr0gg3ph/ NvHP+geIHZgBbyGyAQa8hdhrH/AWYht7wFvwfBUpOAPeQmy5DngLsYcp9ZYO81ye1MpcDvhSzzFC iLdKAkDoVBeLZy/L/sbMTwUj3G2EyvZxzAeBfs6DHCPEZQ7Q0Ukj/0FVIwRwTfEXeUaoshkse2nx li/ugzzJ4UEQiyM5XK5CG6Ju5vDWBJuzfNVnMrGYAyGx7l/kLV82R3KA492yCokQnb8ICsB5kCM5 oHKcBzmSgxMYO2yOzZMcHiiA3KxOGgH3tT/1x7s/bXfBOdxH2+PjqXJsSEm5jWAr+dP3/ycAAAAA //8DAFBLAwQUAAYACAAAACEAdD85esIAAAAoAQAAHgAIAWN1c3RvbVhtbC9fcmVscy9pdGVtMS54 bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAITPwYoCMQwG4LvgO5Tc nc54EJHpeFkWvIm44LV0MjPFaVOaKPr2Fk8rLOwxCfn+pN0/wqzumNlTNNBUNSiMjnofRwM/5+/V FhSLjb2dKaKBJzLsu+WiPeFspSzx5BOrokQ2MImkndbsJgyWK0oYy2SgHKyUMo86WXe1I+p1XW90 /m1A92GqQ28gH/oG1PmZSvL/Ng2Dd/hF7hYwyh8R2t1YKFzCfMyUuMg2jygGvGB4t5qq3Au6a/XH f90LAAD//wMAUEsDBBQABgAIAAAAIQBSKGEvKgMAAMYNAAASAAAAd29yZC9mb250VGFibGUueG1s 1JbPbtpAEMbvlfoOlu+N12tjGxQSBRJuzaFQ9byYBVayvdauHcK5xx7bvkaVF+jbtKeq79BZ/wEC 6wS3SaRmBSaz9nr98/fNzOn5bRwZN1RIxpO+aZ8g06BJyGcsWfTN95PRm8A0ZEaSGYl4Qvvmmkrz /Oz1q9NVb86TTBpwfSJ7om8usyztWZYMlzQm8oSnNIG5ORcxyeBfsbD4fM5CesnDPKZJZmGEPEvQ iGRwb7lkqTSr1VbHrLbiYpYKHlIpYbNxVK4XE5aYZ9XujFUvITHseryOpzwq4ilJuKQ2TN2QqG+i DgwbYfj4yINjB/mmpRYIl0RImm1OxGV4TmIWreuo4DFJyomUZeGyjt8Qwcg0ouWUZAuYyOUUwQ2r P7OM2AD9fgQfnOPcj4TFOsHOVRCBdTYrw/at8vUcgJiwmErjmq6Md8XO1Qn7RDBQ8JADJFz4YPjl 6omgpyFyBRvHF6PRlsgQIn7g2lVkS6RbRbREiue3y3WOJzLkuWBUKCZafWDQhYO6wEFpAwOTNjRi PqNCJ5A5u6WzQ3U0snBegsUHMJJyvtSS6NQC2x71utA6heQZL0//L4wyJBGbCqYFgdGokIKShAvi gG89CK1B5IpJ2YqEEgXCuwZxIXAx3ES2Bqkt84BBuoXRjjfIBWQyferEaACJwoXnr8fzc9Amihcx x5jF47ysLSTKrqGu1Mn+57dPP75/rl7pXnlRhcWDt+XAsRparQReGb5fXv7WNDUQqAo4CEZKP/v5 w/YeyaVKY4WcjpfKgECnsCg8s4fo192X3x+/NiFyCkRwu3roEdk6RO0r8EDhAB1Vzw+MvO6l7w9H g31GTk2tyU5QhNvaaUKWUHkb8krpp7L0Kl89s5+g88BXmywCIFTh9VDnAAR+rPDCm2tbeCeCTnNo FjPj7fgBHCq91uN5cShZIBz4W10UEfja18Um0qQLuKatLqo+RGee3RalaE0POzYf0vBT9CgJzyYi p5N1Sss77Ta1DT1LRWkn5/wLt7Y5Z0hiqNNNhlIdbGkn1dG2M1T7zKIv1MjdWGxbqGtNNSvIflRB VZMvz/4AAAD//wMAUEsDBBQABgAIAAAAIQDHcGSODg0AAGMyAQAUAAAAd29yZC93ZWJTZXR0aW5n cy54bWzsXVtvG8cZfS/Q/yDwvdHcL0LkoE7gvqRJYbt9p0XaIkBxBZKR6vz6niV3rV15VhUdznBj H0OAqRFJUd/MfOd89+9/+O/N8uxuvt4sqtXlRH4nJmfz1VU1W6w+XE7+/fbV38LkbLOdrmbTZbWa X04+zjeTH1789S/f31/cz9+9mW+3eObmDO+y2lysLyfX2+3txfn55up6fjPdfFfdzlf42ftqfTPd 4tv1h/Pq/fvF1fyn6uq3m/lqe66EcOfr+XK6xSfYXC9uN5Pm3e6f82731Xp2u66u5psNPsjNcv9+ N9PFavICn3G2uNs0/5/dXyxm+BN36zfT9c/z91us3U2XlxMxOa+fhdXXiw/XieW31e3nz31ZbbfV zaN1/MaXs3X9btuH16wguwmeuPm9/l31g9vpFaS5e3xVLStIbvrbttp/jGXnkx32yne9T3TYa9fd v/yQl57vxLz7o/cP+wJXFHh6m3MJ3AitvDb7g/6umn38aXHXHlL56aDz+PcvXbbdwE4YY8LuFnA3 nqkCj7Ebe+3/4/ViOetrJGmjM94bZama8qumPSZsmn1IIYTRzsToNa/IISzhGFckuRvBOGkcFdZB nO0YuzGosKyNKgplTUpfWeM/gfrrLod7ILUd9uofnkz6uuPb+zswSF+jiFbEaJM0lrLf2U3HOPwp VSSdlcYrKffQ8MhoO0z4wX26JTz4Qwd/vwlPYXWIQTppaVwUR4fUBYky+iCtIHMqzZwGsVoq4WKU WiYB4wGT/z9UPzyXCuuxwhoUv7bSBQf/R4oqPUiU0t/5Pf+gmy8NF+nV3Y7BDbXzwTorYPEZR71V Wm+lUER56Y20fu8OoY9qDD4qb5XRxguGKwaCJMewOQZRxMHYDkp4gkh+/2AXGJwLPnqlIgVfVvBe aGmUiVQ3GdVNCnu9E06HIMhXCwg+zUzTq121pAVsCmHNXi2RIBUkSKk7o7WI8As68tXiTqhBxmTB V5WE5U3kzo/cz9BYzhoro2JMdTxXxBunasfHPrL6KJhB19T9xTFMuhYvnnFFENSLUdAJdYgT8Dib NIgiuo50e69phmRkw09IXzoR4HcihufH8K59YZ2TQXtLf1PGY98iQ1fwcHrLYJBmQNpaWvJeCamc iszBLC354IOCv89R2xSQfJqHple7mskYYaR3gT6O4gZcCiiQEuusj9yOERkLyLQx0GSeimyokOwY BvWgtRBrX4YQpE4nkb6szWRkbfiTMNe61nL5qaLRdSoad4+bikZYkto2abd/3prGwQugpUao2p5m Bw7Tw1+h9GWdZulwvpJFEXSnHsdT13KhNGHNtdojwlFarZUgER4FEbZwVFkH83HnI2QovGAofBCI UB8TtAAd2OfTMrL0WUeFYxDhp1VhV2VZDWaMIhmmixRXWcN3BNViKKBE8RKDG/mCG8PiN/C0K8k0 t5zGYquhurpI+hAksGFfIkZoyAoNXcF7a41GdOkk9vm3Yh22J/4QQ6S7SU6CNUmt9jYk2ewY2KxC cmdEzXdgEUDG+NQgUlvtBTIH6VXJKPxWbXVVEdoRoegIyoj8NB8/TQleIhIevLaKSWeFjzwyQIwz WjXwS3KalZx+MUcywgYhAj1+I/JmRIfyVIGiPaJFPrQY5EgeYe+obFOAVFhv9WOv5tuMvSImhNwD FSyLKTKC9uAFkCqYOuYgKf6M4m/Z6iHIfchzu+aHM1ZIIR1bshRH+Xabe9thRXBoOsjOXsW3Y1jp SenRylk7+tIzKr1h8VsV4RUM9ExllH5KF8FFrp0NTPQsHbvz6FLuvNI88YVPPDLLg7cusptB6SMv 0b9RKI/8GTo28jk2UloeycxOIGitGbAuoG2+2EzDBglY3jTTitsFqUuDyJGDH7BJvGT+QMH8geR2 RFFX0bOlx2H5P8fMju06MXw06GyAIqAdlvN2FLwdw1Y0ylgNwt3MFc9JbQfFj6LJiLI92tI5pZ+C BpRvO+29MKS3BehtFwXQYAWNrNFphbGi0pLHUDXUSDrMfGqmm3LoY76hj19q0gW0/5Vo1kiWVNyk G4RpaCslrUFnKN6c/G6o9M3pYkiwSPiwqD2lJTGGgSEBXij4yBWj0yNSWag2Ekq2vqjCSWmHORy+ xnYUaGanUfIrmZGZkeUOAjZmtSAlzTl7kvKJfkrmN9oOR0Zt6rnzjNyd4gJIJCfFYOJpLsC3ov5b z1KaseZa7TFhjzkLxnn2lhgP9TKIycI8oa14CsWnTN3+xjeJy6S9WWvIupqoLsCIQtCtWzqUoZGr D6invikteHTbFDFEw/zvjIq+pVhdVRPDbpwRVU3pEw+rAnMpalc4/eD5/eDdIw+RIwXZCsV4dWFl I53WUVjh6MkrLHk0/VERw584d7mEnj/EW9HVTFHW7XiRqM9Y3BhicREJrw6ObzqEijuEklTVIwQE 6GZotPh27JTU5sfrxXJWpzvNFndn9xeL2eUEPTB1lA7OCrLYfCx2UPw6RmNQW0QbojCfQr4M2tRo NlIcNZ2qnRu1Y4l0qjSdGtRYGAvsUCJhiRcZNdag9LWWLsDtxKzljNJPcVcE0tCv2gRGFkoARo+h InnJOJBU1kiUPvMGNUHayEBdX1ryGN2FgRCOTTaKaxsnpFWI6tDDXfrMI45ZV0VT25Q481/q4UYA Aqn0AplFtMlK22RJXookI4mYnOd+FHeqpvcjYr5ZaGcVsLHDKBo7oK1DXeDOEVung5aeSVdPaBba Biqt4kpr0LW0GyWrgmiQndnCWbOF0/yrd0mUUhFt3A2TCYpfkiSyKwuDHE2b2F9uJPuBpoy2RnVa IqOwRJCcpkB8WX51WMXfMTrMDYK6cxE7oi3jRRm9WYPSV+jvh+wOus8zCj8F1QbTlJGZz8G+Jcy9 LmdFWyAnMKCUJ77wiY8YII5eu5pzYQsLvpZ7iBjTyAy+0pJHkS0qgTCYiZmr+TJXU/AqnQCvQVN8 ZmSUPvMOBVjSeEq+NLPBcCVU9nhO9ZuXljxm3gsE1EQTLKBf+gR+6Wd4q4EGLsYWjRn3HEXcU8P7 gySypn8ur84Jrk7XPMZI92AQYmvi0LwkY7gkJnoHFylTLXMC+6CLVApkugbl1ElcRv3mlN/qvHDM oVFa4xLQkM5nSA/fgHoSEFKOBbuZFLCm00z2j6/2Yd4bdOuAJ5yR6dKR6eFrhvZkaM6BVtQpLeeB P+fNIJDXiw/XW5TH302XNSS2y2+r288XX1bbbXXzaB3V9S9n6/rdtg+vOSwo/OftAp50GFrkJ2uA /D6V6ZEdQtnXR+UYaQCt7NPqrK+iYlTIihVMLiuezDSsouoW4Rgnzo5yOU2RAy6JNdba2vdIHB8P jktvMLtLKwafMtLlQR3lIyY0SsGgawkV1UNsL0WUdVVwir8+0FSy1x1vP4Ru7xFhR9mfBodn8Cpr lUZ9ZNyng9DDW9DD2+5d79aATcHDiEHLhPDxQDhCUg7uxrQ5SFVW3BhElriN3jsqreLGYFJpeWkE WtMp7kfx/RgkvkoIZwMmHDDd8CR2B9y3mAUcTxImPIRM3l98Xb7bgBlCSCBhv7/SBl/EP7TEYViw tODRaj8qhGQ5rrSE5NM2dXq1Z9mBr6LqwjUdfGlpn9rS9tEKjCFvCmG4H6feD8T2JELezcAQ7sfJ 96MeQ6ti096O+1FwPwaNOgw+sOgMpdl/PyfUD4q/ngqvtGvG5TxKC6Ef8Lh+wB55qpmTlHBoMJiU L+Wz9e2lyWx6tbdLwRoEk3yTskbIGAVk1BRXeswf5NXJd3UGIUMiAI7ms6zWyAnYreLqKSPU9znA dTJ9llh9XKxOY0N6tbdJmE+hMWNN73GdiDEKxNABLnTnPTN3MkaOWp31nEvipbIY1clGjsXDq+0u 9ZQWmheB6AZHpVV8PwZ5FgIgQaOgnyw3o84alD4qM6QC0aX0M0o/qYvQrxFYjQHztO7yWXdJySOU V4ePIstgS595i2JVicRlnvkCkk/z0/RqnyVFHwJSy5nJPB6WhLk7GDBvHXMCM96cQZaEWajo9BsC XVIZpd9idVpDpVe7egt5syEofDGZeTx6y4PhuoB2hmS5+Vnuc+4IenpG5HrSAzKiO2KjVcYboktG dBnGdszZCQLd8qih8muoLl4jK0QIZER5Sj7juW9ZVU/yIYZdYwNqnNKShx0n0E6etV0lsgrSfCi9 2r0fSsDaQ/5sk3nD4PYYgtvI30SYAkOIidP5cHqQJaEyry5WCswsKI0YpkYLVKTSgi4g+TQ2pFf7 iOEk8qGio8+8uF293526syHaYaJB5mJ2OYG2QqzJ6SbGRwQfA4IriYZeJgrWAuQkv4MQHpxGPnkg gcop/VYZpSHjydVag1W328XN4vf5q2r9cl3db+brXVPg9Xz58dfVf/758+676XJZ3f/rl3/svplV v1TbN9O7+d83bxarD8v5q8Vyjp/gV93P372Zb7dY3bz4HwAAAP//AwBQSwMEFAAGAAgAAAAhAKnI XKqMAAAA2gAAABMAKABjdXN0b21YbWwvaXRlbTEueG1sIKIkACigIAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAALJJsgrOLy1KTi1WCE7NSU0uSU0JLqnMSbVVinEMcNSLCPZRUgAL+CXm AgWBYkoKFbk5ecVWSbZKGSUlBVb6+sXJGam5icV6+QWpeUC5tPyi3MQSILcoXT8/LS0zOdUlP7k0 NzWvRN/IwMBMPykzKSczP70osSCjEmoYVYyys9GHe8aOlwsAAAD//wMAUEsDBBQABgAIAAAAIQC+ jgckgQEAANsCAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACMkk1P7CAYhfcm/oeGfQco4/Wm6WCiRjejMXFu/NgReB2JLRBgrPPvL2Wm1Yku 3DSBc3g476HN2UfXFu/gg7ZmgeiMoAKMtEqb9QL9W12Vf1ERojBKtNbAAm0hoDN+fNRIV0vr4c5b Bz5qCEUimVBLt0CvMboa4yBfoRNhlhwmiS/WdyKmpV9jJ+SbWAOuCPmDO4hCiSjwACzdRER7pJIT 0m18mwFKYmihAxMDpjOKP70RfBd+PJCVL85Ox61LM+3jfmUruRMn90fQk7Hv+1nPcoyUn+LHm+V9 HrXUZuhKAuKNknXUsQV+C7G3/q14SJ/UanHt7cY1eNIHp/QgovX8yW6SYwmQ9XF36LoVId6kZ3nR oM63fHnKTsi8wd+VwezhXQ8Pyll2TMsRdOe1iaB4RSgrCSspW9F5XZ3WhDxPzNGU8uXidiFBFamK elfcqDywi8vVFRp485JUZUVXFasp2/FGVx4n3ToBu/08vyYyckgcATyHPvwd+X8AAAD//wMAUEsD BBQABgAIAAAAIQCpuQPnmAMAAG0ZAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAANRZ32/iMAx+P+n+h6rv0B8UKFPoNDHdbdJuQ4JtjyjXGogo TZUENu6vP6ftWDc2qZ2ERvfkOJbz5bPnGJecP69jYwtCMp4MTadtmwYkIY9Yshia99NfLd80pKJJ RGOewNDcgTTPg58/yFjwFIRiIA10kcihuVQqPbMsGS5hTWUbtxPcmXOxpgqXYmHx+ZyFcMnDzRoS Zbm23bPgWUESQdRK9w7N3OPZVn3VacRDjU8+THcpAg7IFNZpTBUEbuuRi6i1ddt2WxXKdsQVsfYm ZMoVjadsDYHTR/1+RcZ0ATJwPGLlEtG+ZNDpdXvEymUyWlJBQ4WMBq7te2hb0pCLNI1ZSBWyHfxh oeCSz5Vxl/FiaA/EKpsQ5GoC4UYwtQtsYpWX5IYlGk2/Q6xcRHyCLgRNlzLwfA1yvySTkMYwQk6C OY0lEOtVQa6A6niPKUPQZKvOthAqLgzJ/mHEXdP4SyVoJofmlgpGE4WMarN8kclxKpUIpkzF6Bv3 8nUmls3KMvMCJzNA4a2hdpBjwI236LIT5N0c76Y+AOuUwWYYcqg5nFtQT1ysNNErvLDxW/BNegA3 uzwe/O6oEV+nNNkF95ORdT25xrgWCh2IlbxPp/xSZ1jB71tlKS0emVpOUhpi7FzP67rlBCntkQkm EkQY8RePrwpylXk/jJXjeGUCPo2Wpt72/N6g+3EA3gVXm/uY4qg+iNWhKeZpNcNqh8fpk06torpA 0n5iK5ZCxGhWU/TKemBCbWg8Gwu2xRjMbi5uZxMQW6w2RXgzH5lcTsGyXJxT2V6T4vQHfbvaNbR5 f1CVmuNwWPluBRezKQ87rt/r+v0BFjKMapmkMnll+SvEYA2rljOnR0wO/UjE9PABaioxWNmOlzG9 T54OPPFdLp5exuTQj5Qx3crl6PSIyRFVJcbFx9OrnAaO19zi6+fQj0VMc4uvj11ujRpTM2M6zS2+ fg79SBnTqfxfd3I1pmhjj0SM29zi6+fQj0SM0+DiW6/zrVljnAYX33qdb01i7AYX33qdb11iGlx8 63W+9YipPss4vUepXuPrd7p2r/JLUzSP3za4qdyhFU9PaehQzEuqvkk1eWlu5e3Xans7A5zhVL5s 4fvb0qWY8ymxkQqgzUDNszkfjs0hkdBiyZzXTanP7fWvh9dJczFVvcJRt4j1UBdH98kCopcJ7OGG Hug/5F9PAge/KeBfNsF/0eEQfv9ZI/gPAAD//wMAUEsDBBQABgAIAAAAIQA7TRj/ggMAAGcGAAAT AAgBZG9jUHJvcHMvY3VzdG9tLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ALSV24+iSBSH3yeZ/8H4tBviCMVF6bQ9ESgQEBTB60sHuQjKvQoEJ/u/r53ZcdJJ78tu+rFyKt+p 8/2SU8/f2zTpNUGF4jyb9KlvZL8XZF7ux9lp0l878mDc7yHsZr6b5Fkw6XcB6n9/+frleVnlRVDh OEC9OyJDk36EcfE0HCIvClIXfbuXs3slzKvUxfdjdRrmYRh7gZR7dRpkeAhIkht6NcJ5OigeuP5P 3lOD/yvSz72316GN0xX35748/wPvemGKY3/S/yGxoiSxJDsAkBcHFEkJA57mRwNyTJJAAKLMT+Ff /V7xdhn0e5mb3kd/TdFroUqvI8DSDH3HNvgpKa4IVy9/MH+C6DblknJcSJ0sSp7T7s+2EO6XR7H2 iMatTMNnzjd9zF0ihYJssIrWkUsgbe9VGyc3jgEnhupxnr62JEn6r1+/TIUWmFDU5uYKAh7uYhpe JTHgPKyUdT32LM8qpaqJgcGV16OtrGf6GjsRLOt83gS4qFso3RTVeACX6oU3oKt0+CS2gr6QTo52 qS9lVNrytbXqRTsLTyNkmVc2vB73VUfbR68JQ07Z05hKeIHTiIicnx/AG7BuGXELqJlA4AoyZ/p5 +NvJ8/CX9v8ZAP1xANS7BG6+nYjd3B/nhSmzUc0pbj28D7UuRmw6NS9eaGd8soDNZUjam05KzGAv /5ad26J+djfKSNuhY3bIeKAH0gKpKwsGt9qF+3QVGlPlThjt1tFZI5bt4WTbsa2CTrfp9EZQZ+5S 7h9uHM1opiDXFa/2jbXTNtaMbkh9a1v4MuW3dHJidjXhjrTMWtcMUWWUNR0zGZcug7MkYnCmzINW EKMHEK2EoYaw4Wp0wQrKanEdF8aO2ZbFoboQBb2moPYp+pmP9YN3+k22dI47bz7arFQC+hAeluC8 OAZ1zIvBFe+mdLx8jALG+8NWT/mZX7MyYZfCHl4pA3HFNtI5BKZc0W6kQrFCaFb5zS6YOpf1UN1U ksfE0NFDD0GKWsAHcOlnVEQY19kKdIC1N/V2a6hoiVVobUtb59dxJRubSyKRneKoIKuSWeLCNUXO 0YloVQlINh0SbfIAHg9OXQC6aFa8jPK5QIceHYX4wmIZmI0Q+jzMV5tTslTM0eEwZsWGPLKzT9HP fqz//f6R2U/pzf3qjcLEPb0LnKJ5mgQMzTP/1nn4toN//hAvfwMAAP//AwBQSwMEFAAGAAgAAAAh AK10Vt8dCAAALj8AABoAAAB3b3JkL3N0eWxlc1dpdGhFZmZlY3RzLnhtbLSb31PbOBDH32/m/geP 32lIoHBlmnYo9AczbY82MPcsHIVosC2f7RC4v/5WK1sYG9u7sekLiW3tZ1e7+q6h0vuPD1Ho3cs0 Uzqe+9M3+74n40AvVXw796+vvuz95XtZLuKlCHUs5/6jzPyPH/784/32JMsfQ5l5YCDOTrZJMPfX eZ6cTCZZsJaRyN5EKkh1plf5m0BHE71aqUBOtjpdTmb70338lKQ6kFkGtDMR34vML8xFTWs6kTGw VjqNRJ690entJBLp3SbZA+uJyNWNClX+CLb3j0ozeu5v0vikcGjPOWSGnFiHih/liLQRxQtcO/Jc B5tIxjkSJ6kMwQcdZ2uVPIWxqzUIcV26dN8VxH0Uls9tk+lhg+dCpuTgPBVbSMWTwYa5FyZjaQdF oZ0Hk9+nrNYtTve7gikyYkw4HyguPGeWnkRCxc7MblNTnVxYD0Pq+2uqN4lzJ1HDrF3Ed86WWZYM z/aPcOVVQ8tYBhpLd7EWifS9KDi5uI11Km5C8Gg7PfRMRfofQCqWOjiXK7EJ88x8TS/T4mvxDX98 0XGeedsTkQVKXYGEgJVIgcFvp3GmfLgjRZafZkpUb34urpn7a/Ng9aYbGWR5xeAntVT+xECz/2DY vQjn/mxWXjkzTjy7For4trwm473rRdWZue8u3YDduS/SvcWpMTbBSMuflYiTZ/HDN3QlEQEsPuCI VS5Bh0DIDCdUJsGzYxA1++X3xsyv2OS6gKABgFXNwtfapIM8gVgtrGjDXbn6roM7uVzkcGPuIwsu Xl9cpkqnoKRz/907w4SLCxmpb2q5lKZHFNeu47Vayn/WMr7O5PLp+q8vqNCFxUBv4hzcPzrGQgiz 5eeHQCZGKcF0LEySf5oBIGOQjgoHHdqoJ2/shRoVL/5bIqc2hy9S1lKYruah/50gjHozGDQzEVUD QLssXw+GmzgcbuLtcBNYvMPm4ni4F/AuMzQjtjYqVUlPaq4DW3zVeTh411GyZkSjinpHNIqmd0Sj RnpHNEqid0SjAnpHNBLeO6KR394RjXR2jggECle9ig5wNkgL+0rlIbTKHqWbDpS6otV4lyIVt6lI 1p7prXW3u8RysbnJaa6inO4ulos81eaNs2dGoDubpbuzJn+OkrXIFLyY94EGTv2VefvxvqYK3mB7 UG9t8TViwheTF1vYZSgCudbhUqbelXywGWWM/6m9hX3L6HVuYFq/q9t17sGLoWm5vbCjlklvnwlr /7vKcA46u/lRSyh9xkk5PGqpy3bjP+RSbaJyaghvI0dWzxlpriHQxe4pOjQpaq6u3ihMAigh2HbB DwHtE/y3zYVv3+SY4r9tRTvaJ/hvG9eO9rE+uvPLVppz+MuKR1pex+y1e6ZDna42YbkGeuXhmL2C HYIWAnsRO/skkThmr+Bn8umdBgH85kapU3YunnSUQWGnw1JwsdFjYSelJntTRkTsBNVYMwZrmNYy QGzR/S3vlfk7MLcZoEq7d83e5XzQMgPQgkjv0L82Ou9/h561aB6VchHDn0sy6dFoBy0rj0or6sn2 O0aOhzU+BmhYB2SAhrVCBqilPtrfeVxPpEOGN0cGiy3Lroth2ZGV+ZitzA7EawEj9U3C+1fL6m2v hWbfJFDYCWr2TQKFnZ1aL3N9k8AarW8SWC1doz1HVU3lBMXum1WQexMgRDSOeBNA44g3ATSOeBNA w8W7HzKeeBNYbG1wmloVbwIIH+H8qu9AVfEmgNjaYNWu+JtR2ffQSvcvtyOIN4HCTlBTvAkUdnba xJvAwkc4lVBjOakjsMYRbwJoHPEmgMYRbwJoHPEmgMYRbwJouHj3Q8YTbwKLrQ1OU6viTQCx5cGB quJNAOEjHG14Ubxx1b+6eBMo7AQ1xZtAYWenJqjuJZXAYieoxnLiTWDhI5xiKFhY3JygxhFvQkTj iDcBNI54E0DjiDcBNFy8+yHjiTeBxdYGp6lV8SaA2PLgQFXxJoDY2vCieONifHXxJlDYCWqKN4HC zk5NUJ3OEVjsBNVYTrwJLKyXweJNAOEju4I4EY0j3oSIxhFvAmgc8SaAhot3P2Q88Saw2NrgNLUq 3gQQWx4cqCreBBBbG14Ub1wjry7eBAo7QU3xJlDY2akJqhNvAoudoBrLSR2BNY54E0BYmIPFmwDC R3YA4SripGkc8SZENI54E0DDxbsfMp54E1hsbXCaWhVvAogtDw5UFW8CiK0NZp8t7Bclb0+dthQB dZ9BuauBDJy1JIkKLAL8LVcyhYOFsn93yEBgGSGD2FIe1BA/aX3n0TZ2H7QUCBmlbkKlcUv3I+7S qRxEODjuOElw9feZ980egGmMw5J6vvMGTg9Vjwvh8SRzcAj8zB8TOLKTlDvLjTU4IGSOdhVHgPBY 6AUcCCqO9ZjB5pwPPIiHqorL+P+2BRU+AxEHNlHBGlgBnIjqQBUb3t0eJNzuXge37IpHR56OZJRu Frvjn96h7HPP9mh2+p2bneAdPuNO8c458vARm9Wmg3A4C13q8xBSdhPaI2bw4SJeQoTb4nSWTeby QVhTcP9MhuEPgQfScp20PxrKVW7vTvexA9ZM3eg811H7+BQ3iKMnLxmAcqg6Y7+aINrrJN5ENzIt tpu3lqTpHHgS7XlJ2r2uLaVAnWmib8Emg6nBg3j1JTPFfw3/TtNcBaFcyMCcm7O5Kk4NQtQ2t/Dh wqQW19iBeQbcKe7Cp/KMYMsiezZ5XQ4K1fBuCtdw5jpdwuOVr+GSkTUQh/pqL6ay3zFc6F2OwT2c tezD/wAAAP//AwBQSwECLQAUAAYACAAAACEAe5WXqfwBAAAcCgAAEwAAAAAAAAAAAAAAAAAAAAAA W0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCZVX4FBAEAAOECAAALAAAAAAAAAAAA AAAAADUEAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBh09HISAIAAKoLAAAcAAAAAAAAAAAA AAAAAGoHAAB3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhADOJvsqa YAAAdYgCABEAAAAAAAAAAAAAAAAA9AoAAHdvcmQvZG9jdW1lbnQueG1sUEsBAi0AFAAGAAgAAAAh AMe8OvqFBAAAbi8AABAAAAAAAAAAAAAAAAAAvWsAAHdvcmQvZm9vdGVyMi54bWxQSwECLQAUAAYA CAAAACEAGTApa2gBAACzAwAAEQAAAAAAAAAAAAAAAABwcAAAd29yZC9lbmRub3Rlcy54bWxQSwEC LQAUAAYACAAAACEAvHdW72gBAAC5AwAAEgAAAAAAAAAAAAAAAAAHcgAAd29yZC9mb290bm90ZXMu eG1sUEsBAi0AFAAGAAgAAAAhADj3s4J0BAAAPy4AABAAAAAAAAAAAAAAAAAAn3MAAHdvcmQvZm9v dGVyMS54bWxQSwECLQAUAAYACAAAACEAGvY575UFAACUNAAAEAAAAAAAAAAAAAAAAABBeAAAd29y ZC9oZWFkZXIyLnhtbFBLAQItABQABgAIAAAAIQCbkinUFAIAAB0GAAAQAAAAAAAAAAAAAAAAAAR+ AAB3b3JkL2hlYWRlcjEueG1sUEsBAi0AFAAGAAgAAAAhAJa1reKWBgAAUBsAABUAAAAAAAAAAAAA AAAARoAAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQBOzkj1eC0AAGvgAAAR AAAAAAAAAAAAAAAAAA+HAAB3b3JkL3NldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQCcqEw6DgEA AJYBAAAcAAAAAAAAAAAAAAAAALa0AAB3b3JkL19yZWxzL3NldHRpbmdzLnhtbC5yZWxzUEsBAi0A FAAGAAgAAAAhALU1C5K3MQAAU50CAA8AAAAAAAAAAAAAAAAA/rUAAHdvcmQvc3R5bGVzLnhtbFBL AQItABQABgAIAAAAIQAY6tzS4QAAAFUBAAAYAAAAAAAAAAAAAAAAAOLnAABjdXN0b21YbWwvaXRl bVByb3BzMS54bWxQSwECLQAUAAYACAAAACEA1OWVGG4bAACvQAEAEgAAAAAAAAAAAAAAAAAh6QAA d29yZC9udW1iZXJpbmcueG1sUEsBAi0AFAAGAAgAAAAhAHQ/OXrCAAAAKAEAAB4AAAAAAAAAAAAA AAAAvwQBAGN1c3RvbVhtbC9fcmVscy9pdGVtMS54bWwucmVsc1BLAQItABQABgAIAAAAIQBSKGEv KgMAAMYNAAASAAAAAAAAAAAAAAAAAMUGAQB3b3JkL2ZvbnRUYWJsZS54bWxQSwECLQAUAAYACAAA ACEAx3Bkjg4NAABjMgEAFAAAAAAAAAAAAAAAAAAfCgEAd29yZC93ZWJTZXR0aW5ncy54bWxQSwEC LQAUAAYACAAAACEAqchcqowAAADaAAAAEwAAAAAAAAAAAAAAAABfFwEAY3VzdG9tWG1sL2l0ZW0x LnhtbFBLAQItABQABgAIAAAAIQC+jgckgQEAANsCAAARAAAAAAAAAAAAAAAAAEQYAQBkb2NQcm9w cy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQCpuQPnmAMAAG0ZAAAQAAAAAAAAAAAAAAAAAPwaAQBk b2NQcm9wcy9hcHAueG1sUEsBAi0AFAAGAAgAAAAhADtNGP+CAwAAZwYAABMAAAAAAAAAAAAAAAAA yh8BAGRvY1Byb3BzL2N1c3RvbS54bWxQSwECLQAUAAYACAAAACEArXRW3x0IAAAuPwAAGgAAAAAA AAAAAAAAAACFJAEAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWxQSwUGAAAAABgAGAAeBgAA2iwB AAAA --_004_4A95BA014132FF49AE685FAB4B9F17F645C84211dfweml701chmchi_-- From nobody Sun Feb 23 16:35:39 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA251A0785; Sun, 23 Feb 2014 16:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2 X-Spam-Level: ** X-Spam-Status: No, score=2 tagged_above=-999 required=5 tests=[BAYES_80=2, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHH0pKT6D7L4; Sun, 23 Feb 2014 16:35:36 -0800 (PST) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by ietfa.amsl.com (Postfix) with ESMTP id 64B361A0784; Sun, 23 Feb 2014 16:35:36 -0800 (PST) Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WHjWA-0005cz-7q; Sun, 23 Feb 2014 17:35:34 -0700 Received: from [72.250.219.84] (helo=sylvester.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WHjW8-0001Lr-3s; Sun, 23 Feb 2014 17:35:34 -0700 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id s1O0ZRsJ014993; Sun, 23 Feb 2014 17:35:27 -0700 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id s1O0ZRJl014980; Sun, 23 Feb 2014 17:35:27 -0700 Date: Sun, 23 Feb 2014 17:35:27 -0700 Message-Id: <201402240035.s1O0ZRJl014980@sylvester.rhmr.com> From: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org X-XM-AID: U2FsdGVkX19BxKouGYizest/AWLqsSbk X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/UXAjlOIAsRSoLM7nla9sZjSLZmI Cc: draft-ietf-mpls-tp-psc-itu@tools.ietf.org Subject: [secdir] Security review of draft-ietf-mpls-tp-psc-itu-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 00:35:37 -0000 Security review of draft-ietf-mpls-tp-psc-itu-02.txt MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of SDH, OTN and Ethernet Transport Network Operators Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The abstract for this document states: This document describes alternate mechanisms to perform some of the sub-functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks. The security considerations are the timeworn statement that No specific security issue is raised in addition to those ones already documented in RFC 6378 [RFC6378] In RFC 6378 we find: MPLS networks make the assumption that it is very hard to inject traffic into a network and equally hard to cause traffic to be directed outside the network. The control-plane protocols utilize hop-by-hop security and assume a "chain-of-trust" model such that end-to-end control-plane security is not used. For more information on the generic aspects of MPLS security, see [RFC5920]. To my great astonishment I found that "RFC5920 Security Framework for MPLS and GMPLS Networks" is an excellent document, and it is my suggestion that the current draft reference it directly in section 13 "Security Considerations". Barring any surprises in the extensive state diagrams, I otherwise am inclined to accept the "no new issues" handwave. Hilarie From nobody Sun Feb 23 21:51:58 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780B31A0814; Sun, 23 Feb 2014 21:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWYOStUMyRvG; Sun, 23 Feb 2014 21:51:54 -0800 (PST) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3ED1A0813; Sun, 23 Feb 2014 21:51:54 -0800 (PST) Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WHoSD-0005CT-NK; Sun, 23 Feb 2014 22:51:51 -0700 Received: from [72.250.219.84] (helo=sylvester.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WHoSB-00045R-4I; Sun, 23 Feb 2014 22:51:49 -0700 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id s1O5pgru000623; Sun, 23 Feb 2014 22:51:42 -0700 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id s1O5pfrm000621; Sun, 23 Feb 2014 22:51:41 -0700 Date: Sun, 23 Feb 2014 22:51:41 -0700 Message-Id: <201402240551.s1O5pfrm000621@sylvester.rhmr.com> From: "Hilarie Orman" To: ryoo@etri.re.kr In-reply-to: Yourmessage <5B4A6CBE3924BB41A3BEE462A8E0B75A286BA563@SMTP2.etri.info> X-XM-AID: U2FsdGVkX18RC8QuIFkP2Gkotmf/Bfz5 X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;ryoo@etri.re.kr X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/WxotoWjNc9wx932xPjvCXsygis0 Cc: draft-ietf-mpls-tp-psc-itu@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Security review of draft-ietf-mpls-tp-psc-itu-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 05:51:56 -0000 Something like: "This document introduces no new security risks. RFC 6378 points out that MPLS relies on assumptions about traffic injection difficulty and assumes the the control plane does not have end-to-end security. RFC520 describes MPLS security issues and generic methods for securing traffic privacy and integrity. MPLS use should conform such advice." Hilarie > From: "Ryoo, Jeong-dong" > Date: Mon, 24 Feb 2014 04:35:08 +0000 Dear Hilarie, Thanks for your comment. I am not sure about what text has actually to be put in the Section 13 to reflect your suggestion. Do you have any text in mind? Best regards, Jeong-dong ________________________________ >From : "Hilarie Orman" Sent : 2014-02-24 09:36:04 ( +09:00 ) To : iesg@ietf.org , secdir@ietf.org Cc : draft-ietf-mpls-tp-psc-itu@tools.ietf.org Subject : Security review of draft-ietf-mpls-tp-psc-itu-02.txt Security review of draft-ietf-mpls-tp-psc-itu-02.txt MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of SDH, OTN and Ethernet Transport Network Operators Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The abstract for this document states: This document describes alternate mechanisms to perform some of the sub-functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks. The security considerations are the timeworn statement that No specific security issue is raised in addition to those ones already documented in RFC 6378 [RFC6378] In RFC 6378 we find: MPLS networks make the assumption that it is very hard to inject traffic into a network and equally hard to cause traffic to be directed outside the network. The control-plane protocols utilize hop-by-hop security and assume a "chain-of-trust" model such that end-to-end control-plane security is not used. For more information on the generic aspects of MPLS security, see [RFC5920]. To my great astonishment I found that "RFC5920 Security Framework for MPLS and GMPLS Networks" is an excellent document, and it is my suggestion that the current draft reference it directly in section 13 "Security Considerations". Barring any surprises in the extensive state diagrams, I otherwise am inclined to accept the "no new issues" handwave. Hilarie From nobody Mon Feb 24 00:51:54 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09191A012A; Mon, 24 Feb 2014 00:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.148 X-Spam-Level: ** X-Spam-Status: No, score=2.148 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-Gq_A_pSKkM; Mon, 24 Feb 2014 00:51:49 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id D52F41A008B; Mon, 24 Feb 2014 00:51:48 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1O8pXbl030851; Mon, 24 Feb 2014 08:51:33 GMT Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1O8pTus030804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Feb 2014 08:51:31 GMT From: "Adrian Farrel" To: "'Ryoo, Jeong-dong'" , "'Hilarie Orman'" References: Yourmessage <5B4A6CBE3924BB41A3BEE462A8E0B75A286BA563@SMTP2.etri.info>, <201402240551.s1O5pfrm000621@sylvester.rhmr.com> <5B4A6CBE3924BB41A3BEE462A8E0B75A286BA60B@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286BA60B@SMTP2.etri.info> Date: Mon, 24 Feb 2014 08:51:31 -0000 Message-ID: <06f501cf313d$9e5a5540$db0effc0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06F6_01CF313D.9E5F3740" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHW0a4HhHgkCdJLabRfOPDJVH+0HgG+Wc8TAbiYCxuamSBCcA== Content-Language: en-gb X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/XLIYHPQt7oOgGivCNmJN9Uc_k1g Cc: draft-ietf-mpls-tp-psc-itu@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Security review of draft-ietf-mpls-tp-psc-itu-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 08:51:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06F6_01CF313D.9E5F3740 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Perfect. =20 A =20 From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Ryoo, Jeong-dong Sent: 24 February 2014 06:24 To: Hilarie Orman Cc: draft-ietf-mpls-tp-psc-itu@tools.ietf.org; iesg@ietf.org; = secdir@ietf.org Subject: RE: Security review of draft-ietf-mpls-tp-psc-itu-02.txt =20 Hilarie, thanks for the text. =20 If there is no objection from others,=20 I will add [RFC5920] in the Informative reference section=20 and replace current text in Section 13 with the following text: --- This document introduces no new security risks. [RFC6378] points out that MPLS relies on assumptions about traffic injection difficulty and assumes that the control plane does not have end-to-end security. [RFC5920] describes MPLS security issues and generic methods for securing traffic privacy and integrity. MPLS use should conform such advice. --- =20 Again, thanks for your help. =20 Jeong-dong =20 _____ =20 >From : "Hilarie Orman" Sent : 2014-02-24 14:51:55 ( +09:00 ) To : Ryoo, Jeong-dong Cc : secdir@ietf.org , iesg@ietf.org , = draft-ietf-mpls-tp-psc-itu@tools.ietf.org = Subject : RE: Security review of draft-ietf-mpls-tp-psc-itu-02.txt Something like: "This document introduces no new security risks. RFC 6378 points out that MPLS relies on assumptions about traffic injection difficulty and assumes the the control plane does not have end-to-end security. RFC520 describes MPLS security issues and generic methods for securing traffic privacy and integrity. MPLS use should conform such advice." Hilarie > From: "Ryoo, Jeong-dong"=20 > Date: Mon, 24 Feb 2014 04:35:08 +0000 Dear Hilarie, Thanks for your comment. I am not sure about what text has actually to be put in the Section 13 = to reflect your suggestion. Do you have any text in mind? Best regards, Jeong-dong ________________________________ >From : "Hilarie Orman"=20 Sent : 2014-02-24 09:36:04 ( +09:00 ) To : iesg@ietf.org , secdir@ietf.org=20 Cc : draft-ietf-mpls-tp-psc-itu@tools.ietf.org=20 Subject : Security review of draft-ietf-mpls-tp-psc-itu-02.txt Security review of draft-ietf-mpls-tp-psc-itu-02.txt MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of SDH, OTN and Ethernet Transport Network Operators Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The abstract for this document states: This document describes alternate mechanisms to perform some of the sub-functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks. The security considerations are the timeworn statement that No specific security issue is raised in addition to those ones already documented in RFC 6378 [RFC6378] In RFC 6378 we find: MPLS networks make the assumption that it is very hard to inject traffic into a network and equally hard to cause traffic to be directed outside the network. The control-plane protocols utilize hop-by-hop security and assume a "chain-of-trust" model such that end-to-end control-plane security is not used. For more information on the generic aspects of MPLS security, see [RFC5920]. To my great astonishment I found that "RFC5920 Security Framework for MPLS and GMPLS Networks" is an excellent document, and it is my suggestion that the current draft reference it directly in section 13 "Security Considerations". Barring any surprises in the extensive state diagrams, I otherwise am inclined to accept the "no new issues" handwave. Hilarie ------=_NextPart_000_06F6_01CF313D.9E5F3740 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Perfect.

 

A

 

From: iesg = [mailto:iesg-bounces@ietf.org] On Behalf Of Ryoo, = Jeong-dong
Sent: 24 February 2014 06:24
To: Hilarie = Orman
Cc: draft-ietf-mpls-tp-psc-itu@tools.ietf.org; = iesg@ietf.org; secdir@ietf.org
Subject: RE: Security review of = draft-ietf-mpls-tp-psc-itu-02.txt

 

Hilarie, thanks for the = text.

 

If there is no objection from others, =

I will add [RFC5920] in the Informative = reference section 

and replace current text in Section 13 = with the following text:

---

   This document introduces no = new security risks.  [RFC6378] points out
   that MPLS = relies on assumptions about traffic injection difficulty
   = and assumes that the control plane does not have end-to-end = security.
   [RFC5920] describes MPLS security issues and = generic methods for
   securing traffic privacy and = integrity.  MPLS use should conform such
   = advice.
---

 

Again, thanks for your = help.

 

Jeong-dong


 

From : "Hilarie Orman" = <ho@alum.mit.edu>
Sent : 2014-02-24 14:51:55 ( +09:00 = )
To : Ryoo, Jeong-dong <ryoo@etri.re.kr>
Cc : = secdir@ietf.org <secdir@ietf.org>, iesg@ietf.org = <iesg@ietf.org>, draft-ietf-mpls-tp-psc-itu@tools.ietf.org = <draft-ietf-mpls-tp-psc-itu@tools.ietf.org>
Subject : = RE: Security review of = draft-ietf-mpls-tp-psc-itu-02.txt

Something = like:

"This document introduces no new security risks. RFC = 6378 points out
that MPLS relies on assumptions about traffic = injection difficulty and
assumes the the control plane does not have = end-to-end security.
RFC520 describes MPLS security issues and = generic methods for securing
traffic privacy and integrity. MPLS use = should conform such advice."

Hilarie


> From: = "Ryoo, Jeong-dong"
> Date: Mon, 24 Feb 2014 04:35:08 = +0000
Dear Hilarie,

Thanks for your comment.

I am not = sure about what text has actually to be put in the Section 13 to reflect = your suggestion.
Do you have any text in mind?

Best = regards,

Jeong-dong



_______________________________= _
From : "Hilarie Orman"
Sent : 2014-02-24 09:36:04 ( = +09:00 )
To : iesg@ietf.org , secdir@ietf.org
Cc : = draft-ietf-mpls-tp-psc-itu@tools.ietf.org
Subject : Security review = of draft-ietf-mpls-tp-psc-itu-02.txt

Security review of = draft-ietf-mpls-tp-psc-itu-02.txt
MPLS Transport Profile (MPLS-TP) = Linear Protection to Match the
Operational Expectations of SDH, OTN = and Ethernet Transport Network
Operators

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

The = abstract for this document states:
This document describes alternate = mechanisms to perform some of the
sub-functions of MPLS Transport = Profile (MPLS-TP) linear protection
defined in RFC 6378, and also = defines additional mechanisms. The
purpose of these alternate and = additional mechanisms is to provide
operator control and experience = that more closely models the behavior
of linear protection seen in = other transport networks.

The security considerations are the = timeworn statement that

No specific security issue is raised in = addition to those ones
already documented in RFC 6378 = [RFC6378]

In RFC 6378 we find:
MPLS networks make the = assumption that it is very hard to inject
traffic into a network and = equally hard to cause traffic to be
directed outside the network. The = control-plane protocols utilize
hop-by-hop security and assume a = "chain-of-trust" model such that
end-to-end control-plane = security is not used. For more
information on the generic aspects of = MPLS security, see [RFC5920].

To my great astonishment I found = that "RFC5920 Security Framework for
MPLS and GMPLS = Networks" is an excellent document, and it is my
suggestion that = the current draft reference it directly in section 13
"Security = Considerations".

Barring any surprises in the extensive = state diagrams, I otherwise am
inclined to accept the "no new = issues" handwave.

Hilarie


------=_NextPart_000_06F6_01CF313D.9E5F3740-- From nobody Mon Feb 24 06:14:23 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720911A02D6; Sun, 23 Feb 2014 20:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.747 X-Spam-Level: X-Spam-Status: No, score=-99.747 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-6Xzg2DXoDD; Sun, 23 Feb 2014 20:35:13 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id 43B2C1A02D3; Sun, 23 Feb 2014 20:35:13 -0800 (PST) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 24 Feb 2014 13:35:11 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP1.etri.info ([10.2.6.30]) with mapi id 14.01.0355.002; Mon, 24 Feb 2014 13:35:09 +0900 From: "Ryoo, Jeong-dong" To: Hilarie Orman , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: Security review of draft-ietf-mpls-tp-psc-itu-02.txt Thread-Index: AQHPMPhmcEPEmfgwVU+f2hJoAKx3MZrDz+c+ Date: Mon, 24 Feb 2014 04:35:08 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286BA563@SMTP2.etri.info> References: <201402240035.s1O0ZRJl014980@sylvester.rhmr.com> In-Reply-To: <201402240035.s1O0ZRJl014980@sylvester.rhmr.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286BA563SMTP2etriinfo_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/iRIrbGQDKOlAXsB6FL1t8o0giBo X-Mailman-Approved-At: Mon, 24 Feb 2014 06:14:21 -0800 Cc: "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" Subject: Re: [secdir] Security review of draft-ietf-mpls-tp-psc-itu-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 04:35:16 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286BA563SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBIaWxhcmllLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudC4NCg0KSSBhbSBub3Qgc3Vy ZSBhYm91dCB3aGF0IHRleHQgaGFzIGFjdHVhbGx5IHRvIGJlIHB1dCBpbiB0aGUgU2VjdGlvbiAx MyB0byByZWZsZWN0IHlvdXIgc3VnZ2VzdGlvbi4NCkRvIHlvdSBoYXZlIGFueSB0ZXh0IGluIG1p bmQ/DQoNCkJlc3QgcmVnYXJkcywNCg0KSmVvbmctZG9uZw0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkZyb20gOiAiSGlsYXJpZSBPcm1hbiIgPGhvQGFsdW0ubWl0LmVk dT4NClNlbnQgOiAyMDE0LTAyLTI0IDA5OjM2OjA0ICggKzA5OjAwICkNClRvIDogaWVzZ0BpZXRm Lm9yZyA8aWVzZ0BpZXRmLm9yZz4sIHNlY2RpckBpZXRmLm9yZyA8c2VjZGlyQGlldGYub3JnPg0K Q2MgOiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyA8ZHJhZnQtaWV0 Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0IDogU2VjdXJpdHkgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1LTAyLnR4dA0KDQpTZWN1cml0eSByZXZp ZXcgb2YgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUtMDIudHh0DQpNUExTIFRyYW5zcG9ydCBQ cm9maWxlIChNUExTLVRQKSBMaW5lYXIgUHJvdGVjdGlvbiB0byBNYXRjaCB0aGUNCk9wZXJhdGlv bmFsIEV4cGVjdGF0aW9ucyBvZiBTREgsIE9UTiBhbmQgRXRoZXJuZXQgVHJhbnNwb3J0IE5ldHdv cmsNCk9wZXJhdG9ycw0KDQpEbyBub3QgYmUgYWxhcm1lZC4gSSBoYXZlIHJldmlld2VkIHRoaXMg ZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUNCnNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBl ZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cw0KYmVpbmcgcHJvY2Vzc2VkIGJ5IHRo ZSBJRVNHLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5DQpmb3IgdGhlIGJl bmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFu ZA0KV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90 aGVyIGxhc3QgY2FsbA0KY29tbWVudHMuDQoNClRoZSBhYnN0cmFjdCBmb3IgdGhpcyBkb2N1bWVu dCBzdGF0ZXM6DQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhbHRlcm5hdGUgbWVjaGFuaXNtcyB0 byBwZXJmb3JtIHNvbWUgb2YgdGhlDQpzdWItZnVuY3Rpb25zIG9mIE1QTFMgVHJhbnNwb3J0IFBy b2ZpbGUgKE1QTFMtVFApIGxpbmVhciBwcm90ZWN0aW9uDQpkZWZpbmVkIGluIFJGQyA2Mzc4LCBh bmQgYWxzbyBkZWZpbmVzIGFkZGl0aW9uYWwgbWVjaGFuaXNtcy4gVGhlDQpwdXJwb3NlIG9mIHRo ZXNlIGFsdGVybmF0ZSBhbmQgYWRkaXRpb25hbCBtZWNoYW5pc21zIGlzIHRvIHByb3ZpZGUNCm9w ZXJhdG9yIGNvbnRyb2wgYW5kIGV4cGVyaWVuY2UgdGhhdCBtb3JlIGNsb3NlbHkgbW9kZWxzIHRo ZSBiZWhhdmlvcg0Kb2YgbGluZWFyIHByb3RlY3Rpb24gc2VlbiBpbiBvdGhlciB0cmFuc3BvcnQg bmV0d29ya3MuDQoNClRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhcmUgdGhlIHRpbWV3b3Ju IHN0YXRlbWVudCB0aGF0DQoNCk5vIHNwZWNpZmljIHNlY3VyaXR5IGlzc3VlIGlzIHJhaXNlZCBp biBhZGRpdGlvbiB0byB0aG9zZSBvbmVzDQphbHJlYWR5IGRvY3VtZW50ZWQgaW4gUkZDIDYzNzgg W1JGQzYzNzhdDQoNCkluIFJGQyA2Mzc4IHdlIGZpbmQ6DQpNUExTIG5ldHdvcmtzIG1ha2UgdGhl IGFzc3VtcHRpb24gdGhhdCBpdCBpcyB2ZXJ5IGhhcmQgdG8gaW5qZWN0DQp0cmFmZmljIGludG8g YSBuZXR3b3JrIGFuZCBlcXVhbGx5IGhhcmQgdG8gY2F1c2UgdHJhZmZpYyB0byBiZQ0KZGlyZWN0 ZWQgb3V0c2lkZSB0aGUgbmV0d29yay4gVGhlIGNvbnRyb2wtcGxhbmUgcHJvdG9jb2xzIHV0aWxp emUNCmhvcC1ieS1ob3Agc2VjdXJpdHkgYW5kIGFzc3VtZSBhICJjaGFpbi1vZi10cnVzdCIgbW9k ZWwgc3VjaCB0aGF0DQplbmQtdG8tZW5kIGNvbnRyb2wtcGxhbmUgc2VjdXJpdHkgaXMgbm90IHVz ZWQuIEZvciBtb3JlDQppbmZvcm1hdGlvbiBvbiB0aGUgZ2VuZXJpYyBhc3BlY3RzIG9mIE1QTFMg c2VjdXJpdHksIHNlZSBbUkZDNTkyMF0uDQoNClRvIG15IGdyZWF0IGFzdG9uaXNobWVudCBJIGZv dW5kIHRoYXQgIlJGQzU5MjAgU2VjdXJpdHkgRnJhbWV3b3JrIGZvcg0KTVBMUyBhbmQgR01QTFMg TmV0d29ya3MiIGlzIGFuIGV4Y2VsbGVudCBkb2N1bWVudCwgYW5kIGl0IGlzIG15DQpzdWdnZXN0 aW9uIHRoYXQgdGhlIGN1cnJlbnQgZHJhZnQgcmVmZXJlbmNlIGl0IGRpcmVjdGx5IGluIHNlY3Rp b24gMTMNCiJTZWN1cml0eSBDb25zaWRlcmF0aW9ucyIuDQoNCkJhcnJpbmcgYW55IHN1cnByaXNl cyBpbiB0aGUgZXh0ZW5zaXZlIHN0YXRlIGRpYWdyYW1zLCBJIG90aGVyd2lzZSBhbQ0KaW5jbGlu ZWQgdG8gYWNjZXB0IHRoZSAibm8gbmV3IGlzc3VlcyIgaGFuZHdhdmUuDQoNCkhpbGFyaWUNCg0K DQoNCg0KDQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286BA563SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5EZWFyIEhpbGFyaWUsPC9kaXY+DQo8ZGl2IHN0 eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhF SUdIVDogMTVwdCI+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnQuPC9kaXY+DQo8ZGl2IHN0eWxlPSJM SU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDog MTVwdCI+SSBhbSBub3Qgc3VyZSBhYm91dCB3aGF0IHRleHQgaGFzIGFjdHVhbGx5IHRvIGJlIHB1 dCBpbiB0aGUgU2VjdGlvbiAxMyB0byByZWZsZWN0IHlvdXIgc3VnZ2VzdGlvbi48L2Rpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5EbyB5b3UgaGF2ZSBhbnkgdGV4dCBpbiBtaW5k PzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRp diBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkJlc3QgcmVnYXJkcyw8L2Rpdj4NCjxkaXYgc3R5 bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0Ij5KZW9uZy1kb25nPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+PGJyPg0KJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgaWQ9 Ik1haWxTaWduIj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4N CjxociB0YWJpbmRleD0iLTEiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+PGI+RnJvbSA6IDwvYj4mcXVvdDtIaWxhcmllIE9ybWFuJnF1b3Q7ICZsdDtob0BhbHVtLm1p dC5lZHUmZ3Q7PGJyPg0KPGI+U2VudCA6IDwvYj4yMDE0LTAyLTI0IDA5OjM2OjA0ICggJiM0Mzsw OTowMCApPGJyPg0KPGI+VG8gOiA8L2I+aWVzZ0BpZXRmLm9yZyAmbHQ7aWVzZ0BpZXRmLm9yZyZn dDssIHNlY2RpckBpZXRmLm9yZyAmbHQ7c2VjZGlyQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjIDog PC9iPmRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnICZsdDtkcmFmdC1p ZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0IDog PC9iPlNlY3VyaXR5IHJldmlldyBvZiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS0wMi50eHQ8 YnI+DQo8YnI+DQpTZWN1cml0eSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUt MDIudHh0PGJyPg0KTVBMUyBUcmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgTGluZWFyIFByb3Rl Y3Rpb24gdG8gTWF0Y2ggdGhlPGJyPg0KT3BlcmF0aW9uYWwgRXhwZWN0YXRpb25zIG9mIFNESCwg T1ROIGFuZCBFdGhlcm5ldCBUcmFuc3BvcnQgTmV0d29yazxicj4NCk9wZXJhdG9ycyA8YnI+DQo8 YnI+DQpEbyBub3QgYmUgYWxhcm1lZC4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMg cGFydCBvZiB0aGU8YnI+DQpzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRv IHJldmlldyBhbGwgSUVURiBkb2N1bWVudHM8YnI+DQpiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElF U0cuIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHk8YnI+DQpmb3IgdGhlIGJl bmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFu ZDxicj4NCldHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFu eSBvdGhlciBsYXN0IGNhbGw8YnI+DQpjb21tZW50cy48YnI+DQo8YnI+DQpUaGUgYWJzdHJhY3Qg Zm9yIHRoaXMgZG9jdW1lbnQgc3RhdGVzOjxicj4NClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFs dGVybmF0ZSBtZWNoYW5pc21zIHRvIHBlcmZvcm0gc29tZSBvZiB0aGU8YnI+DQpzdWItZnVuY3Rp b25zIG9mIE1QTFMgVHJhbnNwb3J0IFByb2ZpbGUgKE1QTFMtVFApIGxpbmVhciBwcm90ZWN0aW9u PGJyPg0KZGVmaW5lZCBpbiBSRkMgNjM3OCwgYW5kIGFsc28gZGVmaW5lcyBhZGRpdGlvbmFsIG1l Y2hhbmlzbXMuIFRoZTxicj4NCnB1cnBvc2Ugb2YgdGhlc2UgYWx0ZXJuYXRlIGFuZCBhZGRpdGlv bmFsIG1lY2hhbmlzbXMgaXMgdG8gcHJvdmlkZTxicj4NCm9wZXJhdG9yIGNvbnRyb2wgYW5kIGV4 cGVyaWVuY2UgdGhhdCBtb3JlIGNsb3NlbHkgbW9kZWxzIHRoZSBiZWhhdmlvcjxicj4NCm9mIGxp bmVhciBwcm90ZWN0aW9uIHNlZW4gaW4gb3RoZXIgdHJhbnNwb3J0IG5ldHdvcmtzLjxicj4NCjxi cj4NClRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhcmUgdGhlIHRpbWV3b3JuIHN0YXRlbWVu dCB0aGF0PGJyPg0KPGJyPg0KTm8gc3BlY2lmaWMgc2VjdXJpdHkgaXNzdWUgaXMgcmFpc2VkIGlu IGFkZGl0aW9uIHRvIHRob3NlIG9uZXM8YnI+DQphbHJlYWR5IGRvY3VtZW50ZWQgaW4gUkZDIDYz NzggW1JGQzYzNzhdPGJyPg0KPGJyPg0KSW4gUkZDIDYzNzggd2UgZmluZDogPGJyPg0KTVBMUyBu ZXR3b3JrcyBtYWtlIHRoZSBhc3N1bXB0aW9uIHRoYXQgaXQgaXMgdmVyeSBoYXJkIHRvIGluamVj dDxicj4NCnRyYWZmaWMgaW50byBhIG5ldHdvcmsgYW5kIGVxdWFsbHkgaGFyZCB0byBjYXVzZSB0 cmFmZmljIHRvIGJlPGJyPg0KZGlyZWN0ZWQgb3V0c2lkZSB0aGUgbmV0d29yay4gVGhlIGNvbnRy b2wtcGxhbmUgcHJvdG9jb2xzIHV0aWxpemU8YnI+DQpob3AtYnktaG9wIHNlY3VyaXR5IGFuZCBh c3N1bWUgYSAmcXVvdDtjaGFpbi1vZi10cnVzdCZxdW90OyBtb2RlbCBzdWNoIHRoYXQ8YnI+DQpl bmQtdG8tZW5kIGNvbnRyb2wtcGxhbmUgc2VjdXJpdHkgaXMgbm90IHVzZWQuIEZvciBtb3JlPGJy Pg0KaW5mb3JtYXRpb24gb24gdGhlIGdlbmVyaWMgYXNwZWN0cyBvZiBNUExTIHNlY3VyaXR5LCBz ZWUgW1JGQzU5MjBdLjxicj4NCjxicj4NClRvIG15IGdyZWF0IGFzdG9uaXNobWVudCBJIGZvdW5k IHRoYXQgJnF1b3Q7UkZDNTkyMCBTZWN1cml0eSBGcmFtZXdvcmsgZm9yPGJyPg0KTVBMUyBhbmQg R01QTFMgTmV0d29ya3MmcXVvdDsgaXMgYW4gZXhjZWxsZW50IGRvY3VtZW50LCBhbmQgaXQgaXMg bXk8YnI+DQpzdWdnZXN0aW9uIHRoYXQgdGhlIGN1cnJlbnQgZHJhZnQgcmVmZXJlbmNlIGl0IGRp cmVjdGx5IGluIHNlY3Rpb24gMTM8YnI+DQomcXVvdDtTZWN1cml0eSBDb25zaWRlcmF0aW9ucyZx dW90Oy48YnI+DQo8YnI+DQpCYXJyaW5nIGFueSBzdXJwcmlzZXMgaW4gdGhlIGV4dGVuc2l2ZSBz dGF0ZSBkaWFncmFtcywgSSBvdGhlcndpc2UgYW08YnI+DQppbmNsaW5lZCB0byBhY2NlcHQgdGhl ICZxdW90O25vIG5ldyBpc3N1ZXMmcXVvdDsgaGFuZHdhdmUuPGJyPg0KPGJyPg0KSGlsYXJpZTxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286BA563SMTP2etriinfo_-- From nobody Mon Feb 24 06:14:25 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6641A032A; Sun, 23 Feb 2014 22:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CQkhDs1A1YJ; Sun, 23 Feb 2014 22:23:52 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id 375431A0321; Sun, 23 Feb 2014 22:23:52 -0800 (PST) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 24 Feb 2014 15:23:50 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP1.etri.info ([10.2.6.30]) with mapi id 14.01.0355.002; Mon, 24 Feb 2014 15:23:50 +0900 From: "Ryoo, Jeong-dong" To: Hilarie Orman Thread-Topic: Security review of draft-ietf-mpls-tp-psc-itu-02.txt Thread-Index: AQHPMSR9cEPEmfgwVU+f2hJoAKx3MZrD7at2 Date: Mon, 24 Feb 2014 06:23:49 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286BA60B@SMTP2.etri.info> References: Yourmessage <5B4A6CBE3924BB41A3BEE462A8E0B75A286BA563@SMTP2.etri.info>, <201402240551.s1O5pfrm000621@sylvester.rhmr.com> In-Reply-To: <201402240551.s1O5pfrm000621@sylvester.rhmr.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286BA60BSMTP2etriinfo_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/z9pMNwaLSnck4k0ph9gsqQBHaKo X-Mailman-Approved-At: Mon, 24 Feb 2014 06:14:22 -0800 Cc: "draft-ietf-mpls-tp-psc-itu@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Security review of draft-ietf-mpls-tp-psc-itu-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 06:23:55 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286BA60BSMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGlsYXJpZSwgdGhhbmtzIGZvciB0aGUgdGV4dC4NCg0KSWYgdGhlcmUgaXMgbm8gb2JqZWN0aW9u IGZyb20gb3RoZXJzLA0KSSB3aWxsIGFkZCBbUkZDNTkyMF0gaW4gdGhlIEluZm9ybWF0aXZlIHJl ZmVyZW5jZSBzZWN0aW9uDQphbmQgcmVwbGFjZSBjdXJyZW50IHRleHQgaW4gU2VjdGlvbiAxMyB3 aXRoIHRoZSBmb2xsb3dpbmcgdGV4dDoNCi0tLQ0KICAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2Vz IG5vIG5ldyBzZWN1cml0eSByaXNrcy4gIFtSRkM2Mzc4XSBwb2ludHMgb3V0DQogICB0aGF0IE1Q TFMgcmVsaWVzIG9uIGFzc3VtcHRpb25zIGFib3V0IHRyYWZmaWMgaW5qZWN0aW9uIGRpZmZpY3Vs dHkNCiAgIGFuZCBhc3N1bWVzIHRoYXQgdGhlIGNvbnRyb2wgcGxhbmUgZG9lcyBub3QgaGF2ZSBl bmQtdG8tZW5kIHNlY3VyaXR5Lg0KICAgW1JGQzU5MjBdIGRlc2NyaWJlcyBNUExTIHNlY3VyaXR5 IGlzc3VlcyBhbmQgZ2VuZXJpYyBtZXRob2RzIGZvcg0KICAgc2VjdXJpbmcgdHJhZmZpYyBwcml2 YWN5IGFuZCBpbnRlZ3JpdHkuICBNUExTIHVzZSBzaG91bGQgY29uZm9ybSBzdWNoDQogICBhZHZp Y2UuDQotLS0NCg0KQWdhaW4sIHRoYW5rcyBmb3IgeW91ciBoZWxwLg0KDQpKZW9uZy1kb25nDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb20gOiAiSGlsYXJpZSBPcm1h biIgPGhvQGFsdW0ubWl0LmVkdT4NClNlbnQgOiAyMDE0LTAyLTI0IDE0OjUxOjU1ICggKzA5OjAw ICkNClRvIDogUnlvbywgSmVvbmctZG9uZyA8cnlvb0BldHJpLnJlLmtyPg0KQ2MgOiBzZWNkaXJA aWV0Zi5vcmcgPHNlY2RpckBpZXRmLm9yZz4sIGllc2dAaWV0Zi5vcmcgPGllc2dAaWV0Zi5vcmc+ LCBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyA8ZHJhZnQtaWV0Zi1t cGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0IDogUkU6IFNlY3VyaXR5IHJl dmlldyBvZiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS0wMi50eHQNCg0KU29tZXRoaW5nIGxp a2U6DQoNCiJUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgbm8gbmV3IHNlY3VyaXR5IHJpc2tzLiBS RkMgNjM3OCBwb2ludHMgb3V0DQp0aGF0IE1QTFMgcmVsaWVzIG9uIGFzc3VtcHRpb25zIGFib3V0 IHRyYWZmaWMgaW5qZWN0aW9uIGRpZmZpY3VsdHkgYW5kDQphc3N1bWVzIHRoZSB0aGUgY29udHJv bCBwbGFuZSBkb2VzIG5vdCBoYXZlIGVuZC10by1lbmQgc2VjdXJpdHkuDQpSRkM1MjAgZGVzY3Jp YmVzIE1QTFMgc2VjdXJpdHkgaXNzdWVzIGFuZCBnZW5lcmljIG1ldGhvZHMgZm9yIHNlY3VyaW5n DQp0cmFmZmljIHByaXZhY3kgYW5kIGludGVncml0eS4gTVBMUyB1c2Ugc2hvdWxkIGNvbmZvcm0g c3VjaCBhZHZpY2UuIg0KDQpIaWxhcmllDQoNCg0KPiBGcm9tOiAiUnlvbywgSmVvbmctZG9uZyIN Cj4gRGF0ZTogTW9uLCAyNCBGZWIgMjAxNCAwNDozNTowOCArMDAwMA0KRGVhciBIaWxhcmllLA0K DQpUaGFua3MgZm9yIHlvdXIgY29tbWVudC4NCg0KSSBhbSBub3Qgc3VyZSBhYm91dCB3aGF0IHRl eHQgaGFzIGFjdHVhbGx5IHRvIGJlIHB1dCBpbiB0aGUgU2VjdGlvbiAxMyB0byByZWZsZWN0IHlv dXIgc3VnZ2VzdGlvbi4NCkRvIHlvdSBoYXZlIGFueSB0ZXh0IGluIG1pbmQ/DQoNCkJlc3QgcmVn YXJkcywNCg0KSmVvbmctZG9uZw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkZyb20gOiAiSGlsYXJpZSBPcm1hbiINClNlbnQgOiAyMDE0LTAyLTI0IDA5OjM2OjA0ICgg KzA5OjAwICkNClRvIDogaWVzZ0BpZXRmLm9yZyAsIHNlY2RpckBpZXRmLm9yZw0KQ2MgOiBkcmFm dC1pZXRmLW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZw0KU3ViamVjdCA6IFNlY3VyaXR5 IHJldmlldyBvZiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS0wMi50eHQNCg0KU2VjdXJpdHkg cmV2aWV3IG9mIGRyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1LTAyLnR4dA0KTVBMUyBUcmFuc3Bv cnQgUHJvZmlsZSAoTVBMUy1UUCkgTGluZWFyIFByb3RlY3Rpb24gdG8gTWF0Y2ggdGhlDQpPcGVy YXRpb25hbCBFeHBlY3RhdGlvbnMgb2YgU0RILCBPVE4gYW5kIEV0aGVybmV0IFRyYW5zcG9ydCBO ZXR3b3JrDQpPcGVyYXRvcnMNCg0KRG8gbm90IGJlIGFsYXJtZWQuIEkgaGF2ZSByZXZpZXdlZCB0 aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlDQpzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29p bmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMNCmJlaW5nIHByb2Nlc3NlZCBi eSB0aGUgSUVTRy4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseQ0KZm9yIHRo ZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9y cyBhbmQNCldHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFu eSBvdGhlciBsYXN0IGNhbGwNCmNvbW1lbnRzLg0KDQpUaGUgYWJzdHJhY3QgZm9yIHRoaXMgZG9j dW1lbnQgc3RhdGVzOg0KVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYWx0ZXJuYXRlIG1lY2hhbmlz bXMgdG8gcGVyZm9ybSBzb21lIG9mIHRoZQ0Kc3ViLWZ1bmN0aW9ucyBvZiBNUExTIFRyYW5zcG9y dCBQcm9maWxlIChNUExTLVRQKSBsaW5lYXIgcHJvdGVjdGlvbg0KZGVmaW5lZCBpbiBSRkMgNjM3 OCwgYW5kIGFsc28gZGVmaW5lcyBhZGRpdGlvbmFsIG1lY2hhbmlzbXMuIFRoZQ0KcHVycG9zZSBv ZiB0aGVzZSBhbHRlcm5hdGUgYW5kIGFkZGl0aW9uYWwgbWVjaGFuaXNtcyBpcyB0byBwcm92aWRl DQpvcGVyYXRvciBjb250cm9sIGFuZCBleHBlcmllbmNlIHRoYXQgbW9yZSBjbG9zZWx5IG1vZGVs cyB0aGUgYmVoYXZpb3INCm9mIGxpbmVhciBwcm90ZWN0aW9uIHNlZW4gaW4gb3RoZXIgdHJhbnNw b3J0IG5ldHdvcmtzLg0KDQpUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYXJlIHRoZSB0aW1l d29ybiBzdGF0ZW1lbnQgdGhhdA0KDQpObyBzcGVjaWZpYyBzZWN1cml0eSBpc3N1ZSBpcyByYWlz ZWQgaW4gYWRkaXRpb24gdG8gdGhvc2Ugb25lcw0KYWxyZWFkeSBkb2N1bWVudGVkIGluIFJGQyA2 Mzc4IFtSRkM2Mzc4XQ0KDQpJbiBSRkMgNjM3OCB3ZSBmaW5kOg0KTVBMUyBuZXR3b3JrcyBtYWtl IHRoZSBhc3N1bXB0aW9uIHRoYXQgaXQgaXMgdmVyeSBoYXJkIHRvIGluamVjdA0KdHJhZmZpYyBp bnRvIGEgbmV0d29yayBhbmQgZXF1YWxseSBoYXJkIHRvIGNhdXNlIHRyYWZmaWMgdG8gYmUNCmRp cmVjdGVkIG91dHNpZGUgdGhlIG5ldHdvcmsuIFRoZSBjb250cm9sLXBsYW5lIHByb3RvY29scyB1 dGlsaXplDQpob3AtYnktaG9wIHNlY3VyaXR5IGFuZCBhc3N1bWUgYSAiY2hhaW4tb2YtdHJ1c3Qi IG1vZGVsIHN1Y2ggdGhhdA0KZW5kLXRvLWVuZCBjb250cm9sLXBsYW5lIHNlY3VyaXR5IGlzIG5v dCB1c2VkLiBGb3IgbW9yZQ0KaW5mb3JtYXRpb24gb24gdGhlIGdlbmVyaWMgYXNwZWN0cyBvZiBN UExTIHNlY3VyaXR5LCBzZWUgW1JGQzU5MjBdLg0KDQpUbyBteSBncmVhdCBhc3RvbmlzaG1lbnQg SSBmb3VuZCB0aGF0ICJSRkM1OTIwIFNlY3VyaXR5IEZyYW1ld29yayBmb3INCk1QTFMgYW5kIEdN UExTIE5ldHdvcmtzIiBpcyBhbiBleGNlbGxlbnQgZG9jdW1lbnQsIGFuZCBpdCBpcyBteQ0Kc3Vn Z2VzdGlvbiB0aGF0IHRoZSBjdXJyZW50IGRyYWZ0IHJlZmVyZW5jZSBpdCBkaXJlY3RseSBpbiBz ZWN0aW9uIDEzDQoiU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiLg0KDQpCYXJyaW5nIGFueSBzdXJw cmlzZXMgaW4gdGhlIGV4dGVuc2l2ZSBzdGF0ZSBkaWFncmFtcywgSSBvdGhlcndpc2UgYW0NCmlu Y2xpbmVkIHRvIGFjY2VwdCB0aGUgIm5vIG5ldyBpc3N1ZXMiIGhhbmR3YXZlLg0KDQpIaWxhcmll DQoNCg0KDQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286BA60BSMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5IaWxhcmllLCB0aGFua3MgZm9yIHRoZSB0ZXh0 LjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRp diBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPklmIHRoZXJlIGlzIG5vIG9iamVjdGlvbiBmcm9t IG90aGVycywgPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+SSB3aWxsIGFk ZCBbUkZDNTkyMF0gaW4gdGhlIEluZm9ybWF0aXZlIHJlZmVyZW5jZSBzZWN0aW9uJm5ic3A7PC9k aXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+YW5kJm5ic3A7cmVwbGFjZSBjdXJy ZW50IHRleHQgaW4gU2VjdGlvbiAxMyB3aXRoIHRoZSBmb2xsb3dpbmcgdGV4dDo8L2Rpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4tLS08L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUt SEVJR0hUOiAxNXB0Ij4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIG5vIG5l dyBzZWN1cml0eSByaXNrcy4mbmJzcDsgW1JGQzYzNzhdIHBvaW50cyBvdXQ8YnI+DQombmJzcDsm bmJzcDsgdGhhdCBNUExTIHJlbGllcyBvbiBhc3N1bXB0aW9ucyBhYm91dCB0cmFmZmljIGluamVj dGlvbiBkaWZmaWN1bHR5PGJyPg0KJm5ic3A7Jm5ic3A7IGFuZCBhc3N1bWVzIHRoYXQgdGhlIGNv bnRyb2wgcGxhbmUgZG9lcyBub3QgaGF2ZSBlbmQtdG8tZW5kIHNlY3VyaXR5Ljxicj4NCiZuYnNw OyZuYnNwOyBbUkZDNTkyMF0gZGVzY3JpYmVzIE1QTFMgc2VjdXJpdHkgaXNzdWVzIGFuZCBnZW5l cmljIG1ldGhvZHMgZm9yPGJyPg0KJm5ic3A7Jm5ic3A7IHNlY3VyaW5nIHRyYWZmaWMgcHJpdmFj eSBhbmQgaW50ZWdyaXR5LiZuYnNwOyBNUExTIHVzZSBzaG91bGQgY29uZm9ybSBzdWNoPGJyPg0K Jm5ic3A7Jm5ic3A7IGFkdmljZS48YnI+DQotLS08L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5B Z2FpbiwgdGhhbmtzIGZvciB5b3VyIGhlbHAuPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdI VDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+SmVv bmctZG9uZzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPjxicj4NCiZuYnNw OzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPg0KPGhyIHRhYmluZGV4PSIt MSI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij48Yj5Gcm9tIDogPC9i PiZxdW90O0hpbGFyaWUgT3JtYW4mcXVvdDsgJmx0O2hvQGFsdW0ubWl0LmVkdSZndDs8YnI+DQo8 Yj5TZW50IDogPC9iPjIwMTQtMDItMjQgMTQ6NTE6NTUgKCAmIzQzOzA5OjAwICk8YnI+DQo8Yj5U byA6IDwvYj5SeW9vLCBKZW9uZy1kb25nICZsdDtyeW9vQGV0cmkucmUua3ImZ3Q7PGJyPg0KPGI+ Q2MgOiA8L2I+c2VjZGlyQGlldGYub3JnICZsdDtzZWNkaXJAaWV0Zi5vcmcmZ3Q7LCBpZXNnQGll dGYub3JnICZsdDtpZXNnQGlldGYub3JnJmd0OywgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVA dG9vbHMuaWV0Zi5vcmcgJmx0O2RyYWZ0LWlldGYtbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYu b3JnJmd0Ozxicj4NCjxiPlN1YmplY3QgOiA8L2I+UkU6IFNlY3VyaXR5IHJldmlldyBvZiBkcmFm dC1pZXRmLW1wbHMtdHAtcHNjLWl0dS0wMi50eHQ8YnI+DQo8YnI+DQpTb21ldGhpbmcgbGlrZTo8 YnI+DQo8YnI+DQomcXVvdDtUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgbm8gbmV3IHNlY3VyaXR5 IHJpc2tzLiBSRkMgNjM3OCBwb2ludHMgb3V0PGJyPg0KdGhhdCBNUExTIHJlbGllcyBvbiBhc3N1 bXB0aW9ucyBhYm91dCB0cmFmZmljIGluamVjdGlvbiBkaWZmaWN1bHR5IGFuZDxicj4NCmFzc3Vt ZXMgdGhlIHRoZSBjb250cm9sIHBsYW5lIGRvZXMgbm90IGhhdmUgZW5kLXRvLWVuZCBzZWN1cml0 eS48YnI+DQpSRkM1MjAgZGVzY3JpYmVzIE1QTFMgc2VjdXJpdHkgaXNzdWVzIGFuZCBnZW5lcmlj IG1ldGhvZHMgZm9yIHNlY3VyaW5nPGJyPg0KdHJhZmZpYyBwcml2YWN5IGFuZCBpbnRlZ3JpdHku IE1QTFMgdXNlIHNob3VsZCBjb25mb3JtIHN1Y2ggYWR2aWNlLiZxdW90Ozxicj4NCjxicj4NCkhp bGFyaWU8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IEZyb206ICZxdW90O1J5b28sIEplb25nLWRvbmcm cXVvdDsgPFJZT09ARVRSSS5SRS5LUj48YnI+DQomZ3Q7IERhdGU6IE1vbiwgMjQgRmViIDIwMTQg MDQ6MzU6MDggJiM0MzswMDAwPGJyPg0KRGVhciBIaWxhcmllLDxicj4NCjxicj4NClRoYW5rcyBm b3IgeW91ciBjb21tZW50Ljxicj4NCjxicj4NCkkgYW0gbm90IHN1cmUgYWJvdXQgd2hhdCB0ZXh0 IGhhcyBhY3R1YWxseSB0byBiZSBwdXQgaW4gdGhlIFNlY3Rpb24gMTMgdG8gcmVmbGVjdCB5b3Vy IHN1Z2dlc3Rpb24uPGJyPg0KRG8geW91IGhhdmUgYW55IHRleHQgaW4gbWluZD88YnI+DQo8YnI+ DQpCZXN0IHJlZ2FyZHMsPGJyPg0KPGJyPg0KSmVvbmctZG9uZzxicj4NCjxicj4NCjxicj4NCjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRnJvbSA6ICZxdW90O0hp bGFyaWUgT3JtYW4mcXVvdDsgPEhPQEFMVU0uTUlULkVEVT48YnI+DQpTZW50IDogMjAxNC0wMi0y NCAwOTozNjowNCAoICYjNDM7MDk6MDAgKTxicj4NClRvIDogaWVzZ0BpZXRmLm9yZyA8SUVTR0BJ RVRGLk9SRz4sIHNlY2RpckBpZXRmLm9yZyA8U0VDRElSQElFVEYuT1JHPjxicj4NCkNjIDogZHJh ZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcgPERSQUZULUlFVEYtTVBMUy1U UC1QU0MtSVRVQFRPT0xTLklFVEYuT1JHPg0KPGJyPg0KU3ViamVjdCA6IFNlY3VyaXR5IHJldmll dyBvZiBkcmFmdC1pZXRmLW1wbHMtdHAtcHNjLWl0dS0wMi50eHQ8YnI+DQo8YnI+DQpTZWN1cml0 eSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1tcGxzLXRwLXBzYy1pdHUtMDIudHh0PGJyPg0KTVBMUyBU cmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgTGluZWFyIFByb3RlY3Rpb24gdG8gTWF0Y2ggdGhl PGJyPg0KT3BlcmF0aW9uYWwgRXhwZWN0YXRpb25zIG9mIFNESCwgT1ROIGFuZCBFdGhlcm5ldCBU cmFuc3BvcnQgTmV0d29yazxicj4NCk9wZXJhdG9yczxicj4NCjxicj4NCkRvIG5vdCBiZSBhbGFy bWVkLiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZTxicj4NCnNl Y3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRv Y3VtZW50czxicj4NCmJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gVGhlc2UgY29tbWVudHMg d2VyZSB3cml0dGVuIHByaW1hcmlseTxicj4NCmZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJp dHkgYXJlYSBkaXJlY3RvcnMuIERvY3VtZW50IGVkaXRvcnMgYW5kPGJyPg0KV0cgY2hhaXJzIHNo b3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbDxi cj4NCmNvbW1lbnRzLjxicj4NCjxicj4NClRoZSBhYnN0cmFjdCBmb3IgdGhpcyBkb2N1bWVudCBz dGF0ZXM6PGJyPg0KVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYWx0ZXJuYXRlIG1lY2hhbmlzbXMg dG8gcGVyZm9ybSBzb21lIG9mIHRoZTxicj4NCnN1Yi1mdW5jdGlvbnMgb2YgTVBMUyBUcmFuc3Bv cnQgUHJvZmlsZSAoTVBMUy1UUCkgbGluZWFyIHByb3RlY3Rpb248YnI+DQpkZWZpbmVkIGluIFJG QyA2Mzc4LCBhbmQgYWxzbyBkZWZpbmVzIGFkZGl0aW9uYWwgbWVjaGFuaXNtcy4gVGhlPGJyPg0K cHVycG9zZSBvZiB0aGVzZSBhbHRlcm5hdGUgYW5kIGFkZGl0aW9uYWwgbWVjaGFuaXNtcyBpcyB0 byBwcm92aWRlPGJyPg0Kb3BlcmF0b3IgY29udHJvbCBhbmQgZXhwZXJpZW5jZSB0aGF0IG1vcmUg Y2xvc2VseSBtb2RlbHMgdGhlIGJlaGF2aW9yPGJyPg0Kb2YgbGluZWFyIHByb3RlY3Rpb24gc2Vl biBpbiBvdGhlciB0cmFuc3BvcnQgbmV0d29ya3MuPGJyPg0KPGJyPg0KVGhlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIGFyZSB0aGUgdGltZXdvcm4gc3RhdGVtZW50IHRoYXQ8YnI+DQo8YnI+DQpO byBzcGVjaWZpYyBzZWN1cml0eSBpc3N1ZSBpcyByYWlzZWQgaW4gYWRkaXRpb24gdG8gdGhvc2Ug b25lczxicj4NCmFscmVhZHkgZG9jdW1lbnRlZCBpbiBSRkMgNjM3OCBbUkZDNjM3OF08YnI+DQo8 YnI+DQpJbiBSRkMgNjM3OCB3ZSBmaW5kOjxicj4NCk1QTFMgbmV0d29ya3MgbWFrZSB0aGUgYXNz dW1wdGlvbiB0aGF0IGl0IGlzIHZlcnkgaGFyZCB0byBpbmplY3Q8YnI+DQp0cmFmZmljIGludG8g YSBuZXR3b3JrIGFuZCBlcXVhbGx5IGhhcmQgdG8gY2F1c2UgdHJhZmZpYyB0byBiZTxicj4NCmRp cmVjdGVkIG91dHNpZGUgdGhlIG5ldHdvcmsuIFRoZSBjb250cm9sLXBsYW5lIHByb3RvY29scyB1 dGlsaXplPGJyPg0KaG9wLWJ5LWhvcCBzZWN1cml0eSBhbmQgYXNzdW1lIGEgJnF1b3Q7Y2hhaW4t b2YtdHJ1c3QmcXVvdDsgbW9kZWwgc3VjaCB0aGF0PGJyPg0KZW5kLXRvLWVuZCBjb250cm9sLXBs YW5lIHNlY3VyaXR5IGlzIG5vdCB1c2VkLiBGb3IgbW9yZTxicj4NCmluZm9ybWF0aW9uIG9uIHRo ZSBnZW5lcmljIGFzcGVjdHMgb2YgTVBMUyBzZWN1cml0eSwgc2VlIFtSRkM1OTIwXS48YnI+DQo8 YnI+DQpUbyBteSBncmVhdCBhc3RvbmlzaG1lbnQgSSBmb3VuZCB0aGF0ICZxdW90O1JGQzU5MjAg U2VjdXJpdHkgRnJhbWV3b3JrIGZvcjxicj4NCk1QTFMgYW5kIEdNUExTIE5ldHdvcmtzJnF1b3Q7 IGlzIGFuIGV4Y2VsbGVudCBkb2N1bWVudCwgYW5kIGl0IGlzIG15PGJyPg0Kc3VnZ2VzdGlvbiB0 aGF0IHRoZSBjdXJyZW50IGRyYWZ0IHJlZmVyZW5jZSBpdCBkaXJlY3RseSBpbiBzZWN0aW9uIDEz PGJyPg0KJnF1b3Q7U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMmcXVvdDsuPGJyPg0KPGJyPg0KQmFy cmluZyBhbnkgc3VycHJpc2VzIGluIHRoZSBleHRlbnNpdmUgc3RhdGUgZGlhZ3JhbXMsIEkgb3Ro ZXJ3aXNlIGFtPGJyPg0KaW5jbGluZWQgdG8gYWNjZXB0IHRoZSAmcXVvdDtubyBuZXcgaXNzdWVz JnF1b3Q7IGhhbmR3YXZlLjxicj4NCjxicj4NCkhpbGFyaWU8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286BA60BSMTP2etriinfo_-- From nobody Tue Feb 25 06:37:13 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2591A0758; Tue, 25 Feb 2014 06:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAsRhT4mPvvH; Tue, 25 Feb 2014 06:37:06 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id EAAC71A075B; Tue, 25 Feb 2014 06:37:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1289; q=dns/txt; s=iport; t=1393339024; x=1394548624; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=vvn6VmqBsbaBkyB5IVlXKXTEaxdfsYJ6YelXQRG4vjE=; b=PrtykBQYasBMbGitVDnhHnzmiKK9lurNECRCMPI/fWATHm6mez/miA6Q hwTYjGIIaG+EmPJUcDlX1MRVXDzZuc8V+zD33sK5EdQNxca0HTmd1tEu2 TJro0FKhtgCZsTXOlAUrVV3c6y7LprkcDmAuvZdkHaSh7Uz6hVj1I2yqp c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGCqDFOtJXG+/2dsb2JhbABZgwaBEsJoFnSCLIELAYEAJwQBiBfHAheSD4EUBJg0kieDLYIq X-IronPort-AV: E=Sophos;i="4.97,540,1389744000"; d="scan'208";a="306184612" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 25 Feb 2014 14:36:59 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1PEaws6002579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 14:36:58 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.200]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 08:36:58 -0600 From: "Klaas Wierenga (kwiereng)" To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-jcardcal-jcal.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-jcardcal-jcal-09 Thread-Index: AQHPMjcJwgX+osJyDEaPL10iZVgG5Q== Date: Tue, 25 Feb 2014 14:36:58 +0000 Message-ID: <894C08E3-0017-4830-9C8F-930CCEB5B2E2@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.106.30] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/zxSw-sAKhfIk5Y4IIFkF3jgfJhE Subject: [secdir] secdir review of draft-ietf-jcardcal-jcal-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 14:37:08 -0000 Hi, I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document specifies jCal, a JSON format for iCalendar data as well as s= emantically lossless conversion between iCalendar and jCal and vv. I believe the document is well written and ready for publication with a few= small nits: - Paragraph 3 (converting from iCal to jCal): The text looks very much like production rules, why not give ABNF? (Ah wai= t, now that I have read the full document I see that that appears in Append= ix B, I think you should at least point to Appendix B here) - Paragraph 3.4 and onwards It is unclear to me when you write for example "Each individual iCalendar p= roperty is represented in jCal by =85" whether you really mean to write: "E= ach individual iCalendar property MUST be represented in jCal by=85."=20 I assume you want to be normative in specifying the format? - Paragraph 9.2 should RFC4627 not be a normative rather than informative r= eference? Klaas=20 From nobody Tue Feb 25 07:20:41 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651491A0052; Tue, 25 Feb 2014 07:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dG7IdNocjuFC; Tue, 25 Feb 2014 07:20:38 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9661A0058; Tue, 25 Feb 2014 07:20:38 -0800 (PST) Received: by mail-qg0-f45.google.com with SMTP id j5so1429753qga.4 for ; Tue, 25 Feb 2014 07:20:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=49/DJl7bOI7q3ZP3UB4YZIDpcIMTzktbA+X3q+Yc0kA=; b=m4PPoBfFynwokmFr6qf0kRipVIjJLqH9+NT8WI9wd+o7f01PJIKdepYq9CIuekpnDQ XHdr/CW5nmsrCXoEt3UUDkIUL++41SNGm9OjOZ5br56P9MXLPbnMGXM/3CxbkTPjTzc/ UTdJN8zFc6aRGEIAgkxSMS48Hj44OL6+BvzL+DP63KuKaF07+eJRf3AfTi3UaBgfSpbO 5GnHpHaP4pnUkWKBR3ITC9RLjcKlHkKBEArwFRt9oEA7vypBnXRshO4nPv6AD807J8y5 YG240tkxrpFgUI/XVX/7Q+kbzRrroYtJ0LGoF8DfwMQqllolti1m8b9aTytPvV8wU56w peZg== MIME-Version: 1.0 X-Received: by 10.224.75.73 with SMTP id x9mr788394qaj.36.1393341637389; Tue, 25 Feb 2014 07:20:37 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.224.26.11 with HTTP; Tue, 25 Feb 2014 07:20:37 -0800 (PST) In-Reply-To: <894C08E3-0017-4830-9C8F-930CCEB5B2E2@cisco.com> References: <894C08E3-0017-4830-9C8F-930CCEB5B2E2@cisco.com> Date: Tue, 25 Feb 2014 07:20:37 -0800 X-Google-Sender-Auth: 6Mgel8adYE7GEGt7PtP_oAfUkgo Message-ID: From: Barry Leiba To: "Klaas Wierenga (kwiereng)" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/oJsJEv3MkGrBciCxEeb4VAGVbm0 Cc: "draft-ietf-jcardcal-jcal.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-jcardcal-jcal-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 15:20:39 -0000 > - Paragraph 9.2 should RFC4627 not be a normative rather than informative reference? Absolutely, because in Section 2 we have this: The underlying format used for jCal is JSON. Consequently, the terms "object" and "array" as well as the four primitive types (strings, numbers, booleans, and null) are to be interpreted as described in Section 1 of [RFC4627]. That 4627 defines terms that are used in this document, it's a normative reference. Also, authors, note that draft-ietf-json-rfc4627bis is now in AUTH48, so you'll almost certainly be changing the reference to that new RFC (it will be 7158) by the time this document is approved. Barry From nobody Tue Feb 25 09:53:15 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B401A014B for ; Tue, 25 Feb 2014 09:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deyOSEf2n8jl for ; Tue, 25 Feb 2014 09:53:09 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BAE7A1A0118 for ; Tue, 25 Feb 2014 09:53:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 99EE8BE68 for ; Tue, 25 Feb 2014 17:53:08 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RJ9mUgn8MwA for ; Tue, 25 Feb 2014 17:53:08 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8108ABE61 for ; Tue, 25 Feb 2014 17:53:08 +0000 (GMT) Message-ID: <530CD885.4020506@cs.tcd.ie> Date: Tue, 25 Feb 2014 17:53:09 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "secdir@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/2yaJTfpucvD4UOfiv1m0wFD_dWo Subject: [secdir] secdir lunch Tuesday X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 17:53:13 -0000 Hiya, We have a room for the usual get together, its Hilton Meeting Room 1-4, Tuesday 1130-1300 and as usual you need to grab some lunch and bring it with you. Feel free to email suggested topics if you have 'em now. See ya there, Cheers, S. From nobody Tue Feb 25 13:28:01 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8141A06E8; Tue, 25 Feb 2014 13:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.254 X-Spam-Level: X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqPEJfsr8qpa; Tue, 25 Feb 2014 13:27:46 -0800 (PST) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [132.250.118.211]) by ietfa.amsl.com (Postfix) with ESMTP id DF9531A029C; Tue, 25 Feb 2014 13:27:45 -0800 (PST) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id s1PLRh8i017940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 25 Feb 2014 16:27:43 -0500 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_01D8C3B3-E0B8-4770-9D1E-571E0EA77A28" Date: Tue, 25 Feb 2014 16:27:43 -0500 Message-Id: <79966625-7B22-4641-8B4E-3839AE3B67A6@nrl.navy.mil> To: secdir@ietf.org, iesg@ietf.org, draft-ietf-dmm-requirements.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/I5_7H_wO_8khJmZnF_XyctHNBLQ Subject: [secdir] Secdir review of draft-ietf-dmm-requirements-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 21:27:52 -0000 --Apple-Mail=_01D8C3B3-E0B8-4770-9D1E-571E0EA77A28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft gives high-level requirements for distributed mobility = management at the network layer. It also gives definitions of key concepts and motivation for replacing = or augmenting current standards for centralized mobility management (in = which information about location of a mobile node is kept at a centralized mobility = anchor) with distributed mobility management, in which this information is distributed. This latter includes a list of the = problems that can be addressed with DMM. Although the motivation for distributed mobility management is not the = main point of this document, it is very helpful in helping the reader understand the requirements and their importance, = so I am glad to see it there. Since this, including the problem statement, is quite important and useful, I=92d suggest = mentioning it in the abstract. The requirements are for the most part well-written and at the = appropriate level of detail. However, I have a few suggestions: 1) REQ 1 is for distributed processing, but =93distributed processing = is a rather open-ended term. It would be a good idea to include some indication of what is meant by distributed = processing here. 2) There are a couple of points in REQ6: Security considerations that = need to be clarified: 2a) Another example is that a malicious node can forge a number of signaling messages thus redirecting traffic from its legitimate path. Consequently, the specific node is under a denial of service attack, whereas other nodes do not receive their traffic. It=92s not made clear what the specific node is. It would be better to = have something like Another example is that a malicious node can forge a number of signaling messages thus redirecting traffic from its legitimate path. Consequently, the specific node or nodes to which the traffic is = redirected may be under a denial of service attack, whereas other nodes do not receive their traffic. 2b) Accordingly, security mechanisms/protocols providing access control, integrity, authentication, authorization, confidentiality, etc. can be used to protect the DMM entities as they are already used to protect against existing networks and existing mobility protocols defined in IETF. =93can be used to protect=94 seems awfully weak. Is there any reason = why you don=92t want to say SHOULD or MUST? Or, if you don=92t want to make this and IETF SHOULD or MUST, you might = want to say something like =93we recommend=94.=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=_01D8C3B3-E0B8-4770-9D1E-571E0EA77A28 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I have = reviewed this document as part of the security directorate's
ongoing = effort to review all IETF documents being processed by the
IESG. =  These comments were written primarily for the benefit of = the
security area directors.  Document editors and WG chairs = should treat
these comments just like any other last call = comments.

This draft gives high-level requirements = for distributed mobility management at the network layer.
 It = also gives definitions of key concepts and motivation for replacing or = augmenting current standards for centralized mobility management (in = which information
about location of a mobile node is kept at a = centralized mobility anchor) with distributed mobility management, in = which
this information is distributed.  This latter = includes a list of the problems that can be addressed with = DMM.

Although the motivation for distributed = mobility management is not the main point of this document, it is very = helpful
in helping the reader understand the requirements and = their importance, so I am glad to see it there.  Since this, = including the
problem statement, is quite important and = useful, I=92d suggest mentioning it in the = abstract.

The requirements are for the most = part well-written and at the appropriate level of detail.  However, = I have
a few suggestions:

1) =  REQ 1 is for distributed processing, but =93distributed processing = is a rather open-ended term.  It would be a good
idea to = include some indication of what is meant by distributed processing = here.

2)  There are a couple of points in = REQ6: Security considerations that need to be = clarified:

2a) Another example is
that a = malicious node can forge a number of signaling messages
thus = redirecting traffic from its legitimate path.
Consequently, the = specific node is under a denial of service
attack, whereas other = nodes do not receive their traffic.

It=92s not = made clear what the specific node is.  It would be better to have = something like

Another example is
that a = malicious node can forge a number of signaling messages
thus = redirecting traffic from its legitimate path.
Consequently, the = specific node or nodes to which the traffic is redirected may be under a = denial of service
attack, whereas other nodes do not receive their = traffic.

2b) Accordingly, security = mechanisms/protocols providing access
control, integrity, = authentication, authorization,
confidentiality, etc. can be used to = protect the DMM entities
as they are already used to protect against = existing networks
and existing mobility protocols defined in = IETF.

=93can be used to protect=94 seems =  awfully weak.  Is there any reason why you don=92t want to = say SHOULD or MUST?
Or, if you don=92t want to make this and = IETF SHOULD or MUST, you might want to say  something like =93we = recommend=94. 
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=_01D8C3B3-E0B8-4770-9D1E-571E0EA77A28-- From nobody Wed Feb 26 16:33:48 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D4A1A07CA; Wed, 26 Feb 2014 16:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.711 X-Spam-Level: X-Spam-Status: No, score=0.711 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bU6TWL-MwokR; Wed, 26 Feb 2014 16:32:24 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1046C1A079E; Wed, 26 Feb 2014 16:32:23 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id y20so1443406ier.15 for ; Wed, 26 Feb 2014 16:32:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:reply-to:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:importance; bh=XjnCobmZgrl9ebEq8uhqUKu+2yotzgNdx0pT2R1xHbE=; b=vAT743sQ1Sg3Jmb421wqvePGAiT/MHdRi3/micia/ZPqj5OwrK5/xO5CZ+2ATi8k3Q aJvDiuvE89O3HVWD8NUvkxbwabG5LEmKZ5tT+AHyrL93B+KFeb051YwogX6BtWhhRCmw OIjOqD9J0lt8sv/bIUJ0mnSmi4DBwBial2NN0aJWut5BANHxmJ6n87kPjE8USNUg8Sbp GNRhaPqUaWP+fXZHLVz61U2b0WOFx9LPglgD5SIrMjuFC1evi4Du4hrV3Ax79Y1Z0Uvx OFa5tVF7VLQUGkEcBHqYz/NzLyFlBkZ/3zhIyBXaZBTcPJKAYzzWhz8nnTqEBcXchifJ flyw== X-Received: by 10.50.4.74 with SMTP id i10mr2655464igi.43.1393461142623; Wed, 26 Feb 2014 16:32:22 -0800 (PST) Received: from C73782TX02 ([50.58.7.243]) by mx.google.com with ESMTPSA id hs6sm53824523igb.2.2014.02.26.16.32.20 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 26 Feb 2014 16:32:21 -0800 (PST) Message-ID: <3FB80D3E15F745BE82C550268ABCA822@china.huawei.com> From: "H Anthony Chan" To: "Catherine Meadows" , , , References: <79966625-7B22-4641-8B4E-3839AE3B67A6@nrl.navy.mil> In-Reply-To: <79966625-7B22-4641-8B4E-3839AE3B67A6@nrl.navy.mil> Date: Wed, 26 Feb 2014 18:32:19 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0037_01CF3321.151811B0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/3Ph9tjLkZ9SfGSbPyxrebEPfNtk X-Mailman-Approved-At: Wed, 26 Feb 2014 16:33:40 -0800 Cc: dmm@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-dmm-requirements-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: H Anthony Chan List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 00:32:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0037_01CF3321.151811B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0038_01CF3321.151811B0" ------=_NextPart_001_0038_01CF3321.151811B0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Catherine, Thanks for the comments and suggestions. I am going through them one by one as follows: The revised abstract is as follows: Abstract: This document defines the requirements for Distributed Mobility Management (DMM) at the network layer. The hierarchical structure in traditional wireless networks has led primarily to centrally deployed mobility anchors. As some wireless networks are evolving away from the hierarchical structure, it can be useful have a distributed model for mobility management in which traffic does not need to traverse centrally deployed mobility anchors far from the optimal route. The motivation and the problems addressed by each requirement are also described. I agree "distributed processing" is open-ended. The following suggested = revision tries to spell out what to enable.=20 REQ1: Distributed mobility management IP mobility, network access and routing solutions provided by DMM MUST enable traffic to avoid traversing single mobility anchor far from the optimal route. Thanks for the suggestion to clarify what the specific node mean.=20 I also agree that "can be used to protect" is not the proper word. The = intention of this requirement is that the dmm solution MUST be designed = properly (in terms of security) such that the use of the security = protocols that are already used to protect the existing network and the = existing mobility protocols is able to provide sufficient protection to = the dmm entities. Please check the following revision: REQ6: Security considerations A DMM solution MUST NOT introduce new security risks, or amplify existing security risks, that cannot be mitigated by existing security mechanisms or protocols. Motivation: Various attacks such as impersonation, denial of service, man-in-the-middle attacks, and so on, may be launched in a DMM deployment. For instance, an illegitimate node may attempt to access a network providing DMM. Another example is that a malicious node can forge a number of signaling messages thus redirecting traffic from its legitimate path. Consequently, the specific node or nodes to which the traffic is redirected may be under a denial of service attack, whereas other nodes do not receive their traffic. Accordingly, security mechanisms/protocols providing access control, integrity, authentication, authorization, confidentiality, etc. should be used to protect the DMM entities as they are already used to protect against existing networks and existing mobility protocols defined in IETF. Yet if a candidate DMM solution is such that even the proper use of these existing security mechanisms/protocols are unable to provide sufficient security protection, that candidate DMM solution is causing uncontrollable security problems. This requirement prevents a DMM solution from introducing uncontrollable problems of potentially insecure mobility management protocols which make deployment infeasible because platforms conforming to the protocols are at risk for data loss and numerous other dangers, including financial harm to the users. H Anthony Chan From: Catherine Meadows=20 Sent: Tuesday, February 25, 2014 3:27 PM To: secdir@ietf.org ; iesg@ietf.org ; = draft-ietf-dmm-requirements.all@tools.ietf.org=20 Cc: Catherine Meadows=20 Subject: Secdir review of draft-ietf-dmm-requirements-14 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.=20 This draft gives high-level requirements for distributed mobility = management at the network layer.=20 It also gives definitions of key concepts and motivation for replacing = or augmenting current standards for centralized mobility management (in = which information=20 about location of a mobile node is kept at a centralized mobility = anchor) with distributed mobility management, in which this information is distributed. This latter includes a list of the = problems that can be addressed with DMM. Although the motivation for distributed mobility management is not the = main point of this document, it is very helpful in helping the reader understand the requirements and their importance, = so I am glad to see it there. Since this, including the problem statement, is quite important and useful, I=92d suggest = mentioning it in the abstract. The requirements are for the most part well-written and at the = appropriate level of detail. However, I have a few suggestions: 1) REQ 1 is for distributed processing, but =93distributed processing = is a rather open-ended term. It would be a good idea to include some indication of what is meant by distributed = processing here. 2) There are a couple of points in REQ6: Security considerations that = need to be clarified: 2a) Another example is that a malicious node can forge a number of signaling messages thus redirecting traffic from its legitimate path. Consequently, the specific node is under a denial of service attack, whereas other nodes do not receive their traffic. It=92s not made clear what the specific node is. It would be better to = have something like Another example is that a malicious node can forge a number of signaling messages thus redirecting traffic from its legitimate path. Consequently, the specific node or nodes to which the traffic is = redirected may be under a denial of service attack, whereas other nodes do not receive their traffic. 2b) Accordingly, security mechanisms/protocols providing access control, integrity, authentication, authorization, confidentiality, etc. can be used to protect the DMM entities as they are already used to protect against existing networks and existing mobility protocols defined in IETF. =93can be used to protect=94 seems awfully weak. Is there any reason = why you don=92t want to say SHOULD or MUST? Or, if you don=92t want to make this and IETF SHOULD or MUST, you might = want to say something like =93we recommend=94.=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=20 ------=_NextPart_001_0038_01CF3321.151811B0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Catherine,
 
Thanks for the comments and = suggestions.
 
I am going through them one by one as=20 follows:
 
The revised abstract is as = follows:
 
Abstract:
   This=20 document defines the requirements for Distributed = Mobility
  =20 Management (DMM) at the network layer.  The hierarchical structure=20 in
   traditional wireless networks has led primarily to = centrally=20 deployed
   mobility anchors.  As some wireless = networks are=20 evolving away from
   the hierarchical structure, it can be = useful=20 have a distributed model
   for mobility management in = which=20 traffic does not need to traverse
   centrally deployed = mobility=20 anchors far from the optimal route.  The
   motivation = and the=20 problems addressed by each requirement are also
  =20 described.
 
I agree "distributed processing" is = open-ended. The=20 following suggested revision tries to spell out what to enable. =
 
   REQ1:  Distributed mobility=20 management

          = IP=20 mobility, network access and routing solutions provided=20 by
          DMM MUST = enable=20 traffic to avoid traversing single=20 mobility
          = anchor far=20 from the optimal route.
Thanks for the suggestion to clarify what the = specific=20 node mean. 
 
I also agree that "can be used to protect" is = not the=20 proper word. The intention of this requirement is that the dmm=20 solution MUST be designed properly (in terms of = security) such=20 that the use of the security protocols that are already used to protect = the=20 existing network and the existing mobility protocols is able=20 to provide sufficient protection to the dmm entities. = Please=20 check the following revision:
 
   REQ6:  Security=20 considerations

        &nb= sp; A=20 DMM solution MUST NOT introduce new security risks,=20 or
          amplify = existing=20 security risks, that cannot be mitigated=20 by
          existing = security=20 mechanisms or=20 protocols.

          = Motivation: Various attacks such as impersonation, denial=20 of
          service,=20 man-in-the-middle attacks, and so on, may be=20 launched
          in a = DMM=20 deployment.  For instance, an illegitimate node=20 may
          attempt to = access=20 a network providing DMM.  Another example=20 is
          that a = malicious=20 node can forge a number of signaling=20 messages
          thus=20 redirecting traffic from its legitimate=20 path.
          = Consequently,=20 the specific node or nodes to which the=20 traffic
          is = redirected=20 may be under a denial of service attack,=20 whereas
          other = nodes do=20 not receive their traffic. =20 Accordingly,
          = security=20 mechanisms/protocols providing access=20 control,
          = integrity,=20 authentication, authorization,=20 confidentiality,
         = ; etc.=20 should be used to protect the DMM entities as they=20 are
          already = used to=20 protect against existing networks and=20 existing
          = mobility=20 protocols defined in IETF.  Yet if a candidate=20 DMM
          solution = is such=20 that even the proper use of these=20 existing
          = security=20 mechanisms/protocols are unable to provide=20 sufficient
          = security=20 protection, that candidate DMM solution is=20 causing
          = uncontrollable=20 security problems.

   This requirement prevents a DMM = solution=20 from introducing
   uncontrollable problems of potentially = insecure=20 mobility management
   protocols which make deployment = infeasible=20 because platforms
   conforming to the protocols are at = risk for=20 data loss and numerous
   other dangers, including = financial harm=20 to the users.
H Anthony Chan

From: Catherine Meadows =
Sent: Tuesday, February 25, 2014 3:27 PM
To: secdir@ietf.org ; iesg@ietf.org ; draft-ietf= -dmm-requirements.all@tools.ietf.org=20
Subject: Secdir review of=20 draft-ietf-dmm-requirements-14

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

This draft gives high-level requirements for distributed mobility=20 management at the network layer.=20
 It also gives definitions of key concepts and motivation for=20 replacing or augmenting current standards for centralized mobility = management=20 (in which information=20
about location of a mobile node is kept at a centralized mobility = anchor)=20 with distributed mobility management, in which
this information is distributed.  This latter includes a list = of the=20 problems that can be addressed with DMM.

Although the motivation for distributed mobility management is not = the main=20 point of this document, it is very helpful
in helping the reader understand the requirements and their = importance, so=20 I am glad to see it there.  Since this, including the
problem statement, is quite important and useful, I=92d suggest = mentioning it=20 in the abstract.

The requirements are for the most part well-written and at the = appropriate=20 level of detail.  However, I have
a few suggestions:

1)  REQ 1 is for distributed processing, but =93distributed = processing=20 is a rather open-ended term.  It would be a good
idea to include some indication of what is meant by distributed = processing=20 here.

2)  There are a couple of points in REQ6: Security = considerations that=20 need to be clarified:

2a) Another example is
that a malicious node can forge a number = of=20 signaling messages
thus redirecting traffic from its legitimate=20 path.
Consequently, the specific node is under a denial of = service
attack,=20 whereas other nodes do not receive their traffic.

It=92s not made clear what the specific node is.  It would be = better to=20 have something like

Another example is
that a malicious node can forge a number of = signaling=20 messages
thus redirecting traffic from its legitimate = path.
Consequently,=20 the specific node or nodes to which the traffic is redirected may be = under a=20 denial of service
attack, whereas other nodes do not receive their=20 traffic.

2b) Accordingly, security mechanisms/protocols providing=20 access
control, integrity, authentication, = authorization,
confidentiality,=20 etc. can be used to protect the DMM entities
as they are already used = to=20 protect against existing networks
and existing mobility protocols = defined in=20 IETF.

=93can be used to protect=94 seems  awfully weak.  Is = there any=20 reason why you don=92t want to say SHOULD or MUST?
Or, if you don=92t want to make this and IETF SHOULD or MUST, you = might want=20 to say  something like =93we recommend=94. 
Catherine=20 Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: 202-767-3490
fax:=20 202-404-7942
email: catherine.meadows@nrl.navy= .mil=20

------=_NextPart_001_0038_01CF3321.151811B0-- ------=_NextPart_000_0037_01CF3321.151811B0 Content-Type: application/pdf; name="draft-ietf-dmm-requirements-15revision.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-dmm-requirements-15revision.pdf" JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nK1WXXPaOBR951fcycsmMwnEZLtp+kaANGz5SBNndjpNH2TrGmsjS0SSIfz7 vZINMU07ZbaBActwde65535YT3DajuDUv+trWrQ6t+cwt61T+EifeeupFQUDqC9pAZcxGb2HqAtx 1qr2RdA9g/N39EvROpyiW2nzCP/Ql1Bz+Gh0uYC9Xtdt6OdMwcPhkLcfjo7if1vRGcTj1uFIOTQK 3cnAsMzthwbXJVuhgBjTXGmp5wLt0R8VluLIwTrmSvsBRirTpmBOaMXkPsCDNoxF6bGGzwthkDB6 5by0Ds6iY+ieRn/ug9LPhWIw0YmQ6LH2jOqnr5s23KFwb4IFMDNMzd8Ci5L6RT9qx96C16fBYARj lvw21t9t+KRNrhWq/4V1aTTjqS6gr4uiVCIN5WN/g9cVJqZkZg3d86qGCOvsIlR/0+wWn0oquQKV s0B1CwNhnRFJ6aiiQzEJt4YJU2wejAil7qEfeuW+n04EuuyEF8WJaaCfRO9oc/evsLmXkBeWujrA OBcWuE5LbwkcM6HQgssRzD78dki9cKXGH0wmD0fAXMBS9SiRbI2m7b0i5AINM2lOikvqYFOmrjQI YpNGYslF3corIiLR2g2QhZxZkERkYUTBjJBrcBpScm2YpBuOC6nXyGusYiMnU2mujSUKPQtWF/gD aEYscKnl0g89tmJryIwuNqx+yvwYhIOUhl6CUFrMSkkklwgMeEO4QnOUNZYXdcuseBFPKFgReO4l yDKRUn4oJ0o74kgQFCj9sURjN139Ou5XEUPGTIgjRKAXjmSTQBPdYZWPrVJOLEML0E4ejBdGJxIL EoZzGpGW0JM1ICOCjRoJsjFpdQ3E0aYUNPL2S+3tlPyYxlLJtpPJl8QjroFywC0cTO7v4oPj6grT WVjfDj/fj26HA7++u+6Nx9tFZbFTjPTH7H5c2/rVC0p/NpkMp4MKaNL7Qhcf68HsJh7Npr3xgc+A o8bYhLJpDx8iqZ/4KqXH2MKgTylV4jZYv/P2qg/dKLrYLmqYr3Tvb781FLkLTy7QWfAHEyx0szG/ e1rSL7ZMCuFc5YlqTEKqq6eeSn0xu9znbEcJyt9SWD/UvJ/L/g2cvw8Bh+VFgw0Z73qsmmFVHwA2 OtR8cWsMQzWnuYGGrHZcx8w+wpU2RO3hcDSMrx6OqNqm2pGOOc0GTSgG5v5gYakD1qGAGv1Sa/Ga APteG1tPFUl7Pb20NManbGtVQ9VhkZLkPndu8aHT4YyyQDPxkWaTH6BtbeadME9tp8bp/FqlsKFB ccmk4KHHGYX2LIqy8MSseKYmUy63O0r5fHgB/PBYECHkx9RdC8lSvyIQnVgtQ71R81W6NeSg2lTr zYgShe/pUagXOpksqABoTDIXipdG02v6lnxlSIGmXnJ//iNWzRPcMVCWmWzXD5v6tPSrw9LXG+pv iL4R5jBufab3f3mU6tplbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKMTA4NgplbmRvYmoKMTIgMCBv YmoKPDwvTGVuZ3RoIDEzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicbVNNc9ow EL37V7zJJTCTGAxMk/aWAOlkJunQxLfSg7DXtlJbciQZyr/PypiGj+LBH9Lu2/fert4xDCMM/dU9 kyoYvNwgt8EQ3/mfB+9B1AageyQV7mMOukU0QpwFu7wIozFubm4RV0HvUTkyitz1zIjM4ew3e36+ fqF3e76DB1qZRpgtRsNo0o/fgvFXxE9Bj7cqwahSlNAGTiORjuAKqqD5zkuFUBAWFxtt/kAq1Ebn hqwNL/qXwejLHiYupMUJw40sS9DfWhqCVrhr8sY6jKOrlkbI+b2prrdG5oXDD+1kQn6N0T6Xl71k 2W/j8TiPHxAbjyFU6kmiJmO1spApKSczSannyjuME4333FKdNBUHQDSu0MaGwB0zawtYsBgya0rD cz3/EvndNqs3Spz36H66APdkT+KT16XFE+WiPKq+MHotrfQ0X6gUTqrcg7RZs66A7XQve4Vz9bfB wHk4olCSy0Jt8kHJ5ihL11Jlmg3hRlCWeT5srCeRchuhsw6nblacwLV4V2cccCCG1S9KEpZY+VrS xqfzR3pCJRGGsqYst1edpVukZBMjV4StbszePu8CW+iMTFwrciNd4VdqZtdhsdxTClOdEt+qWitf lMfEGZE4bmBmdHUcjorN6KCkSsqGU19lVZe7jt+/zvC0sweOcTzfPdXUO/VKLTVMwgOLvGm7YWpb dtgmL4nV+1Ff82SlrSTd8EALY4RyW67QoRzV8ZD/5+VnazIZtSMx9Sdq2Zun4bJ/BWK6Zdgd03l7 VuzpSTk9zb8WIieMfjPoPA5+8vUBMI1bxmVuZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKNjAzCmVu ZG9iagoxNyAwIG9iago8PC9MZW5ndGggMTggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJl YW0KeJydlF1vmzAUhu/9K85dE6llMZCQXGZNNk1aq35wt+7CAUM8YXvxR7Ts1+/g0K5ZK7qChWzZ Ps95j3nxDiYRhUnbur6Q5MNdBrUlE/iMb012hIYN0HWFhI85bpoDjSGvyDGOQpxAls0hl2T0RTlu FHcXK8MqBy+e1dXVxR3f2Zcr8IlvjGfmAPGEpuP8B0kWkH8lo5xtGg66gkuNcOXs+IzEs7CEUTQC wKRGl75wQiuI3t0gRSJNHokxzmCqPaZCngVveQlCgdsKC6UuvMQV6CdOkTgKVcVRqzDnRgqlG10f +iN7WEmrC1Mb1ojfKGnPjfWoSFhnxMY7nJJ6IxrhDiCZYjUPQk9YsyddSdD1nPdacJ+u7BmrPbPV G0L6WPOOleL4xmj84BLuHXNvRr7CWnSsKY7Ral6YQLEDnEFpx5oh654X3rQ1oTmsKLlhR3/8Lyvt WFnr2OX1ciDnhDU/evV47toMqvGRtQjnVXHDVcGHkJD11xOL4K9rbSSWt+fvJ5+w4vCXV0NpT6yl d1s8pjNYlqXh1g6ok7b+SqfTcF1cbpmCh9G6jB7G58AdsCbqrrP1r5/oPIspa28dJPQ8XGz/3nrf bvD/gOQ7Qtc5ucX2B4p7PHNlbmRzdHJlYW0KZW5kb2JqCjE4IDAgb2JqCjQ3MAplbmRvYmoKMjIg MCBvYmoKPDwvTGVuZ3RoIDIzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnichVbR bts4EHz3Vyz6cg7g+Ow4bZrHNGmLAGnrawwUhzoPtERZbChSISm7uq+/WYpy5OSAcxBEscjh7Ozs Lp9oNp3TjH/S36wa/fn9grZ+NKPP+N2OnkbzuIDSn6yiDyssek/zM1oVo27fnM4WdHHxnlbVaHxr gnRGhtMbJ4pArz43X76cfpdP/vUb+iQ3rhGupbPZ/Pxk9Wu0uKTV3Wg8nxIB1tm8yYKy5uSP0dm7 +Ib4BYVSUi18oFxmIpckqBDKkWmqjXRkCwKdvXWPp1q0+KKyG6VVaKl2NtjMag/A+aIHLMVO0kZK Qz4IkwuXq39kTj+/f7p+d3bx9iE+vb08P09Pi/ez7undYjZ/ABSDxDdn88UDqF/pUNpmW3Y8+zMp V0UBNgr8pas88ywaEwP0hIMTkvDeZkoEUKik92IrqbCuEsFPGLAloTXJqtYWj8+xCZOV1lGwPYzW dt8vkGQsdAqWnKwEGDgpslJs8AI5Y1IBMngs3uFYLBMJpeMsTeglRXgrRJVOq60yYUKismZLFuxA QPhHMJXGN076BJNZYyQi3THTTcsB7Vln7KpF9igD1JE+KBNPnxCgPR9aOFvFqBPOIBi2SCAF5SjD Uod4W4CwLKzcC1lUZxqA+h4rlCLELw+bhMtKFcCTmYNHLtrOHIJ8xao/Gwz7DkDdETGFEQ9cikJl vKxSWsf08vMzd898hCFbSyeCdQkoSQweAGlrlcWYKmHggZxliyGIqpd/elQXN8oHpzZNGIbfba5Y y/UYlbg+iZLhdM1VK5CSaAtGFhtk/6gykrCxHDqVGClZYIPEbZ1tEPVGlioFr7gbIJWsH+qpydsU HA6PgdVOVcIpBJZyUlh2KqxwHM56PAdZ+tKp1njJCjs5QWwsT4kY5E66CXvLNxVbqe9E/FUA0aNY 4keZTDfRdjH7yIq2UJmuuw10IzUEQUP62qXCg8b1zVcPJvtSZWWKJX5KkSOZsJB4ROs4KA6iO5VF IVBGWQaBAgSC49my980xSO8VVdXWwxdG7lGbT41yMWkwjumNk3HcpudVHFwTP7kI4gCWpyg4URaC QydwkL8zKVPsSPZOKB0bAOMOoXoXZgKliYgmh5DQynYq50QY2bUJ0Nadu0B8CAIrooNtFULyCBlN DSg6tgBJt8vd+aBKCm0h5Xosp9vpZAgSe+zl7PJhAsMpl9NnabhgUFG0FC7gH1+qmpbO/gI0IBaf l0vOFfgPgVDU6Ld3MdW3S7rKMjRWLL+7XV5hORfufWSHqPB+lah966gNkdbj+9vl6hs2/VzdT88W 03OMAPwXShc7/rCsRHfMIWVJiCHcD+RZ86KO2xXacm89HPXj7uorn7QU6BOnw31dVUxvkPVpYonE PsSxSSLPFWuEvkxbZGEv2l78OEoPKJXEDDDKV9HDPvqCC40T/VtV7OYjF+9VKFPRflxeD5E+7qzm ybGMzRzlBKuux1jUC3W5mMXR+LcMXe98PtzTXr5wIKqqbpxvgKgG0z52CbYddrotP3PmNtxj8fyq QFMdkbe66YbsRrY29alXdwKQQxfw2AM76/bIiBjJamvigQdF02CJc5XHFF7tlFdsob6C1JHazorY pTy6KhqgjQMXsioNplk8tLuF5NbIGBm3S815iMU2xNpZrsdUl9wkdHvcPePnAybyyzrrVUNXG6YA Cdbcx40sVDd2XzfPblbupLZ1LPnnmXY8ONkmVEhklTQv5+l3LATSARqlQjFjZ3RZvOvFfKdpFDta LQCVBl+fsSMHP48333pUeZxNmHABdxYWjW8ZqDx7yrMU8G8KLQ53Gf9miNUV6Qazi5srbj6Oe0pm q6oxGMXpmhZvOrXkJtjfKTCQhzhbabdO1CWPb06hmP7/bObrADg3+ii6yPU/JAZVzlZ/4xtcOTJt uX47CYdQ8aLGGRMh4ObX56+veDYPX+eR7WuerKjdfLo+wTUuoKVN+yr/XStO8FWzbaDSYj6JF3d6 8UG/wp31nG/GH1ejv/DzL0SJ+N5lbmRzdHJlYW0KZW5kb2JqCjIzIDAgb2JqCjE1MDcKZW5kb2Jq CjI3IDAgb2JqCjw8L0xlbmd0aCAyOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4 nIVWwXLbNhC96ytwiz1jqpYU22l7SuOk9UzccR31FOsAESsJDQjQAChZ+fq+BUiJlNuJNB7JIrB4 +/btWzyLy/FEXPK7/Syr0U+PN2IdRpfid/ytR8+jSVog2o+yEr/NseidmEzFfDXK+yZiOhM3N+/E vBqd3dlI3lIsbr1cRfHqdXt/XzzSc3j9RHyipW+k34vp5eTt+fyf0exnMf88OsOjp7Pp07kQc6fk /k0QlVtqQwLH7Jz/FkTtKZCNIpDf6pLwv9tqRT6InY4brNudvxlNZl209Co30hiyawpjIe45oI57 UcvI+IPQVulSRhJxI+PhQKcoCLeKZBHwEMpTJbUV2CrLDSkRHXaRCLICFKcBzK3apxXDXDkvSmcD Q5RLQ/1YNXntFB8iosb+rw8SPxWfHcBoux7/jRwXQPylplKvdCnuHjI6oO/HqaSVa0rHhaaunY9C ByQQgfa50R4wGYasa8N5asDJqRrZ2HLTDyWtAtyqNpToIO1BdAhpy27DvHC2PYr4JORnqYyk+pF+ QAzS+sPtaEv+QpSN9/jJ7C+Q4SCxrlS9tFAVvbZdSmYn96FwVjgwl1K7GDKDg/EHNrHWoOQeeCKr hUkHPmCP9JLrRMDW5tYPEpplKL1eks9nBmEcx2MSaS+kpyMDXdqtXMf9OPMNcyUtqhIag2QgI7GT AUwDDH50jS+hOa5Bw/FAPLdI6UIM/UCMInF70gLg9M6uuOYshVSdA4Ola1BUlZpkUPCjKAAokjF6 TRZBQ7NGv8ReT/QLgXBGieVQzhmGAi4DMvSWDG8Ap5J7THy9K27Hyw3Sk14XalMWpZEhFEsZSBXD SLTSL4vERNr1zfmNs2SLa2i9yI/xwUWPmsLiAjCbAA5VU6LWAx2CKFm5JguwK3cnDKAFspOKTa87 94CDYeleKB0iFNDEnv6ZDon2cT50MZSMsqiNtFjmdtKjt+XAjSoHsawMGG2Py/wkjv8zMIurdkFz fQ79VRqH0ndSa/D9VwHiIXB00DEE6hjDoVL4Ygw7y1AEHGGlfYjFxtXCO6TIOvokS46SVi/3ObmO A5YKqDxxohbxhdAxUbZMwINesme4gSaAWEDCbFD89SQQyhodwB60pqgmODRaDgfvNgQwPvPWdzsi ll4O27XdXUz9dtQGncghcIaoHjqqyj2Q5d5A+AdxD7WyhXhdE17x3PrJcFyNOwxHttH0W6dVLl2v y9FrmA865LHB/BLGltWhCswfELKgujgYuDwQVt5VYF44k5xH8vg7FdFQ0cmElCubdAxbPSQWegJX x/29udIq5qjkEr96afT3/9kApr5wwUHpbMzHJpuCGKp29hxJgVKkUkARWmmmtmPlh6aqQPf3zHwX 720br2Inic53wmmHXZXKAcvZwcxal8Z44K3SDBexkbaVKozck28j/YgNxraGlm0f1hW3jbapC9s4 gTDasvu2N4A8fHk/ziiblHIvxvVpsQ6sZanm063qGh8sYjxnj9y7bw72o6qqCKgOy3TRsnwsG7he Qfzp0Pa6cXtMdtzdjcaPtNW0WzCc9mY2RXofnEXSOYcmdN7ZE9QR/XQ84TKRr7R1xq27Ir1HTRg8 mgZ0mAO9hSeT3Ab+U4UuR1w/ZOmd3VeHAwfpDA5PtKILlpQmmceY4ICS7wyrvtXf5x69e9hedxIE jSK016xsBF8fP324nt5cYba02x68e9l3Dc6bhzvaULzvajqZYZ/MPB8unI9tij1W0vLZzdVskUUd OtPJNGhbmkZl11qxf+9gg78M7l9PZ/d/Pp3jEuVwiQq1s6ob/oh0NU1MfYCRYOFHNeaVBKbMuB2P H19qzQbwvlmz6c0mF+lKLk5e0MqaxNUCMT/OR3/h/S9A3AYiZW5kc3RyZWFtCmVuZG9iagoyOCAw IG9iagoxNDA1CmVuZG9iagozMiAwIG9iago8PC9MZW5ndGggMzMgMCBSL0ZpbHRlciAvRmxhdGVE ZWNvZGU+PgpzdHJlYW0KeJyNVl1z6jYQfedX7FuTGaABmnA7faL5uM3MpZNmeLvJg7BlrMaWHEmG 6/76nhUy2IROaobx12r37NmzK7/T1XhCV/yL56Qc/Pw8p40bXNFX/DeD98EkGFA8JSX9voLRF5pM aZUN9usmNJ3RfP6FVuXg4lF7abX0ozsrMk8fjrvlcvQs393HN/Qg17YWtqHp1eSXy9Xfg9mvtPo2 uMCrl4vbP18uhyR0SrkpJYmN1B6P/1i8XJJwVElL358fbm+m8+vX36gwiSioNGtVKN9gWZIbe/nT YDI7evy2DGvhMdjBZ5JI52gjvNyJBhbLxde+9+vpZPa6R5EYJPrDwyd769jM5tez1zGeT2/aWI+a RJoqr4weks+VozSQo7S3Jq0RFU8lZaYozE7pDYHC0o2j71tkakVRNJTKqjCNTE8Tc9ESh5UZcHgT HB7MSqFBWMmU7X3wpUN82uUqydnYIn8rexTh2EqUI5O7DxEDBxwD0LJMJWQyKlVRIEUXrgOlR1za pDIEFJoMqBLeWIJMdsa+ceAIMaV1E9w6wUUOsfpcRjbUP10ajvkdI5biDRFrJxlO8jmHLd13ynmr 1rX/LADKqI1vXQdAjnkX/kBKauTeSEu85apYAUrdB57/Bz7KhKXMmjLwYyqvSkjcGgDtM/RQAEGU dGT4CDqHUrmehdzKIlSKPbDmcoWq2CRvjrJM+XIvpVR4QZXw+SnyWK9zUnON87Lsg1u2dv3+2dPJ jhI0gUy4VRic0pmxpQi3Vr7Xyu55rKzZqvQY9hRVF0VdVcZ6dJclQRu1lfrADkTJ8OKcmY378uJK 1ejVTwVxJr0OANYJys/alolgQXKej088EywPHOQpupB6yZSYREku9EbykOGVbALzrXTj8wGzWgcC XVi8brtQlVURDIAECklVhlHB9oVokCnDYPeg1htUgZwXyRtCLHwEHP28XERVYTaGpcOz1U/Q6WvU s1C4G62FQ9hjz4+is/C8L5GFRqxR8HzW8QEgK6apVBL6JgbQjLVHYGWVThRS5wS5lhB7rVzOml8D jIQeBDkUgkUGUWmvMvRCmHAiwmybpC1Z2DUEugP/8Bx3VdV1GWbjzozD9F92p+Hj03BfR7RhXwWH RopFxh7Bw7ytOfcu1x1t2U58fneCbYiZjrpGsRirNkpjUHQirSV6QUaigsY6MYOwQIflU3TykRyk tcIL3mZZaa2fY5F4e4U+uv2Lcr3JyvPEEM6ZRIkAu5NCu5lGnDvl8/+O/wR1Smxi0TrO15DT9TQU /xZtAyD36Zg/HaQnUYzjp8b9jwqjxNGi3tTO02wyDB8dp18k35+QD928wuf9avAXfv8C2CTv42Vu ZHN0cmVhbQplbmRvYmoKMzMgMCBvYmoKMTAwOQplbmRvYmoKMzcgMCBvYmoKPDwvTGVuZ3RoIDM4 IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnichVVNc+I4EL37V/RtoQqYADth9sgS wqZqSLFA1R6GHITdgDay5EgywfPrt/VhYs9QsyEpHHf309Pr19Ib3A2GcOc+8TvNk0/rCRxNcgcL +jsmb8nQJ0D8SnP4c0tJX2A4gu0hCXVDGI1hMvkC2zzpPEmLWqLtP2h2sPDTz8Ny2V/jm/k5Ao+4 1yXTFYzuhr93t/8m4z9g+zXpUMigMVxJ4BlKyw8cNbxzIeDAtbGgVWkRrAJ7QlCaH7lkAojEu9Kv 8H7i6Qk09ru/JcNxjZhxjak1riSH0nB59NUOyj2zLNO0pgPNUPAzLRjxI5UBoTmcNfYDlKsqWPqK HpQbeGcVpEzSyqYUFrgEoSjHkzUDgKkEvHDjCiOWKizP+Xdm3VZDXuQpql9wVAf/+qSM7UUkJjMw JW2beDAf6e+ZQXqpRGkj/dF9LcaWyiVeLJBiVLc3bj9KGiJYCEbMU5JdM8G/E4TDzoi35ntimEGu 9lxwW7XkzZlkR8ypDA6ljGgEZP1KvjENCuPBkASZNRapQRtAcWtPbTY3Ent+FaHSICSXB6Xz+hnI nrlpcSX9GJUXhRN1T+QQZbPVTde5zd/oQeRGar9iYYHRL7h+CfwgyGR6UrrnIWqjZOj6T9sI5oow t9bVYU1KPXMWDBYAB14SRdU0E0pnpuc7H6FuyAOmMhZz4zGbUpI4e8Lx+0sVvVcCqP0SG6ZysYxZ FgKw6/gFqKcqQ3haAYEdDjzdddsGWzJZXd1+k1SGhVCVezT0+hXJ7+g60yDYNlhbVgdL/MnrpBbT Kc184wjwLyyZutRIDTBgTupd1k2T8MiPFAFnwvmF5YXAoE4YqxyBWBLHXeev6a7rdXDuEk3rB4Ec FUr7unR5BvXZe8SfMjFqgNzo/28qt+ssnwNyhFqG4DRN3YQvmEV3nFDadEF5RDkmPK3O9/Bt/Ti7 H00+v3hqFFxpdanaSNfEz6Ph+MUdSoUb8jOKyo+eEKVgulbMhNMjMI9A48VqBQuUpK+AlTcwrFnG FWy8oYjdYrXeEL0riKPjy+ZnJc5Yby4WX8vmq1YV5s4K/zflEcsqFSbASRooEokaLBwFtXw+simL QmkLz0H3xWJDytfn5ia27Fbmxmf6PYVtP0d3zcKsCHStXz/Pdt2IRkNEhrfucvowZuXPm+CFH5iT Di3ibbke3NjVa344YtVf/BNpXdlfgxsfvEFHhgPjJik3uZMwaLMTXWDUoGxAGgGRYGIQb+v5paCr ycC0PJZ0B4+HPX9v/3ipf1tRv2DyQqDzbfI3ff4Ds0q3kGVuZHN0cmVhbQplbmRvYmoKMzggMCBv YmoKOTY5CmVuZG9iago0MiAwIG9iago8PC9MZW5ndGggNDMgMCBSL0ZpbHRlciAvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJytVk1z2jAQvftX7K0wYMxH26RHGghlpmYoYSaHkIMwAlRsyZHkEjr8+K6N HX8mkE7EYMna1dun9VvZT9BudaAd/uLe8QxrdgUbZbRhhP+N8WR0IgeIO8eD73N0uoZOF+Zr47Su A90eXF1dw9wzamOuqeRUmwNJ1hpKbWDb5ow+qbIFbulSBkQeoNvufK7Pfxu9bzD/adQSe280ncJo OrsrLowMw2lp3h5PrSle6p+MTi8HBQ0zao3iknPzCJWCHGE0uptgV2hHmJqj+4r5H33rp90/5kA+ hAk2a7Eoup43FEAsgGrntw15FCu8VHmfM+RgrFNXdj9vyOJYyaDof4khA2SlDvkFlxlSJCvrk11x qeEElVdHeve++RPWEe4yMk7vcJSRcXp3tCeW3R8l8/Hdx/OCknYzirVKSXqxFXSWUVcjDVroQutx NrkJt1fuzq7tfk2Ol1u2CSSFTgvghnIticv+0hV4Yslcpg/gEU421ENTK0TttbroOWBKS7YMdLVn vC+7bIF1wB3NBFc4eQDiKgFLCqsMnhbgBa5mvktz5yCe0XshdwqIArUVew6MJ+y7TUAgvSUayIkQ BS5WNHQh/ABijUaqaEzsBSrkgOEVlX8w8hIJoY1IHCQ8Yc/0FojvS+FLRnQCkezakiLQjG+ye1zU ZvaiDg7xyckpzFzh3ZBtVeoqjypeCpmGT35mw6kKXh8Vz+B3M6hc/Up7NVpla7w/xBHsyf9GKRXA BbJuvaHrWEk+kZoR10XJSdRQOMhoO/cIH8bmoHUQO6GJufI8UzmUE8nEIxIZ81CvsBbSoxKFpCgI jljh5IpoAr5LOKpbxYwyMZrAPN9lDtPoT5QKvFCdiiIzEgkaayGCIHwFjsCKF26MEoFG9bWiykE8 TAMWUER0T3ZsR/bExNqhz9r0Peabjm8GvpliPyYZui3uvCqdJ6IYMKrbpcA6S/aXJRQRDQ0x2WRW 5o4NTNr9Niz7JFBSp2k4h/DCWYO5QhYKjwqNde9QpcKvOcw6IBkqEeJLN3pcN1tcu6gNV61FvQkU Txm3FStq+OwziZvoB5tAaeh1mtHnYFF4D1OkAdePiDmcG7/w9w8ReHEmZW5kc3RyZWFtCmVuZG9i ago0MyAwIG9iago4MjgKZW5kb2JqCjQ3IDAgb2JqCjw8L0xlbmd0aCA0OCAwIFIvRmlsdGVyIC9G bGF0ZURlY29kZT4+CnN0cmVhbQp4nI1WTXPbNhC961fsrfaMpFp2Eie5uZKTeiZyXVu32AeIXImo SYAGQMnKr+9bEPqgo2ZKjYYSATw8vH27yxc6G47oTD7pnlW93+8vael7Z/QV32XvpTeKEyjdsor+ mGHSRxqd02zRa9eN6PyCLi8/0qzqndyYwM5wGEycWgT66ZpMp4N7fvE/j9AXnrtGuQ2dn43enc7+ 6V18otm33gmGFo3JgrbGk2+ygpTc5z5zupanVCmjllyxCf3uQK6CmivPfVImP/2tN7rYIoLi2rpn UlnG3pNqQoHlOlNxXbA0Z/K60qVy5YZy7YPT8yZwPgTM+YctzNXhEFV2rksdNgeEyGcFftDCOlK0 KFVoZ/GOgV10iCVCxubsSXuqna2tB7g29P1O1ewGkwM2k41Rlc6G07T1k/ATnJvgcQbDC40fdsWO MtBxqtQ//oNpoVaMJWzIF3ZtEk4onG2WhYjRlKoNwhEe4z34z1ym1rFQ6AON6fHE8eNp41mCQvwa 2HgR3S7wB5DaLOXUwWa29HJsLEpA0EQv48y5DQVsUXaDc/Rcie2Wi146JXsM/7QVD6+WmOKfjh1p e4zhw9X1U+RaKxe0wp5bOv9v56Ogd9Obu6eE86t5Mu0gNI5r60Jrh70umMk4VeN4SDQr2DH8BtfP 4z3JJroaXh9jmmD2qie7NgLZOaZyWYHNMhnokw5iUceZrQCTYzzYhLXQzgfKYBedw3zrgkHX7SN8 TK/9/pkyIJ+gokXyNvVSTXiHc945Oy+5ooegwvYU+8yECoInMzyUQt61mKTy3CHDwHWt4SEUJBwK yd5UlXIxOXbS7rNyYcvSrsH7c2eTu4fRZ6JbawYWBadSJSFZAvtEvL3u8UhOvNIKmh5moTJZAaHt IsTI+qYM0fBmD9hh0V7tFjGXHM83WJA5Vl62kPSCVINgB7gh7qXaDDtadJghdlBfL9gjtP0YdH5V VV0itAiYScVIkBWsoxx28+ykmFjXQWqfeslMRWOLJoBwTrjUeLqh21TqHk/Gk9vH0z5Wt/hwDusV 8Dtgpc0kyUitFOovWNPNHaH6SHmGp7DY43TCqvO8VtkzBz/sYD2eXG8dF3WjqKv+0dZ5CGCN7ESF 9WEgrSInb8tGRiHcX6YDJvLaaOMC5aDfEo2RdCnG0VKS2qsP9P3+y/jD5dn7pw7G1n67naWoiG5h HyQRB5aMNU4eT29j+dnne3tl1gGqtsgNqC0dQxSGwNHQKgSF3iMpGUG8QhuaXn2NvbDN3A6asYFU XZcQUySP8ZF141vKLfs4PudYiUr9LMUbvIaPp28S4hwJMZGwo7Bm6HvOVkkzXiVhpccHhxC2Zm/N ccToh7Vm3/l31Sj1jCy5LU9u6zbo9pp2Wq5v6ykIomiK0WJlFXqrmER2rRy4te36CK8EA3+Mf91S JYs0WGv/JqX3WNEw6cVg907SqbE78X1TS+1HUN5Ebifs8E0sLhCLb8gKkcnDqioxFNUOmIfGGC4P C/Hbt6X22p0wSv6KNxmlRXuUMT4i+gOHmBNNnXbwu5eJXRnclkCxZETDty0H788j2hiZJkmcD6Vu MKiVw4R//VprMcZVs2yQ/hejfnxzpDcXmuuS6ZNk4fWs9zc+/wIfv4OXZW5kc3RyZWFtCmVuZG9i ago0OCAwIG9iagoxMjE5CmVuZG9iago1MiAwIG9iago8PC9MZW5ndGggNTMgMCBSL0ZpbHRlciAv RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJx9VttOI0cQffdX1FtAMg42LJDkaRfYFVKICDiKomUf2tNl u7M900NfbJyvz6mesZkxTkCWwa6uy7lUzwudjsZ0Kr/te1EOfny8pEUYnNIXvBaDl8E4B1D7VpT0 aYqgKxpPaDofNOfGNDmjy8srmpaDo7sqsq84ntx4NY/07ufm/v7kkV/C+2/oM898Un5Dk9Px+fH0 78HZTzT9dXC0CyjdzFgTN1Q4VHmNNHeeWBVLuv+NUkjK2g15fknGc0C0Z4ksuIpeRdbHPwzGZ/2M iHPJF4g2FSlqQq35hzVpDmZRDSkuU0CcToWpFhQKZVXTxQj53jLdmBC9maUoUXHJFFNVsaVSGfRa KbRB81QV0ThUqnSO2Q7Uy7Qd7vDJ0iG/NvM5ezRLQHrt/HfC3yYaDr1MaxOXVHtXsycZBpPhMD6I rnC2nZAKhbQrZzQwKDyr0E6w39QOxw5quQLOd05WqZyhnpuDlCAYTS62mD88nf9M9IQoy1Q7jCdh c2VsAlUCiopRFd97la87nACLpfNSpekdJKsNzbjhepVsxV7NkDw6CrnMAc5z4dCpHDqlAyYXPABx yyfKhk2IXI6IpnuomLJWRR5CUUgFEAnzZNtUJHS1ZxugOvLqpdnpulSVWnApxAorGGyuPC0ALUxF CniztfuYfgCmf0BrUl3cs8sWUl07HwWMwhqWoTFcJO2ociIdjGZir5O7h/fHTdh5C9JZGY1jSIkP MsNEfzGCJO4A2FJI2bXahK0x9TDDLV/witFvrbwqOTaa+V9HoJM2VwqsUfmz+P9VlbXlIQVXQkR1 bU2hxCug2PfSVA6q6U0PemLWC+ZWWkMK+D5lgSmCDrRDhxi2z5b4Ei8KCBdPSnumSrISoG50EU3J YZgdLr70vbZ6ubYpfEK766UR6eIU1pl26FUaLdDHovl4a5leiiy2pWgG1T/BFlpqZzDa7PiXR4vR kJ7uHk5mKoiit9/0cYbmZGr7tpmQPpfuDEBWbUSNIHHJspwaRPtQC7oHxPRLIxRJWVHqiBaCasWF Y4fNsdWjLH2YbbkbYt8QFzDE/e7Ubu8Jl0tWul2LzP4kuhN5B4NlmapDBP2pQt7onZUnrZfv0z8f NSB313amat8Sb5fDkL4z19C0WfFbJrAVi9HzseAkAogJ96lGrrmM3uvuv4fYx+QSmNxwbd0mb5cM QZlsNHWX7OBsytbpVcHWEwnLy2IV6bynNrRS3ihZKqIE2JOr0LgOm1/81GyrAwC8Lycqc8DFN9qS pdJpFgkrXh9eDZ2N+Zat3Z1wjrVcLTKm0qTmWVrIv70UcpmaAlgMG27RhzxhnPArroAGqU6jLQI6 t7e3x00+THPDVu8TcCUEpMZE3EBfQFuEC0HKv9vCu4DdRSTWy/tI+WJpIhcx310p37odrx1A/K3/ rUq/Pn6+vphMzr9BZ3KHWjGGXBSuQokF79TbwWnbve50F9IsFN7UTfbo1srrbG9shXWFzlmVvSzt Y1F+Xtns2rn/+EXQe4BwVhfPx+D/2skjRWS7aWjps36wft4MptIGawT3VQMIt2sfZiocJsiUfZhk fK7lqn8+utVwm7gO7I7aCrevdX6I/JgWCWXOxsP8VEr9n68PEB8ejr8h5+108Dt+/wWfu4+gZW5k c3RyZWFtCmVuZG9iago1MyAwIG9iagoxMjMwCmVuZG9iago1NyAwIG9iago8PC9MZW5ndGggNTgg MCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyNVk1z4kYQvfMr+ha7ChMDu+uNfdpd O4mr4i3WJqeQw0hqiUmkGXlmBCa/Pq9H4kNAtgIF2PPx5nX3ez16pevRmK7l3f2m1eDH5xsq/OCa fsGnGLwOxnEBdT9pRZ/nWPSRxhOa54N235gmU7q5+UjzanDxaAI7w+Hq3qk80Mnr/unp6plf/ekM /cyJa5Tb0OR6/O5y/tdg+hPNfxtc7BasdVhSZRNd6rCh0BjDpafFBY+K0ZBmT4+z1YdueHE5pKyp S52qwJc/DMbTPlTVlAFzPpBvEp86XQdtzeLCLy5Je6qdNUzBUsLkOGW94ozC0tmmWAJtj5PpPGfH JlBT++BYVVSrsPQjovmyBUpKrqhSG1Klt8RvGodaB+QeUGUdk+cVwEgbUkAGnk6agJN3MbNZaVCr cOAI27sEvcdpyGmjHcuMx8zkwzbeTzkKQqmtauW0Kc7jVsqoIm4mVShtQDHFP06V+h/OevnLuC7t Ji4FzxdOJXE0JWUyzEkqEzkmLHkbvD9c+G7YhR0kPb4b1RnwdK7Zx425LUu7Fhh3ENZtL67nh2/j W+jp++H0ckyPs92aIUGka+v+JpWm7H3kj/oGOdXbshFesX4rkMso2ZxRkaiZnn5/maMwCqESMpbn OhXlqJXVmQygpD6C4gtLtgT6zJRJlxBFrvBxtopZsNBkpcrIike94LvXkw16pYTpbSu3g3SJjKt2 PtKntHFRqFCpyaQm5wLaJoVXXQpu4S8lpoiAqfXhqk0Ve9u4lK8YBkARV2KXfkypShFFatERUL1h 3CZxybgkZGvcL/dfcYBnJ5ki5frG6AkWBgpLFYgBQQ22RK+YDZU2jXkAuBHTpqX1p4zE1DaPJLrj 7sAiwelxSBcGGgRCKIGoXAF801QJfmzeR4pVZDIWko+B5RAs8qPKEuoFrUqUI4wxpNqKy1np4rIP 1Kmitho5EnK50mWDJqDkIxoCyElD8BsfuLrrQy0ushgJuhCgjnyMiFrnYncrNlSkzf/SVkcph3mk EyAsyWu5N1a7cxjJVTroIopL6H2nZpFrX78nYlVZBkX5zv+7xjF7GaOxv0zka9oqaPby7qgfxZ7T 0th1mdFxr5igV3ze1Mr7aNRO51el2qC6u/h8U9fWHXUNMfm+Ixza/T9QELf4RVae81gi5fZex4Zh oaEgUsaOkTi6z0RMZ5ghgqHoqk+M31RVlzyk9ZJFIZ0olzAp/l51yoQhVN3ehJ1BcOKRU23N7e2q KF0qU8Q7SCqBjtmV5jy5I93IDdfSPeIUe5jrwNF8INA9NCkZOTaY8A+2YNBwW3IxNAQ13PKrsZ9N Gm0NJwlaHyfXJQ7G1PA4ER1ChNTSD7HONTUki1B/tWu5i8+Y/jB+dCKB6MtAKoaSqnKtNtvi3R0b 5KB/xJZlcUvHxuVDZIfHoFbuJ2di9ZmkJ7y/qsDKxqRFPlK4xxhhkIrsqfVRDMstKE9fkGSF1hFU 7DrgIzo9KBa6G7Ke67f/cSXx9gqShMfOe3pJ4bzWTue8Eh+LWO5ULcu3F3Sbmd6UWAgndLUA1vtJ xPoCyaE1PmQjeSZkiX7UgT+81eDh6VNTNBDBFL1GHj2p//pjhnZI4/GfwHyYD77h/S/YsXmEZW5k c3RyZWFtCmVuZG9iago1OCAwIG9iagoxMjE4CmVuZG9iago2MiAwIG9iago8PC9MZW5ndGggNjMg MCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyFVl1z2zYQfNevuLfaM5Ji+SNO8+bG SuuZOHFk5qnuA0QeJTQkQAOgPvLruweSkim5Y2k0skxwsbe7d+AznY0ndCbv9jstB+9m17TwgzP6 E5/F4HkwiQuo/UpL+iPBog80OackHzT3Tej8gq6vP1BSDk7uTGBnOIxuncoDHb1u7+9HM372x1fo M89drdyWzs8ml6fJv4OL3yn5MjjZr3Dsbe1S9jTfkueC06DNgpShuwdSWYbrnqyjynGuN6TS1LpM VgR7+ttgcnEAt15yWLKj0s51oQMg66qyLpD2ZJgzzgCdyV7GBiqVNgEf4AHsBUxqUfMmkAoEuD2a MukSZLCLkQuOI67FLuky4o+Bc/6+I5Uscdnxc60dl2xCVxCqFdjK2XnBpaeHx6tI6+HxPWXsU6fn IKpNr8JHkcYauuzvMZt+v/hIUGsl91aF3cpO/XLgEHlb1HK/p8e/vv34cktBuQWH5kbVEdKluNXD OdKYzUo7a5qCwLrF+/otoTkDVhfWgb6vONW5TlVRbOFW50SfGXa/HKJSqpQLOq0L5eSX16FWDdt1 lBnMVipwXL9XsY8FLu9gztebxJPCPbU/9KN93dsgaID/eGwRrM+tgymgLJos2LBTxWtCWKdxRwQi m9PdNPlMa+t+jhvF9ypKSgDKnpEblFfqbNTnjs0KaxYjdFpJiJj+Zc2wyVk0CAC8gaABwmItdM6V pNzxYXDL0ko20UDBZmr7ViBXVmeN+bUxjD70ymkYBqCq4I2EXvywxSo23ZJ7QuwSjDW7fEqprbHr pUZjrHVRxH4DbYX1UgHMAWrJEK6tQDhIraMuOJSzCjVUOwr8JQI/3WgfR8WuOUEm2NQWB7G46cWf 7n88JpRr56PVXmeYFo5r30ydDDIHNnHCiJ+j13z3AQsVxtAvuLHbFdWJx23ut4JgeL2//mYUZyyi IEjclbZLlPgvZhPnEEa3nfcat0LmJTtn3Qg7G37L/xC4rEJMe8xCtEEmmRDp8e/tlvGKC1vtZkAc hrF8/KUxri1UDFoV+4gAb84xRLrkLv5iQV3utP8/3vD8Cp5/slEaNikjVGHZthjI4ngSnXyEWVof DkKQoKpeDEq17YRA51nPQ/BaLIOcNRjoOBd44aIxr6mMy3Zv03ECdzTkFENc0p/jPp8ZLxCgaBZ0 Ec1f7AgToe4w/vs4u/ODlu86Km3EaYTZcWuFeTGM/BAT/FWRhLSzNWaQTAQVokjQQ76kfbWMhGj5 Uel9oH3m8QhQOwmHpHdIql9Pe3JEgip11h8QynSeI1fYsPN3iGR5r+eYULbCXJZ5iMPLM84P/Dio J0OyQFRUXTFlVs57345VHEt2zfFRQHQOroZ2jovm2Fnqqo81BwFuTv3yzU5+OlFPp+JJJTPfYe85 IrCG4z4OVizrHk9sVBqAV+cR8JNM7qeTaTZ+OoVR6K5i3O4w3VRIq6ebeiFcLybD+FhF/dffD2rB eJj7B5jTZPAd7/8AtRQYN2VuZHN0cmVhbQplbmRvYmoKNjMgMCBvYmoKMTEyMwplbmRvYmoKNjcg MCBvYmoKPDwvTGVuZ3RoIDY4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnichVZd c9s2EHzXr7i3xjOSYtlpnOYtTZw2M3HzYaUznaYPEHAk0ZCADIBy1F/fPZC0RElJ5PFIooi9w+7e gnd0Pl/Qufz177qZPP54RWWcnNNv+C8nd5NFvoH6N93Qr0vc9IwWF7QsJt26BV1c0tXVM1o2k0dv XOLgOM1eBVUkOnq9urmZfeS7ePwLveZVaFXY0sX54snZ8t/J5S+0fDt5tLuDv9qYrCsJBe59+BJJ OUOVjwmfApPziVRRsE5s8k/aO9zfMiV/9tNkcXmAV7ROJ+sdqUhtbFU9zas+P1p9PiN2alUzWdnQ zPhGWUd+zUHlFbYA4B6U4WgDmzmuXjwdyiwrGynwXYufGnZozpjAMXKkVDGtg0eFht7fXsl6HewK faPMLXdtPZn3RT5ef3j6nOR6G2zayr6iNX0vcdzJC+GYoq/bjHHz6XZJf7xbykaCN60GTXxPcYAK Nn6JU/LhFEGqWde22O6IP1yWKpVIKyfMr5gam2yphP3VdtzVMULDulLOxiaiuHCRvPZ1HDPYv258 spu82ef0pwrWtxA8JaVhgdjqSgS0DcSJ3uXbpiDUWVWTL07tK3LYWM1TapSbWTeDGrPGGgO9e9jO CdGTYDVqK7urFfxSsRnvDHqpTLnhde23ovMcZsaerItJOSmjYJi65hL0NKAHRjUsqGMklOZmnWBW UlrDJwDunS78bKwRAlEK+C/AeMUBvIpGsOmBC7IwCjVqqzNduSSUosKHkgW5bVYA8AVFWzrcB+wG RVXJR1it2NjAxTprmDDbhdVUBN+QxfDtbW2tUjUfr38Jj2IIQEy9nWbnxzVrKwi5K1Al71E2fl9Z yCn39EUOyN41ApP1urQOo4AdPUg+6NuLOQUqB1YH2+oI7Cobn8MDuGw3LPVtGDoQtrX2QdjHBsYg J+z8+MHLe6r1gkogBV9PDy2UuBQUOKVFbYSW7m0s332w//Vfsb7A4OMGCJYOm+GEZmPl29pkXiI4 AqfSDwjLrIpRZXmy2LXKObSV7DxwYg26zPYIQZVKTP2NIB6ujrEav7LS627EIVRhXRd1b66Xr0Hw X5wQqdAQDjXWiJHQ6QHVQ6TZfuizx3nDbkhTBIC0LA7AFXw43dH3NZODpO2yv9s5FIRjW7GCBXXf wOopyioNqbjbyah5rdp41BSipfNGnUvv48ohEX9wsqyDECHn4LhcN6J99HdFd2l4UHMoJfytsZvs snorOSbd8E5KxCZiotmxsaOvG+BGfeG9QAREgfmzUmXFsn9Uq1VCFjXDVIq18TXnix8U3dMElMqh I/lFoFVR7WPnOyQZB2RcD9TNtVGuxHkwRWldt3kGYTrEsUREpUIzVEEv4YBdHLdXOG5v2loGEX7/ 3nkrdN/+/u7T21fDI0PzsG6QIUfbShjZcA2b5qFSG2/NqdNpyHzMSG86LSLs4Q4BbLhGXIXtDw/N 62Fgdxh76lRqI7pgkB4eEk42hic6MKu9nDjdQVBxfvIpXT9z8GSBqMWh92CWMVuDpnjiAJjDyaFM L/nJbWd9vZsdRPdaTpuaoHruQzwh1Y8YQrS8QWChSDcWORvHWIO2e4tZBdg++m6Qx8A7STHgY6QV p46fHnBvG3gqkQGy7nSbwPn5IpP9EoGEB9BrM/98NkWgI4rnPfz11zWmPdKLtmyx9HIxzU/KNH79 /R6TSYvLf4B5vZx8wN//A2TD9GVuZHN0cmVhbQplbmRvYmoKNjggMCBvYmoKMTI3OAplbmRvYmoK NzIgMCBvYmoKPDwvTGVuZ3RoIDczIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic fVVNU9tIEL3rV/RtcZVRkHFiJycT8II3QLyO9rTew3jUkgbPh5gPHP/77ZFNmSFVwUUJNNPvve5+ 3X6Gi7yAi/g5PrnKPqwm0LjsAm7pt8mes6K/AMcHV/C1pEtTKEZQ1tkhroDRJUwmUyhVdrbQHq1G f35jWe3hl5+bh4fzFT67X0/gT9zYwOweRhfFeFA+ZZefobzPzk43KpTiBenG+swF3gJzUIVOCs48 ggrS01/Ogwsbx63ovDDagTc7Zis3+CMrLt/h+RahMjvtvEWmwAetUQJqL7xAtx7kAGWbIBsZelRC e4PjWhNkFeE0sBcjKrBImIJ7oZueRTHNGlQEDaYGJiUslinGicRT5WrBSTgwcIQgEVoTD1prQkNp UyGqPukqxVifHVJYD0DEPtSMIxh9wj7nrGMbwmOco3NAeHTN5QQz+vRanLIVdILPQdiDYlZVlI9D 16fSWUMIysHyRwFMV/SckqBY8Q1WRJxU+gfyWDAYR45jQz/l/ftghd/DNVVTVGjZa11PQpYSmUOS UqON1ejbJRwPzkXIoCnsBPRWsdCvxImYj29ETEjE4urx6ncCHo3GU8SUIugy9XUTvLHut0UjZxoe DmIcdezJUEcA69pYKqgy5AtNx9SA1Jkds9Qq0bEIsTN2Gx1E6TDwZNGoWcd+iL6ox5qw4FvSMwRk NBSmPpoiHtVGSrOLGC0Ni2IVQj9ATjRakMlYbC/1UKiOhMX/+GuGb2ze84iDni9J2tcts5KMMc9h iVFsms1dYDsUUCJvtZGmoak6Qs4VE/IL8BgvsJtxo7roxdzYJmF4oJlnhECWY9wk6FcyzoA8vw88 1vkr0ljds807Cn8MzVVEmjXGNPGFkDlxJlRziZrBDR1awRKmSE+3YeGZ7I/iyxfSdZvDCgVN0soo I8UQRpPxEMrvq8Xj9yGtzWI8HfZR+1QURqq8OlDN/AFe9Oi58Imqv8gr53d7E7Zwj5gOF9ON2gfq 7j86LkZHczCEb4a2WUr3RBhthJg5FXLG861NOL7ReiF/LOPq25IlRdrG+eK6hFu1uUtRt3l3Cpgh rTvKiK58HPWB5A1NK2le5esBeZOMJvPjopr/7GhOHFyFJtBiuyyG/dJ/94Xw75J2JhTj/whzXmZ/ 0+d//p3+8GVuZHN0cmVhbQplbmRvYmoKNzMgMCBvYmoKODY0CmVuZG9iago3NyAwIG9iago8PC9M ZW5ndGggNzggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJx1VNtS2zAQffdX7Fth xqhx0kLokyEJEEgYmrhlSunDRl4cJbYUdAmlX185F6ZKSjwZX/acs2e1Kz1DgyXQqK/NnVfRx9EJ FCZqwKX/F9FzlKwAsLnxCs4zD2pD0oTsKVrzEmi24OSkDVkVHfSlJS3JHnU1PlnY+3WHw6MRPZv9 CFzQRDvUr9BsJJ8Os1nUOoVsEB34UKYF5wLG6vBDlLS2Xx+ynn+vn3oVivILWKPSP5acQcZV5WPN 4y22g7pUBq4ZnHt/qHNlAq1vUixJG5FjvsX2+33ICYaYa5FvEp0tWYCNodWIYUAFSjLxBgvN9mmS xDBeoJChQz6b8FRY5nirYmQCi3fklw6GvINSBt6uHL6QgIz4VKpSFWJF/Ed1xWRrZjpdofcWYExq DtdKwY2aBuo3r04WC+Wjt2iFkli+FWhfYw/XhGE6M5uraTqXjiFncx2kuScJA/den24VO27H8CBm QnqfMOrGP5x/sCigK4z1bbax9yF9vIjhWqAsjINm0mgkzRg6UyF3vJROsReSddvrkhmXYdVawKWT OS6pLEXgqiMMVxsxU6wxKa8/7q3dlfP2SBYhvzYDQzURJYWecg+dOpHyGlGtAHuSQ9RcwUDQxPCw H7e9DgxwojRapX2roee0WuykKNfEVBIvccLI7Q073AtfMVbhmA8741GtvjNA3BNe0oobfeTlDFO6 2BkeUcI1qXAu+9JYYZ1V9TbJqCRfpJOCI1f1ZjhbktBqZ3S80MzrpLhkfhss7E4aXQgFF6Jwnkq5 em+LUp3xv/pPb9x3UlhRwHeSiOHCbPk+nC5X4U3LPjdXkM4UJTwe9HL2eBgDWcCSbc6t3u+FT2jg zBXOWGj5nV+fYDun2887LAiSz7+8Zi+LvvrrLyLxhNBlbmRzdHJlYW0KZW5kb2JqCjc4IDAgb2Jq CjY3NAplbmRvYmoKODIgMCBvYmoKPDwvTGVuZ3RoIDgzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2Rl Pj4Kc3RyZWFtCnicdZTJUhsxEIbv8xR9C1Sw4rFTLDmNwQ57hcCkUknIoZmRZYEWowXw26dnoYLs xFOuKUt/f73otx5hyHIYNk//rnT24XoPhM+GcExfkT1meSuA/lVpOCxJtA/5CMp51sXlMBrD3t4+ lDrbOjWBO8PDYOpwHmDjM728HFzzR7+5A5/5nYvoVjAa5h+3y/tsfADlRbZFWxdReriUInIFR9YE xx3SQnRSKbv9LsvHr8qSKz63RlYIp++ntNUszjRK9QmUrnQRZM24p43R7mvMWUQDR+iU9fAzGikw QbYtTaWQAVUKbAK7ONbFFW+1rLI6yTNR/AVN7SJccWrBVzHJ00PxVcWWvaoQzc4G7phbJyTVfI4O hURjpE+A34x84s7LsAI7h/KZU3FpA4I9/I0tYmglzKi18SjJDVygQCO5S1KcUdvLdu0N9b4NYJKH +X9K/47eS00nWi3oRE+wrrFOZ+Fk5b01KbgLY52+4L1mgz6V7gGerIGTKFJ3THkMnnK2Nnmwmpq6 sw6DdbL1xJtcDYQRZNBAitDpWc3TE11orMmHCxpgaprJM7oabqyKQVqzxkavu5BihQtrNxo4XNlo xODMwrnUKbYsm5rXeBorfxdFQW7h6KoFwxA2oCc0PPL5RMlBW3bC/eLQiDVzLNoAhkpioy9sq/mH q8kA8IMLaRLkDWpPXax13ojZqhEXS3TB0C/fCXtw/6c/YADXfM4dN1V7NAd5u35Ec4PbrVnNbrd3 gAcisv7+mL0sJU0AJlFEH2Cc77Q3ydot8+sKBYd89zcxZ2X2lZ4/iDFq72VuZHN0cmVhbQplbmRv YmoKODMgMCBvYmoKNjAzCmVuZG9iago4NyAwIG9iago8PC9MZW5ndGggODggMCBSL0ZpbHRlciAv RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJy9ll1z2jgUhu/5FWe42WTG8mJoQ9i78JGUNqQssNPZ3fRC 2AdQsSUiySH01++RMAmsofRiZ+1hbGPp6NWj9xz5CWphBDV3Ftc4q/w6asLcVGpwR7955akS+QZQ XOIM2hNqdA1RHSazyrZfBPUGNJvXMMkqF31pUUu0rKv5zELp6A4GbIRPpvwGbnGqc643UK9F7y4n 3yqNFkzuKxetMAoBHpTOuBXPCCOcoUYZo7n8pVK/8m2o+9+j2049ilpfAdqaJxJ1AOMwgOon3MBa 6cTATGnIDYKQQI0NWAV9mYiYW6RQUWMXau8grbnQmKG0cI/PmJpqAO3OEKJ3gQsCbsgABlzHC4ha rWb4JqoV1kl4X86OS/ei+6wbThdcJlwLlixiFqfcGDblBhO20jgTL19PaWsX/bbz/MDTNTeCB3BH T3c5vSK5afG2i3JObcKgGHjvmCwETnluA7inhp+UXiiJMoCP9EQDQD+EW66141ntfugMn6/AiyxH 8qphq5owJc4C7MzsWO19OdDjBS3Y0q3TSqu5RmMeL0lQnnpzNMLDhXcMl4VsdpVxuQtNnVeorUBz kuHhdIe0TCmt7xGAYxQWqUUBpRuWVd+LnBD1HaChF0CXnYDqEfBbPmeUs1r9DUc5xs/yWfOlWPI1 Z5Sb+GLZKhMrFq9YvmIGV1zTxJU8SelL0Zss7yl9X2y4lLnePjse43CfWFlndfw6CqgZdJS0WqW+ 6x8GNQxTLtEnKDF72cBATUWK5TiO7qu1fmpSrFb7Lwy2UUtlOUuyjJkYJRlancT1p2/r023fN13M qBv93yug/RVChyvyDCGAmJKiLHQ31rZ4dYWxWkxzS2nmCQlLqLjkc1+hTpvsiHrichxDOcbn2Kop LRKhqf0LzZCTT9merrBDQjRPxXe632k8XcKcyeUWT1vJbyovqrbD85ENQvevdC2qN/uzL2skOnsj v9IhrzhHxYiJkHPjvHeXqilPyxE6Ksty6XYDco1xFi2KtbOL64TUwtmkizFmWx611lke3Y3kmYj/ TxbFkMcsAuN4QTc0ByPmkkA5W92m3FJmlQPd0K5G9o1trl0JK6FsaNoe/I7voR2n+oqRUv8B1zDB eCFVquZU3YI3jb6KYJxrejiWsA+TwdjRJ+jXZ6HvooaD/vAk8A7tTNskrZ5JLFgLu/hBTTqCpt/r 9Q7ZHBrsh6QeL/qdzuMlfKHsNAu1cugmmGJ8YNHfYKZVVg40QoP+e4S+b8bW776JcdWNKiylcN3R e1/3QBwCGq2XhA4tWuBpWETpvazow8fATT7PjYVGFPgPs8OhHPs5QtR0kHuTyu90/gPKXN1kZW5k c3RyZWFtCmVuZG9iago4OCAwIG9iagoxMDAyCmVuZG9iago5MiAwIG9iago8PC9MZW5ndGggOTMg MCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyNVtty4jgQfecrunjZpMp4MZDbvGwR biHBCQvsZFKbPAi7wZrYkiPZMPz9tMQlJJipmKIsbKn79Onu07xB1fWgaj6be5CU/h5dwFyXqtCj 77z0VvLsBtjcggSuJ7TpErwaTGal9TkPanW4uLiESVI66YsMlcCs0lZslsHB1fb9ygjf9OEb6OJU 5UytoFb1GqeTn6X6FUwGpRN69f+Qpagqba4zxad5hqHryymPebZyh35/+HL6V8mrb3fvXa2ICQdu XAfKQyV/rcAeQ+gPYcmzCPYswtYi2fpkpSmCSCpddgDISoAYcjHXIGfQi+UUWzKBR6ledSRTAClg jCyJUetDS49coXmzc+ZAGwNMpqhM2FWXjtTOvxL2CBccl18I/Em+yoyt1z84OnBLizHyjJZDWjIR QtuFAc+dQ7zlfYLszpVgCQ92+MFngs0xQZEBFxt6D+1sy+IbtHKlzOZmmirJggi1tdvXOkfL8K3M lWAxsXtohphOcsEDlnEptAMLGbtw7oCQLngOpKkLjYp35nyoJe/rpI6bnaOMdrmOUDngE2dNEaLS khju0q87mWqM6akhNojYzGzrbaj13cMwaFNMpNGucvNDCVJZ7ojdEgQzqaDeA8JWLsjQ54rMIgTv ikp7Tbllitgcr5JUap4nVJ+HRoY2GkYx9EUoyZ9Fvm6VEQu5/MQ8PJ8M+/6o9XxagKhWrV4WUj6Q 5riYu/9pVEd5vuNqulrzV96esFGZU6ZAPkA5VmqbuB3i4uqsEI3P52oN50Ym6DbnVJX6KKpH9spf 2ZL6aETAvrOYhSb92yzfuuDninHCvLMLxm6BmFhHMJFLpkK964yKDhixvUt/G9NYrkxf6a+mvdny oUZgWvK+82NCN0GViCJAK0rdPMtVAZ57zJYkXgbwBINIyFjOOeoPwlQ9L6bQVojbZhlzH2azWDKD 5yiHAyTJuSPG7MLI0BMR9kT3UWSe9Ddkjl2SLynmhswjemJcwrvLb8T1kjJA3dJiglS2ywl+zBeo /jElM+73Wg++X1SrXtUpUt5Rt1W/OKu/gBE4YVqVUrzuZ+r3n3KLzaRqhDEz3TtBlXDL38qmrJAE MgzGMhnMBRpuG4euz2qecd3LRcgWGMdE09jylhtWDIVtXDDFUmbffacHxNgyjHK1su+PeTcRXLsw pAKND2fi4pzIMgCNf9KzfJ7rrKifDcT6ZZUgjmXMk+2oaTGdEdo8CDg1SouedGKfxa98jdk4H7jH oF2bOK0m3tCNqSCiFo/3wZHq3Phm8Xz6h2H9PpC2wRBSBx6CTG6KuSiaq0bjxeogNYJeYy/vq/E4 T1OpMivGBKFBpmkAawz/nGlj14F7uTg64mnXea1mnNNUSHiYOTAh548Mo5jrIFoPnE1b3CkaQsLQ Xb5mGo95ftcOi9fP44y4pFQOaNYgVfMuHBrZ+zVABs9q1qD5/0B8d0KXNB4wA0aTdn11fqX0L0Zv y6Pu2QZqfIRgJGJOk+jSqEFnUvqXPr8Bbz/NpGVuZHN0cmVhbQplbmRvYmoKOTMgMCBvYmoKMTEz NQplbmRvYmoKOTcgMCBvYmoKPDwvTGVuZ3RoIDk4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4K c3RyZWFtCnichZXbctpIEIbv9RRdvoldJWt14GB2bywDJnHAVkCudTnsxVhqpAliBo9G2OTpt0eI zRLCLoLSaab7+3v+Hl7BdTxwzdGck5X127QLWWm5MKJfZr1aXj0AmlOygpuYBl2B50O8sHbzPPAD 6HavIF5Z55+ERiVQXw4UW2g4+gwmk8spvpbHb+AWX1TF1BZ812tdxN+soAfx2Do/HPUp2nRgfh5N zMX8AgZyxbgoz2yY3vah4/stG8K14oUJ4zkXHyy/sw/zlYZ0/G77L4AI1ZKm2dB3bLiTuSilsGFA N0ykcOdAqJZLacPZRL7wgustzKr1WipNAb3gF1xc1Gj/cHTbFLcqtqcwAtcjjOe8suGZsv7JlnzJ 3hhNbxjGDr1lIiOGkJKrDW5BLmDPc4qjwTQ8OkfYr8eei9L+N1fXNeX5rHiZC0YlmRHOZynTgu/Q xrJSyBWVJjLYhP+lAQ6dU0yDSmtSdjaWCSv4d0xhKivNRQYLqSBS8n2704VNDSnQTyFqeGIjIFxr XL2gMgr8XyjouT1SMKpEyjZYGG6j4TmXxPpUq1G5FEja7ujuFnmGNowaEdOTIvZFOCPEFsRk7wVP 4GGxKCRLiarARJOah7XmUvwQdizlQOlOGCH/y7XBT6LimeMHTosMc4otGEURkY1QoGIFRCxZooYp S7kkMrXhCVLPjKLpjDoGBdkqwRUKXR7TGfDhRhYbWqVHwTeoSooYo1JYasXpehc2TBIsS7hH/SbV 8jjO/Hx4+RhPw3vKyOqxJNZwQjyFnRzaVhz6ujZMmEryU9J7gRv8n/LdLgD3bIUw25ZkEFP9BFMy a/kHzDTLEIKG4Bh2h0R5gHrCN0THLmt2o7DSuVTlBwjTlGKXWB4Qf4RQ0ACxhT5VmaqAKSdbzC8O BHys2BtyqmqSC1nIjON+JdpBy4UxZizZwkA5cFPxIjWdElDDFUxQ38VP0G27Zp97nIXNtCHJL36H 3GFOQnmvOSI6UmU/uE0bsjVSpDGvDmD6ORescWUTjhZe+zb4V/BUMfFWkVfeOYQbapTdAxhw44ZE 23CD/JsB9FzXbRNlHe4Qq+BVWue+TszLVZ3KSeTqAC/iZDKeLKn2XOMB4oOijXAPR8JVhZBW0C9k CX3akDQWBBJBz/P9DiHQukhxOcMNzwSte7vtkZpbZWx/SLZucjqlyXkt6zwNmee26vzNQg5TZ35h A/UVK5zGN8P3NScTQFhlVakhoL3V/Hkdmgu+RsZ9Xs+YeBhbX+j4G76Z8qJlbmRzdHJlYW0KZW5k b2JqCjk4IDAgb2JqCjk0OQplbmRvYmoKMTAyIDAgb2JqCjw8L0xlbmd0aCAxMDMgMCBSL0ZpbHRl ciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxlUE1vwjAMvedX+DaQaNe0fG0nxtdgwMZYL9PYwdBQ QpsEklQa/36BdZoYsSLL7z3bTz5A4FMITlHmtSC3ixakhgTw6H5KDoSeBVCmtYBu7ERtoCHEG/LT RyGMoNVqQyxIZSwt05JZr69xY+Hq9Wczb8EO5pqBIVvpAvURwoDWq/GORHcQT0nFUSOeMKvMlsO7 ypTF6g2h0S856ffHMMWVA09l6FGPNuBlixprMCx2XHCpavCG3KJwUNRoeu1GEMIT7lGWXQOBPL+H 43l8J0sSnuPK+Lu94/98PKlCcpgovVWSyQsXXa0wWSsBPSWEU63RciVNOX6udJZhjjJDW0BYd8bG z14Q0HYAI5YbLjPuMC6dJLm0tDvt9KUyexSd9IT5bo3TNOrN8/LeFiUsK4PEX1ZrwCxg7pcnHXzt uWYGHoq0MBYiWjsf99/hP+aYMkd8uqGDmLy6+AZnp4uvZW5kc3RyZWFtCmVuZG9iagoxMDMgMCBv YmoKMzUxCmVuZG9iago0IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJd Ci9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0K L0V4dEdTdGF0ZSA5IDAgUgovRm9udCAxMCAwIFIKPj4KL0NvbnRlbnRzIDUgMCBSCj4+CmVuZG9i agoxMSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAv UGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUg MTQgMCBSCi9Gb250IDE1IDAgUgo+PgovQ29udGVudHMgMTIgMCBSCj4+CmVuZG9iagoxNiAwIG9i ago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMg MCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTkgMCBSCi9G b250IDIwIDAgUgo+PgovQ29udGVudHMgMTcgMCBSCj4+CmVuZG9iagoyMSAwIG9iago8PC9UeXBl L1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNv dXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMjQgMCBSCi9Gb250IDI1IDAg Ugo+PgovQ29udGVudHMgMjIgMCBSCj4+CmVuZG9iagoyNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVk aWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Q cm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMjkgMCBSCi9Gb250IDMwIDAgUgo+PgovQ29u dGVudHMgMjcgMCBSCj4+CmVuZG9iagozMSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAg MCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9Q REYgL1RleHRdCi9FeHRHU3RhdGUgMzQgMCBSCi9Gb250IDM1IDAgUgo+PgovQ29udGVudHMgMzIg MCBSCj4+CmVuZG9iagozNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQy XQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRd Ci9FeHRHU3RhdGUgMzkgMCBSCi9Gb250IDQwIDAgUgo+PgovQ29udGVudHMgMzcgMCBSCj4+CmVu ZG9iago0MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRl IDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3Rh dGUgNDQgMCBSCi9Gb250IDQ1IDAgUgo+PgovQ29udGVudHMgNDIgMCBSCj4+CmVuZG9iago0NiAw IG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50 IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNDkgMCBS Ci9Gb250IDUwIDAgUgo+PgovQ29udGVudHMgNDcgMCBSCj4+CmVuZG9iago1MSAwIG9iago8PC9U eXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9S ZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNTQgMCBSCi9Gb250IDU1 IDAgUgo+PgovQ29udGVudHMgNTIgMCBSCj4+CmVuZG9iago1NiAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8 PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNTkgMCBSCi9Gb250IDYwIDAgUgo+Pgov Q29udGVudHMgNTcgMCBSCj4+CmVuZG9iago2MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3gg WzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0 Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNjQgMCBSCi9Gb250IDY1IDAgUgo+PgovQ29udGVudHMg NjIgMCBSCj4+CmVuZG9iago2NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUg ODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1Rl eHRdCi9FeHRHU3RhdGUgNjkgMCBSCi9Gb250IDcwIDAgUgo+PgovQ29udGVudHMgNjcgMCBSCj4+ CmVuZG9iago3MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90 YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRH U3RhdGUgNzQgMCBSCi9Gb250IDc1IDAgUgo+PgovQ29udGVudHMgNzIgMCBSCj4+CmVuZG9iago3 NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFy ZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNzkg MCBSCi9Gb250IDgwIDAgUgo+PgovQ29udGVudHMgNzcgMCBSCj4+CmVuZG9iago4MSAwIG9iago8 PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBS Ci9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgODQgMCBSCi9Gb250 IDg1IDAgUgo+PgovQ29udGVudHMgODIgMCBSCj4+CmVuZG9iago4NiAwIG9iago8PC9UeXBlL1Bh Z2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJj ZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgODkgMCBSCi9Gb250IDkwIDAgUgo+ PgovQ29udGVudHMgODcgMCBSCj4+CmVuZG9iago5MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFC b3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9j U2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgOTQgMCBSCi9Gb250IDk1IDAgUgo+PgovQ29udGVu dHMgOTIgMCBSCj4+CmVuZG9iago5NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1 OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYg L1RleHRdCi9FeHRHU3RhdGUgOTkgMCBSCi9Gb250IDEwMCAwIFIKPj4KL0NvbnRlbnRzIDk3IDAg Ugo+PgplbmRvYmoKMTAxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJd Ci9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0K L0V4dEdTdGF0ZSAxMDQgMCBSCi9Gb250IDEwNSAwIFIKPj4KL0NvbnRlbnRzIDEwMiAwIFIKPj4K ZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9LaWRzIFsKNCAwIFIKMTEgMCBSCjE2IDAg UgoyMSAwIFIKMjYgMCBSCjMxIDAgUgozNiAwIFIKNDEgMCBSCjQ2IDAgUgo1MSAwIFIKNTYgMCBS CjYxIDAgUgo2NiAwIFIKNzEgMCBSCjc2IDAgUgo4MSAwIFIKODYgMCBSCjkxIDAgUgo5NiAwIFIK MTAxIDAgUgpdIC9Db3VudCAyMAo+PgplbmRvYmoKMSAwIG9iago8PC9UeXBlIC9DYXRhbG9nIC9Q YWdlcyAzIDAgUgovTWV0YWRhdGEgMTA2IDAgUgo+PgplbmRvYmoKNyAwIG9iago8PC9UeXBlL0V4 dEdTdGF0ZQovT1BNIDE+PmVuZG9iago5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEwIDAg b2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjE0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE1 IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjE5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2Jq CjIwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjI0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5k b2JqCjI1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjI5IDAgb2JqCjw8L1I3CjcgMCBSPj4K ZW5kb2JqCjMwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjM0IDAgb2JqCjw8L1I3CjcgMCBS Pj4KZW5kb2JqCjM1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjM5IDAgb2JqCjw8L1I3Cjcg MCBSPj4KZW5kb2JqCjQwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjQ0IDAgb2JqCjw8L1I3 CjcgMCBSPj4KZW5kb2JqCjQ1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjQ5IDAgb2JqCjw8 L1I3CjcgMCBSPj4KZW5kb2JqCjUwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjU0IDAgb2Jq Cjw8L1I3CjcgMCBSPj4KZW5kb2JqCjU1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjU5IDAg b2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjYwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjY0 IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjY1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2Jq CjY5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjcwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5k b2JqCjc0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjc1IDAgb2JqCjw8L1I4CjggMCBSPj4K ZW5kb2JqCjc5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjgwIDAgb2JqCjw8L1I4CjggMCBS Pj4KZW5kb2JqCjg0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjg1IDAgb2JqCjw8L1I4Cjgg MCBSPj4KZW5kb2JqCjg5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjkwIDAgb2JqCjw8L1I4 CjggMCBSPj4KZW5kb2JqCjk0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjk1IDAgb2JqCjw8 L1I4CjggMCBSPj4KZW5kb2JqCjk5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEwMCAwIG9i ago8PC9SOAo4IDAgUj4+CmVuZG9iagoxMDQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTA1 IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjggMCBvYmoKPDwvQmFzZUZvbnQvQ291cmllci9U eXBlL0ZvbnQKL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMTA2IDAgb2JqCjw8L1R5cGUvTWV0YWRh dGEKL1N1YnR5cGUvWE1ML0xlbmd0aCAxMzI5Pj5zdHJlYW0KPD94cGFja2V0IGJlZ2luPSfvu78n IGlkPSdXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQnPz4KPD9hZG9iZS14YXAtZmlsdGVycyBlc2M9 IkNSTEYiPz4KPHg6eG1wbWV0YSB4bWxuczp4PSdhZG9iZTpuczptZXRhLycgeDp4bXB0az0nWE1Q IHRvb2xraXQgMi45LjEtMTMsIGZyYW1ld29yayAxLjYnPgo8cmRmOlJERiB4bWxuczpyZGY9J2h0 dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMnIHhtbG5zOmlYPSdodHRw Oi8vbnMuYWRvYmUuY29tL2lYLzEuMC8nPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0nYjEy NmI0MTEtZDc2Mi0xMWVlLTAwMDAtNTdjYmMzZDYxMzM4JyB4bWxuczpwZGY9J2h0dHA6Ly9ucy5h ZG9iZS5jb20vcGRmLzEuMy8nIHBkZjpQcm9kdWNlcj0nR1BMIEdob3N0c2NyaXB0IDkuMDInLz4K PHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J2IxMjZiNDExLWQ3NjItMTFlZS0wMDAwLTU3Y2Jj M2Q2MTMzOCcgeG1sbnM6eG1wPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJz48eG1wOk1v ZGlmeURhdGU+MjAxNC0wMi0yN1QwMToyODo1NiswMTowMDwveG1wOk1vZGlmeURhdGU+Cjx4bXA6 Q3JlYXRlRGF0ZT4yMDE0LTAyLTI3VDAxOjI4OjU2KzAxOjAwPC94bXA6Q3JlYXRlRGF0ZT4KPHht cDpDcmVhdG9yVG9vbD5HTlUgRW5zY3JpcHQgMS42LjUuOTA8L3htcDpDcmVhdG9yVG9vbD48L3Jk ZjpEZXNjcmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J2IxMjZiNDExLWQ3NjIt MTFlZS0wMDAwLTU3Y2JjM2Q2MTMzOCcgeG1sbnM6eGFwTU09J2h0dHA6Ly9ucy5hZG9iZS5jb20v eGFwLzEuMC9tbS8nIHhhcE1NOkRvY3VtZW50SUQ9J2IxMjZiNDExLWQ3NjItMTFlZS0wMDAwLTU3 Y2JjM2Q2MTMzOCcvPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0nYjEyNmI0MTEtZDc2Mi0x MWVlLTAwMDAtNTdjYmMzZDYxMzM4JyB4bWxuczpkYz0naHR0cDovL3B1cmwub3JnL2RjL2VsZW1l bnRzLzEuMS8nIGRjOmZvcm1hdD0nYXBwbGljYXRpb24vcGRmJz48ZGM6dGl0bGU+PHJkZjpBbHQ+ PHJkZjpsaSB4bWw6bGFuZz0neC1kZWZhdWx0Jz5FbnNjcmlwdCBPdXRwdXQ8L3JkZjpsaT48L3Jk ZjpBbHQ+PC9kYzp0aXRsZT48L3JkZjpEZXNjcmlwdGlvbj4KPC9yZGY6UkRGPgo8L3g6eG1wbWV0 YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQgZW5kPSd3Jz8+CmVu ZHN0cmVhbQplbmRvYmoKMiAwIG9iago8PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQgOS4wMikK L0NyZWF0aW9uRGF0ZShEOjIwMTQwMjI3MDEyODU2KzAxJzAwJykKL01vZERhdGUoRDoyMDE0MDIy NzAxMjg1NiswMScwMCcpCi9UaXRsZShFbnNjcmlwdCBPdXRwdXQpCi9DcmVhdG9yKEdOVSBFbnNj cmlwdCAxLjYuNS45MCk+PmVuZG9iagp4cmVmCjAgMTA3CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAw MDAyNDgyNSAwMDAwMCBuIAowMDAwMDI3NjAzIDAwMDAwIG4gCjAwMDAwMjQ2MzEgMDAwMDAgbiAK MDAwMDAyMTM4OSAwMDAwMCBuIAowMDAwMDAwMDE1IDAwMDAwIG4gCjAwMDAwMDExNzEgMDAwMDAg biAKMDAwMDAyNDg5MSAwMDAwMCBuIAowMDAwMDI2MTM0IDAwMDAwIG4gCjAwMDAwMjQ5MzIgMDAw MDAgbiAKMDAwMDAyNDk2MSAwMDAwMCBuIAowMDAwMDIxNTQ4IDAwMDAwIG4gCjAwMDAwMDExOTEg MDAwMDAgbiAKMDAwMDAwMTg2NiAwMDAwMCBuIAowMDAwMDI0OTkxIDAwMDAwIG4gCjAwMDAwMjUw MjEgMDAwMDAgbiAKMDAwMDAyMTcxMCAwMDAwMCBuIAowMDAwMDAxODg2IDAwMDAwIG4gCjAwMDAw MDI0MjggMDAwMDAgbiAKMDAwMDAyNTA1MSAwMDAwMCBuIAowMDAwMDI1MDgxIDAwMDAwIG4gCjAw MDAwMjE4NzIgMDAwMDAgbiAKMDAwMDAwMjQ0OCAwMDAwMCBuIAowMDAwMDA0MDI3IDAwMDAwIG4g CjAwMDAwMjUxMTEgMDAwMDAgbiAKMDAwMDAyNTE0MSAwMDAwMCBuIAowMDAwMDIyMDM0IDAwMDAw IG4gCjAwMDAwMDQwNDggMDAwMDAgbiAKMDAwMDAwNTUyNSAwMDAwMCBuIAowMDAwMDI1MTcxIDAw MDAwIG4gCjAwMDAwMjUyMDEgMDAwMDAgbiAKMDAwMDAyMjE5NiAwMDAwMCBuIAowMDAwMDA1NTQ2 IDAwMDAwIG4gCjAwMDAwMDY2MjcgMDAwMDAgbiAKMDAwMDAyNTIzMSAwMDAwMCBuIAowMDAwMDI1 MjYxIDAwMDAwIG4gCjAwMDAwMjIzNTggMDAwMDAgbiAKMDAwMDAwNjY0OCAwMDAwMCBuIAowMDAw MDA3Njg5IDAwMDAwIG4gCjAwMDAwMjUyOTEgMDAwMDAgbiAKMDAwMDAyNTMyMSAwMDAwMCBuIAow MDAwMDIyNTIwIDAwMDAwIG4gCjAwMDAwMDc3MDkgMDAwMDAgbiAKMDAwMDAwODYwOSAwMDAwMCBu IAowMDAwMDI1MzUxIDAwMDAwIG4gCjAwMDAwMjUzODEgMDAwMDAgbiAKMDAwMDAyMjY4MiAwMDAw MCBuIAowMDAwMDA4NjI5IDAwMDAwIG4gCjAwMDAwMDk5MjAgMDAwMDAgbiAKMDAwMDAyNTQxMSAw MDAwMCBuIAowMDAwMDI1NDQxIDAwMDAwIG4gCjAwMDAwMjI4NDQgMDAwMDAgbiAKMDAwMDAwOTk0 MSAwMDAwMCBuIAowMDAwMDExMjQzIDAwMDAwIG4gCjAwMDAwMjU0NzEgMDAwMDAgbiAKMDAwMDAy NTUwMSAwMDAwMCBuIAowMDAwMDIzMDA2IDAwMDAwIG4gCjAwMDAwMTEyNjQgMDAwMDAgbiAKMDAw MDAxMjU1NCAwMDAwMCBuIAowMDAwMDI1NTMxIDAwMDAwIG4gCjAwMDAwMjU1NjEgMDAwMDAgbiAK MDAwMDAyMzE2OCAwMDAwMCBuIAowMDAwMDEyNTc1IDAwMDAwIG4gCjAwMDAwMTM3NzAgMDAwMDAg biAKMDAwMDAyNTU5MSAwMDAwMCBuIAowMDAwMDI1NjIxIDAwMDAwIG4gCjAwMDAwMjMzMzAgMDAw MDAgbiAKMDAwMDAxMzc5MSAwMDAwMCBuIAowMDAwMDE1MTQxIDAwMDAwIG4gCjAwMDAwMjU2NTEg MDAwMDAgbiAKMDAwMDAyNTY4MSAwMDAwMCBuIAowMDAwMDIzNDkyIDAwMDAwIG4gCjAwMDAwMTUx NjIgMDAwMDAgbiAKMDAwMDAxNjA5OCAwMDAwMCBuIAowMDAwMDI1NzExIDAwMDAwIG4gCjAwMDAw MjU3NDEgMDAwMDAgbiAKMDAwMDAyMzY1NCAwMDAwMCBuIAowMDAwMDE2MTE4IDAwMDAwIG4gCjAw MDAwMTY4NjQgMDAwMDAgbiAKMDAwMDAyNTc3MSAwMDAwMCBuIAowMDAwMDI1ODAxIDAwMDAwIG4g CjAwMDAwMjM4MTYgMDAwMDAgbiAKMDAwMDAxNjg4NCAwMDAwMCBuIAowMDAwMDE3NTU5IDAwMDAw IG4gCjAwMDAwMjU4MzEgMDAwMDAgbiAKMDAwMDAyNTg2MSAwMDAwMCBuIAowMDAwMDIzOTc4IDAw MDAwIG4gCjAwMDAwMTc1NzkgMDAwMDAgbiAKMDAwMDAxODY1MyAwMDAwMCBuIAowMDAwMDI1ODkx IDAwMDAwIG4gCjAwMDAwMjU5MjEgMDAwMDAgbiAKMDAwMDAyNDE0MCAwMDAwMCBuIAowMDAwMDE4 Njc0IDAwMDAwIG4gCjAwMDAwMTk4ODEgMDAwMDAgbiAKMDAwMDAyNTk1MSAwMDAwMCBuIAowMDAw MDI1OTgxIDAwMDAwIG4gCjAwMDAwMjQzMDIgMDAwMDAgbiAKMDAwMDAxOTkwMiAwMDAwMCBuIAow MDAwMDIwOTIzIDAwMDAwIG4gCjAwMDAwMjYwMTEgMDAwMDAgbiAKMDAwMDAyNjA0MSAwMDAwMCBu IAowMDAwMDI0NDY1IDAwMDAwIG4gCjAwMDAwMjA5NDMgMDAwMDAgbiAKMDAwMDAyMTM2OCAwMDAw MCBuIAowMDAwMDI2MDcyIDAwMDAwIG4gCjAwMDAwMjYxMDMgMDAwMDAgbiAKMDAwMDAyNjE5NiAw MDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDEwNyAvUm9vdCAxIDAgUiAvSW5mbyAyIDAgUgovSUQg WzxFNjdGQURBQzUyMDZCQTMyQ0MwNzZEMzQ5RDE3NzJEOD48RTY3RkFEQUM1MjA2QkEzMkNDMDc2 RDM0OUQxNzcyRDg+XQo+PgpzdGFydHhyZWYKMjc3ODIKJSVFT0YK ------=_NextPart_000_0037_01CF3321.151811B0-- From nobody Thu Feb 27 02:33:50 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266931A0168 for ; Thu, 27 Feb 2014 02:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ww-b1-ElA4eP for ; Thu, 27 Feb 2014 02:33:47 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2551A0179 for ; Thu, 27 Feb 2014 02:33:47 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s1RAXhWs003248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 27 Feb 2014 12:33:43 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s1RAXhOs010254; Thu, 27 Feb 2014 12:33:43 +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: <21263.5255.121406.713393@fireball.kivinen.iki.fi> Date: Thu, 27 Feb 2014 12:33:43 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8NVfjBP3tsPDlBkwi2aY4fPmkdA Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 10:33:50 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Rob Austein is next in the rotation. For telechat 2014-03-20 Reviewer LC end Draft Julien Laganier T 2014-02-28 draft-fairhurst-ipdvb-ule-iana-05 Chris Lonvick T 2014-02-18 draft-ietf-dhc-dhcpv6-unknown-msg-05 Tom Yu TR2014-01-17 draft-ietf-abfab-arch-12 For telechat 2014-04-03 Derek Atkins T 2014-03-12 draft-ietf-ipsecme-ikev2-fragmentation-05 Sandy Murphy T 2014-03-05 draft-melnikov-smime-msa-to-mda-03 Last calls and special requests: Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-11 Adam Montville 2014-02-19 draft-ietf-storm-rdmap-ext-08 Russ Mundy 2014-03-24 draft-mahalingam-dutt-dcops-vxlan-08 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Magnus Nystrom 2014-02-24 draft-ietf-mpls-ldp-applicability-label-adv-02 Radia Perlman 2014-02-24 draft-ietf-multimob-pmipv6-source-07 Vincent Roca 2014-02-25 draft-ietf-sidr-policy-qualifiers-01 Zach Shelby 2013-08-30 draft-kaplan-insipid-session-id-03 Ondrej Sury 2014-02-27 draft-ietf-ippm-testplan-rfc2680-04 Carl Wallace 2014-03-14 draft-drage-sipping-rfc3455bis-13 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-10 Brian Weis 2014-02-28 draft-ietf-ecrit-trustworthy-location-08 Tom Yu 2014-03-03 draft-ietf-mpls-special-purpose-labels-05 Dacheng Zhang 2014-03-14 draft-vanelburg-dispatch-private-network-ind-05 -- kivinen@iki.fi From nobody Thu Feb 27 19:27:46 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C451A039A; Thu, 27 Feb 2014 19:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SI2TeoLuA6rF; Thu, 27 Feb 2014 19:27:40 -0800 (PST) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4A26B1A02C5; Thu, 27 Feb 2014 19:27:40 -0800 (PST) Received: by mail-yh0-f53.google.com with SMTP id v1so135888yhn.26 for ; Thu, 27 Feb 2014 19:27:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=mhtXIKm1v8PgHF4XsVGBf2HeiVveKqFEgbT5viWd6xs=; b=Hw9p1OStWuJnKP505DQ5NqR3i3q9R3gj7X/srueVV48kV9SjwkVQ1nkMsQ788qT0q2 QtEzgwqZ11XtLvuE8E6U7K5pDw8C5mtpF1okLGrEFUOfeJhmemg/Q442HEOeKxeEEPqw t4xE/7rBjy4QfATVSKoopOqve7P8qr1uFNlPoHy+wPL6YyIi5DmE+9+XJpS1kDfaCzlr woyrTJKb6IcOtkj8Z2XReERJK/uJz8bBXnN1f7xPkNIMfrKHxRFhVkNGXNbnMj3HNpnW Y+SQgjSMcmk7RLrMwlxiJQYCVng5+i4b+NBij9E6xMsvNkAQyvIEGyMAZUh9lXtuTp6t z2RQ== MIME-Version: 1.0 X-Received: by 10.236.223.73 with SMTP id u69mr431828yhp.40.1393558058536; Thu, 27 Feb 2014 19:27:38 -0800 (PST) Received: by 10.170.81.136 with HTTP; Thu, 27 Feb 2014 19:27:38 -0800 (PST) Date: Thu, 27 Feb 2014 19:27:38 -0800 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: "secdir@ietf.org" , draft-ietf-mpls-ldp-applicability-label-adv@tool.ietf.org Content-Type: multipart/alternative; boundary=089e016349a40d929d04f36f05fc Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/aH21mBVE092xN26lz-Q016KFJYM Cc: "iesg@ietf.org" Subject: [secdir] Secdir review of draft-ietf-mpls-ldp-applicability-label-adv-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 03:27:41 -0000 --089e016349a40d929d04f36f05fc Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document clarifies label advertising behavior for LDP speakers. As such, it does not add any new functionality to LDP and hence the Sec Cons section looks fully adequate to me. -- -- Magnus --089e016349a40d929d04f36f05fc Content-Type: text/html; charset=ISO-8859-1
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document clarifies label advertising behavior for LDP speakers. As such, it does not add any new functionality to LDP and hence the Sec Cons section looks fully adequate to me.

--
-- Magnus
--089e016349a40d929d04f36f05fc--