From nobody Mon Nov 3 07:11: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 631AC1A038F; Mon, 3 Nov 2014 07:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 jZqc35r6Anqb; Mon, 3 Nov 2014 07:11:18 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A95921A036D; Mon, 3 Nov 2014 07:11:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8362; q=dns/txt; s=iport; t=1415027478; x=1416237078; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=zvlau6IGp7NhM1gjZQDnbK8ewHGWT95T85PRGy48+NU=; b=Khs/8Rzj8lM4+IdGjgwDsVCK1jkW/UpIPbNwmwn3A/MRBYMyiX+HrXoF RZSY2UUto0kRDfMw1elO5tdGeGzid8G9fKvcIi4oXbQ8Ph1BlWPYYLplx pPyZ8ai0l4gAjA5Y5pZr3voI/7gU92DUqpCPm0xmWT4GiwmmDlIcARWOu I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAOGZV1StJV2U/2dsb2JhbABcgkhGVFgE1VMCgSEWAQEBAQF9hAIBAQEELVwCAQgRAwECKAchERQJCAEBBAESiCwDEsEwDYZAAQEBAQEBAQEBAQEBAQEBAQEBAQEBF45WgikYhEsFj3uCH4cSgkSCEYExjjCCZoQJg3hsAYFHgQMBAQE X-IronPort-AV: E=Sophos; i="5.07,308,1413244800"; d="scan'208,217"; a="92855316" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP; 03 Nov 2014 15:11:17 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sA3FBGhZ031515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Nov 2014 15:11:16 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.61]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Mon, 3 Nov 2014 09:11:16 -0600 From: "Acee Lindem (acee)" To: "Shaun Cooley (shcooley)" , "draft-ietf-ospf-security-extension-manual-keying.all@tools.ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" Thread-Topic: secdir review of draft-ietf-ospf-security-extension-manual-keying-09 Thread-Index: Ac/yQ6iTuz66jDyPQS6Q8po+ZqsLRAAApYcwAU6i6wA= Date: Mon, 3 Nov 2014 15:11:15 +0000 Message-ID: References: <187A7B1DA239514F9146FC78B19AADE3502CD332@xmb-aln-x10.cisco.com> <187A7B1DA239514F9146FC78B19AADE3502CD38A@xmb-aln-x10.cisco.com> In-Reply-To: <187A7B1DA239514F9146FC78B19AADE3502CD38A@xmb-aln-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.204] Content-Type: multipart/alternative; boundary="_000_D07D0530747Faceeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Qu44hZFLjuCLxkYUQHeHWTbOolU Subject: Re: [secdir] secdir review of draft-ietf-ospf-security-extension-manual-keying-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 15:11:28 -0000 --_000_D07D0530747Faceeciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Shaun, Thanks for your review. Acee From: "Shaun Cooley (shcooley)" > Date: Monday, October 27, 2014 at 7:30 PM To: "draft-ietf-ospf-security-extension-manual-keying.all@tools.ietf.org" = >, "se= cdir@ietf.org" >, "iesg@ietf.org" > Subject: secdir review of draft-ietf-ospf-security-extension-manual-keying-= 09 Resent-From: > Resent-To: Acee Lindem >, Alia Atlas = >, >, >, Manav Bhatia >, > Resent-Date: Monday, October 27, 2014 at 7:30 PM I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These 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 addresses both inter-session and intra-session replay attacks= when using manual keying for OSPFv2 by changing the sequence numbers to be= 64-bit, with the most significant 32-bits being a boot count and the least= significant 32-bits to be an increasing sequence number. The document als= o changes the Apad constant to match the source address of the IP header in= order to extend authenticated data to prevent source address spoofing. The document was well written and I very much appreciated the redline style= approach to the draft. I consider this document ready for publication. -Shaun --_000_D07D0530747Faceeciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Shaun, 
Thanks for your review.
Acee 

From: "Shaun Cooley (shcooley)= " <shcooley@cisco.com>=
Date: Monday, October 27, 2014 at 7= :30 PM
To: "draft-ietf-os= pf-security-extension-manual-keying.all@tools.ietf.org" <draft-ietf-ospf-security-extension-manual-keying.all@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Subject: secdir review of draft-iet= f-ospf-security-extension-manual-keying-09
Resent-From: <draft-alias-bounces@tools.ietf.org&= gt;
Resent-To: Acee Lindem <acee@cisco.com>, Alia Atlas <akatlas@gmail.com>, <akr@cisco.com>, <hartmans@painless-security.com>, Manav Bhatia <manav@ionosnet= works.com>, <zhangdach= eng@huawei.com>
Resent-Date: Monday, October 27, 20= 14 at 7:30 PM

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

 

This document addresses both inter-session and intra= -session replay attacks when using manual keying for OSPFv2 by changing the= sequence numbers to be 64-bit, with the most significant 32-bits being a b= oot count and the least significant 32-bits to be an increasing sequence number.  The document also chang= es the Apad constant to match the source address of the IP header in order = to extend authenticated data to prevent source address spoofing.

 

The document was well written and I very much apprec= iated the redline style approach to the draft.

 

I consider this document ready for publication.=

 

-Shaun

 --_000_D07D0530747Faceeciscocom_-- From nobody Tue Nov 4 07:19: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 74E841A89A7; Tue, 4 Nov 2014 07:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.206 X-Spam-Level: X-Spam-Status: No, score=0.206 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.594] 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 q0zeHjfM7Uex; Tue, 4 Nov 2014 07:19:04 -0800 (PST) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by ietfa.amsl.com (Postfix) with ESMTP id BC9FC1A8978; Tue, 4 Nov 2014 07:19:04 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id B436646B2E; Tue, 4 Nov 2014 10:19:03 -0500 (EST) Received: from fledge.watson.org (weiler@localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.9/8.14.9) with ESMTP id sA4FJ37Q020925; Tue, 4 Nov 2014 10:19:03 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.9/8.14.9/Submit) with ESMTP id sA4FJ3db020922; Tue, 4 Nov 2014 10:19:03 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 4 Nov 2014 10:19:03 -0500 (EST) From: Samuel Weiler To: manav bhatia In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-704623269-1414953574=:21474" Content-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (fledge.watson.org [127.0.0.1]); Tue, 04 Nov 2014 10:19:03 -0500 (EST) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/3D4N5o14XY86H65d1f5Fs6PQcyc Cc: draft-ietf-karp-bfd-analysis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-karp-bfd-analysis-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: Tue, 04 Nov 2014 15:19:06 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-704623269-1414953574=:21474 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: [Background for secdir's benefit: Manav recently said he was waiting a reply from me, as secdir reviewer, and a routing AD asked if a ball had been dropped.] Keep in mind that secdir reviews are written for the benefit for of the security ADs. While secdir reviewers will sometimes spot glaring errors that we have completely confidence about, we often lack the expertise on a particular document to be 100% sure of the right answer, and we often don't have a vested interest in the outcome. Both of those are obvious results of choosing to randomly assign reviewers to documents, as secdir has done for years. Speaking for myself: when I'm uncertain or mildly skeptical about something in a doc, I prefer to flag it anyway, hoping that those with more expertise and vested interest will track it down, resulting in a better product. The review here contains two clear examples of the above uncertainty and, looking back now, I can pretty clearly see why I did not reply. First, of the four questions I raised, you responded to two with "Will remove this in -07" and "I agree. This should be mentioned.". Particularly without the text for the second, there's not much to say. Waiting for the -07 seems called for. The other two questions were about things I was skeptical about something but had not been following enough of the discussion to be absolutely sure about. I was hoping that people more swapped in on the details would discuss and explain. Having the discussion be solely between the doc editor and me, as the (potentially) non-expert secdir reviewer with (potentially) no vested interest in the document, seems less than ideal. But since that's what you seem to be waiting for, I will happily try: Again, for two of the items, there's nothing to respond to until I see the -07. In the other other two cases, I am not satisfied with the discussion to date. > Theoretically the two should use algorithms of similar strength. Why? (Explain your theory...) > In fact one could argue that BFD needs stronger algorithm since an > attack on BFD can bring down all your control protocols. Has the WG had that discussion? > Lastly, RFC5880 (the BFD spec) says: >    An attacker who is in complete control of the link between > the >    systems can easily drop all BFD packets but forward > everything else >    (causing the link to be falsely declared down), or forward > only the >    BFD packets but nothing else (causing the link to be falsely >    declared up).  This attack cannot be prevented by BFD. > > Given that, does it make sense to go to this pain to replace MD5 > and SHA1? > > > Sure, but such attacks are outside the scope of routing protocol > security. Do we have a solid definition of that scope? (Where?) And how vulnerable would BFD be to off-link attackers anyway? Are we doing all of this work solely to defend against on-link attackers who have only _incomplete_ control of the link? (It may well be a stupid question, but, if it is stupid, then it should at least have an easy answer, right?) -- Sam --621616949-704623269-1414953574=:21474-- From nobody Wed Nov 5 08:35: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 4B1161A89E0; Wed, 5 Nov 2014 08:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 FE2dJW_C5D9e; Wed, 5 Nov 2014 08:35:26 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8808F1A89A1; Wed, 5 Nov 2014 08:35:26 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id rd18so1063342iec.35 for ; Wed, 05 Nov 2014 08:35:25 -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=IXj97J1tcSva5+bba+fsFaf9EGlLDgU+rXy98Um5Z9U=; b=yFE0u6jP9ySK8F2awEa2+A6Tc26KsmHdx6gfFn+6jGPUzyOE9RBkqFH1Ou5jslvqt5 +6V6GmypuMKweC0kmCzAYXnd5/zn4IXX5qJkSXbGtOnqeGbKwOhrCYTz3cRATifROz0s rWAR8lS9tvnDAH5a1LQhgznpq7oxgv7AdZiSoxoMr9zUVp8EwShoUiqo76tfhl4llFsA Czd0qK2dGDh9+4lFQWjj7XiKTY0/HYuGNb1dpEpUDvFEhTMnwDfIQvSrESG9KuHFPbLk mn6wLbYNxeqwCVtDJ2zUg9d0wNEHXia8LsU54YFIRJzZ0w7XqfEIg+unoqyp8kaj3k7d QkcQ== MIME-Version: 1.0 X-Received: by 10.50.128.35 with SMTP id nl3mr6279128igb.34.1415205325724; Wed, 05 Nov 2014 08:35:25 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.173.29 with HTTP; Wed, 5 Nov 2014 08:35:25 -0800 (PST) In-Reply-To: References: Date: Wed, 5 Nov 2014 11:35:25 -0500 X-Google-Sender-Auth: 1D-jd8IgYZ1VYIddUO1PYHZg3Qo Message-ID: From: Barry Leiba To: Donald Eastlake Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/eXbrxl2_c3ve0yZkp59-_C8wN7s Cc: "secdir@ietf.org" , "iesg@ietf.org" , draft-leiba-cotton-iana-5226bis.all@tools.ietf.org Subject: Re: [secdir] SECDIR review of draft-leiba-cotton-iana-5226bis-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: Wed, 05 Nov 2014 16:35:28 -0000 Hi, Donald -- I'm sorry I didn't respond to this right away. > However, it is not clear to me that there is adequate defense against > denial of service attacks on IANA. ... > think Section 3.3 should clearly provide that IANA can go to the IESG > for anything that the IANA considers abuse of registration procedures. That seems like a reasonable addition; I will do that. > Given the completeness of this document in other regards, it seem odd > that it does not mention that there can be and are IANA registries > whose root is not the IETF but some other organization. This is about IANA Considerations sections in IETF documents. It's meant to tell you what to put in IANA Considerations sections, not to cover every nuance that might exist with registry creation. I'd prefer not to add those kinds of edge cases that rarely happen, and that we get through on an individual basis when they do. > In Section 2.3, we find > "In particular, when a registry policy that requires involvement of > Working Groups, directorates, or other bodies ..." > but in the IETF, Working Groups are transient entities. Registry > policy involvement of a WG not allowed and I have my doubts about > allowing "directorates". Use of a mailing list is OK because mailing > lists can be permanent. That text was a recent addition. Do you have a specific suggestion for alternative text that gets the same point across? The point is that even after a working group writes a restrictive policy, that very working group (still existing at the time) sometimes refuses to handle a registration because they think it's not work doing a standards-track RFC "just for this". It's not that the policy explicitly says that the WG has to do something... it's that because of the policy and the fact that the WG is still around, the WG (or the directorate or whatever) gets involved. > And, at the very end of Section 2.3, it seems to imply that > "Specification Required" implies "significant community involvement" > which I think is wrong. My understanding is that there needs to be an > expert to judge that the specification cited in the assignment request > is adequate for interoperability. That paragraph does not say what I meant it to say. It's possible that the parenthesized bit at the end is stray, but I'll have to go back to the earlier versions and see where that came from. It needs fixing; thanks for pointing it out. > Section 2.3.2: Talks about using multiple policies in a registry and > seems to imply the main reason for this would be different sources of > applications for assignment or just the general desirability in some > cases of having alternative policies. Completely missing here is any > reference to the many cases where disjoint ranges of code points are > given different registration policies but that is given in Section 4 > where there is no mention of different sources of applications. Also > note that for registries where the assignment of a block of values > makes sense, such as MAC addresses under the IANA OUI, it makes sense > to have different policies for assignment of small ranges or a single > value and more stringent policies for assignment of large ranges. This > stuff probably shouldn't be split between Sections 2.3.2 and 4. I don't see why it shouldn't: they're two entirely different use cases, and they're described separately because they are separate. > Although Section 4.7 makes it clear that any type of RFC can cause > assignments from a registry, I believe it is the case that any type of > RFC can, if appropriate, create an IANA Registry and it doesn't say > that in the draft unless I missed it... There's nothing in the document that limits what RFCs the document applies to. Do you really think it's necessary to say that explicitly? The reason 4.7 says what it says is to specifically differentiate "RFC Required" from "IETF Review" and "Standards Action", each of which require different types of RFCs. > Contrary to Section 9.1 of this draft, the draft does not have an IANA > Considerations Section. A fair point; I will add one. :-) > In Section 2.3.1, under item number 6, grouping is unclear. A reader > might not know if "significant" is supposed to modify "documentation" > or "expert review". I suggest changing the comma after "expert review" > to a semicolon or deleting the comma after "significant". I will change the comma after "expert review" to the word "with". > Since I'm sometimes a bit stubborn, Nahhhh... > I will make one last point on > which, as far as I can tell, no one agrees with me. My point is the > error is the "order of strictness" list. Expert Review and > Specification Required both involve an expert and both involve > documentation. While it is true that Specification Required requires > that the documentation be public, unless there are further provisions, > the "expert" involved in Specification Required is restricted from > making a judgment on anything but the completeness and lack of > ambiguity of the document. Yes, you and I have significant disagreement here. Expert Review does not necessary involve documentation (apart from the information required for the registration request). And Specification Required can have the designated expert consider whatever it wants to have the expert consider, according to the instructions given to the expert. In my view, Expert Review has the expert review the registration request, and Specification Required has the expert review the registration request *and* the specification. And this sort of disagreement is exactly why this document increases the emphasis on instructions to the expert, so each use of these policies makes it clear what they expect the expert to consider (and what not to consider). > I went to the www.iana.org/protocols page and was unable to find the > Fruit Parameters Registry or the Fruit Access Flags... Maybe the IANA > Considerations Section that should be in this draft shouldn't be empty > but should create that Registry for documentation purposes... He-he-he........ Thanks again for the thorough and thoughtful review. Barry From nobody Wed Nov 5 10:32: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 614DC1A9121; Wed, 5 Nov 2014 10:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 tLuQ7exOCrRM; Wed, 5 Nov 2014 10:32:09 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CFB11A9150; Wed, 5 Nov 2014 10:31:47 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id s18so1247410lam.13 for ; Wed, 05 Nov 2014 10:31:46 -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=GyWfzHJxjZCubRJ7bhC+mMAOSa9ZyAJbzeFmOJCM9bE=; b=rCJTn1ZiyzknruW8mNKhm+Q2LDS2mDiRh5DYvbtQNk1cwc2779rfOLCDRIobykPfqM eiktd1WUkj5isaCVxRHk5D/9VwLmBR6SPR5E3v/LplqgQv+8/Y1hNzKKJQSvJ9LnkTgd 4KkC06wCZepZG5vXFpmmwsiJC52qm0MvFeeS3IDlIsDTBGw+Bm0qzQuF/xZ0SB1GYMQv uWhtzys5Zd+1H8+7PTAdTfIPAPhF2vj97tObpbwN7EIaRsfkrkPLL277Zr/vjZDb7fcu VExifknLhrP9OKAx2DXfV1dNqaL0yXZG6CT8V0/RLJb0EZomd6QDz9XmCCYhCUGtAUF5 RwVA== MIME-Version: 1.0 X-Received: by 10.112.57.227 with SMTP id l3mr69490027lbq.68.1415212305981; Wed, 05 Nov 2014 10:31:45 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Wed, 5 Nov 2014 10:31:45 -0800 (PST) In-Reply-To: References: Date: Wed, 5 Nov 2014 13:31:45 -0500 X-Google-Sender-Auth: JIJrziixGPU5LRM4bPo8BBsBndY Message-ID: From: Barry Leiba To: Donald Eastlake Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/uGAmQLW-C_DRCpKBgRwWyp_jaSs Cc: "iesg@ietf.org" , "draft-leiba-cotton-iana-5226bis.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-leiba-cotton-iana-5226bis-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: Wed, 05 Nov 2014 18:32:10 -0000 Following up on a thing or two: >> However, it is not clear to me that there is adequate defense against >> denial of service attacks on IANA. > ... >> think Section 3.3 should clearly provide that IANA can go to the IESG >> for anything that the IANA considers abuse of registration procedures. > > That seems like a reasonable addition; I will do that. Here's what I added to the end of the section: NEW IANA always has the discretion to ask the IESG for advice or intervention when they feel it is needed, such as in cases where policies or procedures are unclear to them, where they encounter issues or questions they are unable to resolve, or where registration requests or patterns of requests appear to be unusual or abusive. >> In Section 2.3, we find >> "In particular, when a registry policy that requires involvement of >> Working Groups, directorates, or other bodies ..." >> but in the IETF, Working Groups are transient entities. Registry >> policy involvement of a WG not allowed and I have my doubts about >> allowing "directorates". Use of a mailing list is OK because mailing >> lists can be permanent. > > That text was a recent addition. Do you have a specific suggestion > for alternative text that gets the same point across? I thought about it a bit more. How about this?: OLD In particular, when a registry policy that requires involvement of Working Groups, directorates, or other bodies to be actively involved and to support the effort, requests frequently run into concerns that "it's not worth doing a Standards-Track RFC for something this trivial," when, in fact, that requirement was created by the Working Group in the first place, by placing the bar that high. NEW In particular, working groups will sometimes write in policies such as Standards Action when they develop documents. Later, someone will come to the working group (or to the relevant community, if the working group has since closed) with a simple request to register a new item, and will be met with a feeling that it's not worth doing a Standards-Track RFC for something so trivial. In such cases, it was a mistake for the working group to have set the bar that high. >> And, at the very end of Section 2.3, it seems to imply that >> "Specification Required" implies "significant community involvement" >> which I think is wrong. My understanding is that there needs to be an >> expert to judge that the specification cited in the assignment request >> is adequate for interoperability. > > That paragraph does not say what I meant it to say. It's possible > that the parenthesized bit at the end is stray, but I'll have to go > back to the earlier versions and see where that came from. It needs > fixing; thanks for pointing it out. There was a missing word, but I re-worded the stuff in parentheses a little more): OLD Therefore, Working Groups and other document developers should use care in selecting appropriate registration policies when their documents create registries. They should select the least strict policy that suits a registry's needs, and look for specific justification for policies that require significant community involvement (Specification Required, in terms of the well-known policies). NEW Therefore, working groups and other document developers should use care in selecting appropriate registration policies when their documents create registries. They should select the least strict policy that suits a registry's needs, and look for specific justification for policies that require significant community involvement (those stricter than Specification Required, in terms of the well-known policies). Barry From nobody Wed Nov 5 19:56: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 0EEA41A03A9; Wed, 5 Nov 2014 19:56:01 -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 FCpvY5FdAOlC; Wed, 5 Nov 2014 19:55:59 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995881A01F6; Wed, 5 Nov 2014 19:55:59 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id lf10so377191pab.19 for ; Wed, 05 Nov 2014 19:55:58 -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 :content-type; bh=3reotFch3xDET36wkj8bsx2oQwcx3cLt2Mk6tZUVZdA=; b=FkW8MvqY14Fr/l1fsy03InH3TbXfIFidS7pLpzSFW1CjHYPUHTJvVqX70ENMKufeQh 76W0JSo0DSoZm/7xKYHG0KIYNztQqMHn5CAJZAmDJIibh94QN/PrlgdW5DE4+2/0/es0 pykcqHvFAHI1MjWBFVwee7pdsXptXxlcDDLSMScyDAEagKtWCrVYmBX+xUVyxPxO3abL 4qJR4lvHCAX6dHnrPgqq4cYWQ4fgs/Y+M/82JWJe0yfoI8csd0QfAWEF0AQDl7zaAWH4 NZrLCP3UKF2JZ266djq1dmFSwx0utJomdJwUQHo+XVZck+IPIe5WiD5QmbGjBoOFqWie E6yw== X-Received: by 10.70.31.2 with SMTP id w2mr1676381pdh.128.1415246158722; Wed, 05 Nov 2014 19:55:58 -0800 (PST) Received: from [192.168.1.76] (172-3-137-150.lightspeed.sntcca.sbcglobal.net. [172.3.137.150]) by mx.google.com with ESMTPSA id lr4sm4530020pab.42.2014.11.05.19.55.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Nov 2014 19:55:57 -0800 (PST) Message-ID: <545AF14A.3080307@gmail.com> Date: Wed, 05 Nov 2014 19:55:54 -0800 From: Chris Lonvick User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-bmwg-bgp-basic-convergence.all@tools.ietf.org Content-Type: multipart/alternative; boundary="------------020608040505050902010709" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/qsnfpSN-Tc4pXri-K_0j736gOH4 Subject: [secdir] SECDIR review of ietf-bmwg-bgp-basic-convergence 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 Nov 2014 03:56:01 -0000 This is a multi-part message in MIME format. --------------020608040505050902010709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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. The Security Considerations section is a boilerplate used in all documents from this Working Group. I only scanned the document but it appears to be well written and ready for publication. Best regards, Chris --------------020608040505050902010709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
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.

The Security Considerations section is a boilerplate used in all documents from this Working Group.  

I only scanned the document but it appears to be well written and ready for publication.

Best regards,
Chris
--------------020608040505050902010709-- From nobody Thu Nov 6 14:13: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 9FACF1AC3A2 for ; Thu, 6 Nov 2014 14:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.715 X-Spam-Level: X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_NEUTRAL=0.779] 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 mRZE7FXyeijX for ; Thu, 6 Nov 2014 14:13:24 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4170B1AC39C for ; Thu, 6 Nov 2014 14:12:54 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sA6MCoia028909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 7 Nov 2014 00:12:50 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sA6MCn9T011828; Fri, 7 Nov 2014 00:12:49 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21595.62049.850102.421993@fireball.kivinen.iki.fi> Date: Fri, 7 Nov 2014 00:12:49 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/dfKeh7Q-MwL6r_PeM2YxpzKgwCc 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 Nov 2014 22:13:32 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Hilarie Orman is next in the rotation. For telechat 2014-11-25 Reviewer LC end Draft Alan DeKok T 2014-10-21 draft-ietf-tram-alpn-07 Dorothy Gellert T 2014-10-27 draft-ietf-manet-ibs-03 Alexey Melnikov T 2014-11-06 draft-ietf-opsawg-mibs-to-ieee80231-01 For telechat 2014-12-04 Sandy Murphy T 2014-11-25 draft-mcdonald-ipps-uri-scheme-15 Last calls and special requests: Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-07 Matt Lepinski 2014-11-18 draft-nottingham-safe-hint-05 Catherine Meadows 2014-11-10 draft-ietf-opsawg-capwap-hybridmac-06 Yoav Nir 2014-11-14 draft-ietf-radext-nai-10 Magnus Nystrom 2014-12-01 draft-josefsson-pkix-textual-07 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Hannes Tschofenig 2014-10-07 draft-ietf-lmap-use-cases-04 Sean Turner 2014-10-13 draft-ietf-mpls-lsp-ping-relay-reply-04 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-12 -- kivinen@iki.fi From nobody Sat Nov 8 02:18: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 8FE1B1A6F24 for ; Sat, 8 Nov 2014 02:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 q_sPPqGq-RTv for ; Sat, 8 Nov 2014 02:18:19 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02A91A6F11 for ; Sat, 8 Nov 2014 02:18:18 -0800 (PST) Received: from [192.168.1.200] (p508F0824.dip0.t-ipconnect.de [80.143.8.36]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 4AB751C0E9748; Sat, 8 Nov 2014 11:18:15 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <25AA1780-FCF9-498E-96A1-046C03D509BD@comcast.net> Date: Sat, 8 Nov 2014 11:18:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <50253F8B-C4E8-4F30-B3FB-B8DC12D630E8@fh-muenster.de> References: <25AA1780-FCF9-498E-96A1-046C03D509BD@comcast.net> To: David Harrington X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/QxXO7fmHENsvmxp7xmSb2TD0eWY Cc: draft-ietf-rtcweb-data-channel.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-rtcweb-data-channel 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, 08 Nov 2014 10:18:21 -0000 On 25 Oct 2014, at 00:11, David Harrington wrote: > Hi, >=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=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 > I think this document is not ready.=20 Hi David, thank you very much for your review. See my comments in-line. Best regards Michael >=20 > A few comments. > 1) This proposal stacks a number of protocols - SCTP/DTLS/ICE - with = which I am not intimately familiar. > I cannot tell whether using these in combination opens any holes. >=20 > 2) one of the use cases pertains to avoiding internet filtering and = monitoring of HTTP messages.=20 > =46rom a security perspective, I find this undesirable, but it is = probably a real world use case. >=20 > 3) This document has dependencies on 8 different internet drafts -=20 > features in [I-D.ietf-tsvwg-sctp-prpolicies] MUST be supported. > features in [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used. > [I-D.ietf-rtcweb-jsep] will establish the connection, > and so on =85 >=20 > It is hard to assess the security of the system when so many pieces = are yet to be =93fixed=94. Security is a process. > While this could be put through with downlinks, I think it important = to understand how those pieces fit with this document to create system, = before this part should be approved. >=20 > 4) section 6.2 specifies some sentences using =93will=94; I think to = make the standard unambiguous, these should be converted into RFC2119 = keywords. >=20 > 5) section 6.2 says "typically this will be shared via BUNDLE or = equivalent=94. Without knowing what will be used, it is difficult to = assess the security implications. >=20 > This is being submitted as standards-track, and I think the language = needs to be tightened up considerably to determine whether an = implementation is standard-compliant. Which of these options are = mandatory to implement for compliance, and which are optional? We tried to be as specific as possible. >=20 > 6) section 6.2 says "The number of streams negotiated during SCTP = association setup SHOULD > be 65535, which is the maximum number of streams that can be > negotiated during the association setup.=94 It is unclear to me = whether the following paragraphs explain why the maximum number of = streams should be negotiated. If so, then I think this should be made = clearer. If not, then I think a justification for negotiating the = maximum should be provided. No it doesn't. The justification is just to use the maximum number of = streams. The alternative would have been to start with some other number (which one?) = and use the extension RFC6525 to increase the number of streams, in case they = are needed. The WG decided that the process of increasing the number is too complex = compared to just negotiate the maximum number always. >=20 >=20 > 7) section 6.4 says =93A strong wish if for the application-level API = to be close to the > API for WebSockets ...=94; Can I assume that by =93close to=94 the = authors mean =93similar to=94? Based on comments the text has been changed to Data channels are defined such that their accompanying = application-level API can closely mirror the API for WebSockets, which implies bidirectional = streams of data and a textual field called 'label' used to identify the meaning = of the data channel. > I think the text in 6.4 needs to be tightened, using RFC2119 keywords. > =93each data channel has the following properties =85=94; I cannot = tell whether this is defining properties that must be implemented or is = a description of the properties that happen because this proposal uses = SCTP.=20 It defines the properties of a data channel. Some of them are related to = SCTP features. This is then described. Some of them (label and protocol) are not. I'm not sure if using RFC 2119 words would make this clearer. >=20 > 8) 6.5 saya "If it attempts to re-use a stream which is part of an = existing data channel, the addition SHOULD fail.=94 I have a concern = that this is not a MUST. Are there security implications if this is not = a MUST? This has been changed to a MUST. >=20 > 9) 6.6 again could use some RFC2119 keywords. I think the whole = section should be looked at for keywords, but have particular concern = about error handling and die limitations. If an implementer ignores the = SHOULD limit to 16KB, what impact both from an operational perspective = and a security perspective will this have? On the sender side: Sending a larger message on one data channel will = block the sending of messages on other data channels. The impact is limited to data = channels belonging to the same peer connection. On the receiver side: Larger messages are received. But a receiver has = to deal with this anyway... >=20 > 10) I don=92t think pointing to a generic rtcweb security document is = sufficient. The security considerations section in this document should = discuss the security implications of various implementation choices = specific to this document. There are a number of SHOULDs in this = document. What are the security implications of not applying the = SHOULD,? see my point #9, for example. Could this be exploited to create = a DOS attack?=20 A sender can always try to send a huge message to the receiver. But it = is up to the receiver to protect itself in some way. >=20 > Hope this helps, >=20 > David Harrington > ietfdbh@comcast.net >=20 >=20 >=20 From nobody Mon Nov 10 13:13: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 70C241ACD60 for ; Mon, 10 Nov 2014 13:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.143 X-Spam-Level: X-Spam-Status: No, score=-7.143 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] 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 qOFLGtOjLggt for ; Mon, 10 Nov 2014 13:13:04 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259AE1A1A2A for ; Mon, 10 Nov 2014 13:13:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,355,1413237600"; d="scan'208,217";a="106027596" Received: from ral033r.vpn.inria.fr ([128.93.178.33]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 10 Nov 2014 22:13:00 +0100 From: Vincent Roca Content-Type: multipart/alternative; boundary="Apple-Mail=_E8C6436B-2085-45A9-B4A7-DCF27BEE4829" Date: Mon, 10 Nov 2014 11:13:01 -1000 Message-Id: <38936223-5F53-4EC4-AA7B-15AF5F7F7AF6@inria.fr> To: secdir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/o3QIPozjrWK8GeW_wXRTzLoRE7Q Cc: ludovic.jacquin@hp.com Subject: [secdir] Topic for our SecDir lunch: The PTB-PTS ICMP-based Attack against IPsec Gateways 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 Nov 2014 21:13:08 -0000 --Apple-Mail=_E8C6436B-2085-45A9-B4A7-DCF27BEE4829 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi everybody, There=92s a subject I=92d like to discuss with you tomorrow during our = SecDir lunch if we have time for that. It=92s about a DoS on IPsec we have found with my previous PhD student, = Ludovic. It=92s described here: =AB Too Big or Too Small? The PTB-PTS ICMP-based Attack against = IPsec Gateways =BB, GLOBECOM=9214. PDF is freely available at: = https://hal.inria.fr/hal-01052994/en/ The study has limits since it only focusses on IPv4 and a single OS = (stable Squeeze Debian distribution). That being said, we have an exploit using default IPsec configuration, = either preventing end-hosts to open new TCP connections (when relying on PMTUd) or creating large initial = delay/performance penalties (when relying on PLPMTUd). And UDP connexions will be affected too=85 The only thing an attacker needs is to be on the IPsec tunnel path with = the ability to eavesdrop encrypted traffic and send back a forged packet (e.g., a non encrypted Wifi = network should be sufficient, I see many of them available at IETF ;-) So we=92d like to have your feedback in particular on the following two = points: - Is there an appropriate way to manage Path MTUs in presence of IPsec = tunnels when we are already at the minimum PMTU size? - Is there an appropriate way to make the end-host (in the =AB red =BB = protected LAN) and its IPsec gateway understand each other when we are already at the minimum PMTU? This is clearly a tricky situation that may not be well addressed today. = Is it described somewhere in an RFC so that implementers have clear guidelines? We didn=92t find anything, = but it does not mean there=92s nothing. And may the problem be extended to other tunneling technologies that = perform encapsulation? Your feedback is welcome. Thanks, Ludovic and Vincent -- Vincent Roca, PhD/HDR, Inria research institute, France http://privatics.inrialpes.fr/~roca= --Apple-Mail=_E8C6436B-2085-45A9-B4A7-DCF27BEE4829 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi everybody,

There=92s = a subject I=92d like to discuss with you tomorrow during our SecDir = lunch if we have time for that.
It=92s about a DoS on IPsec we = have found with my previous PhD student, Ludovic. It=92s described = here:

=AB Too Big or Too Small? = The PTB-PTS ICMP-based Attack against IPsec = Gateways =BB, GLOBECOM=9214.
PDF is freely available at: https://hal.inria.fr/hal-01= 052994/en/

The study has limits since = it only focusses on IPv4 and a single OS (stable Squeeze Debian = distribution).
That being said, we have an exploit using = default IPsec configuration, either preventing end-hosts to = open
new TCP connections (when relying on PMTUd) or creating = large initial delay/performance penalties
(when relying on = PLPMTUd). And UDP connexions will be affected too=85
The only = thing an attacker needs is to be on the IPsec tunnel path with the = ability to eavesdrop encrypted
traffic and send back a forged = packet (e.g., a non encrypted Wifi network should be sufficient, I see = many
of them available at IETF ;-)

So = we=92d like to have your feedback in particular on the following two = points:

- Is there an appropriate way to = manage Path MTUs in presence of IPsec tunnels when we are = already
at the minimum PMTU = size?

- Is there an appropriate way to = make the end-host (in the =AB red =BB protected LAN) and its = IPsec gateway
understand each other when we are already = at the minimum PMTU?

This is clearly a = tricky situation that may not be well addressed today. Is it described = somewhere in an RFC
so that implementers have clear = guidelines? We didn=92t find anything, but it does not mean there=92s = nothing.
And may the problem be extended to other tunneling = technologies that perform encapsulation?

Your = feedback is welcome.
Thanks,

  = Ludovic and Vincent

--
   Vincent Roca, PhD/HDR, Inria research = institute, France
   http://privatics.inrialpes.fr= /~roca
<= /body>= --Apple-Mail=_E8C6436B-2085-45A9-B4A7-DCF27BEE4829-- From nobody Mon Nov 10 13:33: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 A02D31A1BFE; Mon, 10 Nov 2014 13:32: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 mFxU31tS9wyL; Mon, 10 Nov 2014 13:32:57 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB6D1A3B9E; Mon, 10 Nov 2014 13:32:57 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id nt9so7066797obb.1 for ; Mon, 10 Nov 2014 13:32:56 -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=xQf6Yeh6Dkm4kCSnG7xmyN3QBEYyhOcMCGVbpa1Vtek=; b=z0fr43QgA+rqnsN5Zv1pGXVXPtU2PcxNVG43TXnYyfmeAJjl+A3bEm6r6Z39ftDdLW YyZT1o5nt6Mqdx6CfBv7Hir6F/FKOg9f/4I753IKlJ7cEkSfcZMkrQ/HpzUR0Y8Nl2BG BJVeWs6FQ62I6JC8k4hfCcqWFwOHH4UdEu9BA9gAFyV9X34yIhXhK5f1PNYCALG1x4Bd /Sq3Gwn46/XTSo4TudGlQ4DQXxqyygX4uveTiZQ7psnjCQ/Nu0+F2XgrhgxtnhOWGidR M6SAZpSG6+joE/W03XPXsgGdqlNRRvLKXTjAW8Eb4CbQmJVT4TNN720ZqweUUmQ+W5Iv Gb+A== X-Received: by 10.60.37.97 with SMTP id x1mr3950819oej.57.1415655176239; Mon, 10 Nov 2014 13:32:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.145.4 with HTTP; Mon, 10 Nov 2014 13:32:36 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Mon, 10 Nov 2014 16:32:36 -0500 Message-ID: To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/XAlE4MBjCRTv7lVddBS16DGm8LU Cc: "iesg@ietf.org" , "draft-leiba-cotton-iana-5226bis.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-leiba-cotton-iana-5226bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 21:32:59 -0000 Hi, Sorry for delay in response On Wed, Nov 5, 2014 at 11:35 AM, Barry Leiba wrote: > Hi, Donald -- I'm sorry I didn't respond to this right away. > >... > >> Given the completeness of this document in other regards, it seem odd >> that it does not mention that there can be and are IANA registries >> whose root is not the IETF but some other organization. > > This is about IANA Considerations sections in IETF documents. It's > meant to tell you what to put in IANA Considerations sections, not to > cover every nuance that might exist with registry creation. I'd > prefer not to add those kinds of edge cases that rarely happen, and > that we get through on an individual basis when they do. OK >> ... > >> Section 2.3.2: Talks about using multiple policies in a registry and >> seems to imply the main reason for this would be different sources of >> applications for assignment or just the general desirability in some >> cases of having alternative policies. Completely missing here is any >> reference to the many cases where disjoint ranges of code points are >> given different registration policies but that is given in Section 4 >> where there is no mention of different sources of applications. Also >> note that for registries where the assignment of a block of values >> makes sense, such as MAC addresses under the IANA OUI, it makes sense >> to have different policies for assignment of small ranges or a single >> value and more stringent policies for assignment of large ranges. This >> stuff probably shouldn't be split between Sections 2.3.2 and 4. > > I don't see why it shouldn't: they're two entirely different use > cases, and they're described separately because they are separate. > >> Although Section 4.7 makes it clear that any type of RFC can cause >> assignments from a registry, I believe it is the case that any type of >> RFC can, if appropriate, create an IANA Registry and it doesn't say >> that in the draft unless I missed it... > > There's nothing in the document that limits what RFCs the document > applies to. Do you really think it's necessary to say that > explicitly? > > The reason 4.7 says what it says is to specifically differentiate "RFC > Required" from "IETF Review" and "Standards Action", each of which > require different types of RFCs. It is a common false impression, despite plenty of counter examples, that only standards track (and maybe experiemental standard) RFCs can create registries and get code point assignments. I think it would be good to dispell that. >> Contrary to Section 9.1 of this draft, the draft does not have an IANA >> Considerations Section. > > A fair point; I will add one. :-) OK. >> In Section 2.3.1, under item number 6, grouping is unclear. A reader >> might not know if "significant" is supposed to modify "documentation" >> or "expert review". I suggest changing the comma after "expert review" >> to a semicolon or deleting the comma after "significant". > > I will change the comma after "expert review" to the word "with". OK. >> Since I'm sometimes a bit stubborn, > > Nahhhh... > >> I will make one last point on >> which, as far as I can tell, no one agrees with me. My point is the >> error is the "order of strictness" list. Expert Review and >> Specification Required both involve an expert and both involve >> documentation. While it is true that Specification Required requires >> that the documentation be public, unless there are further provisions, >> the "expert" involved in Specification Required is restricted from >> making a judgment on anything but the completeness and lack of >> ambiguity of the document. > > Yes, you and I have significant disagreement here. Expert Review does > not necessary involve documentation (apart from the information > required for the registration request). Sure. > And Specification Required can have the designated expert consider > whatever it wants to have the expert consider, according to the > instructions given to the expert. Specification Required implies an expert review of the documentation to determine if it is sufficient for interoperability. Once you start giving any additional instructions to the expert, it isn't Specification Required anymore, it is now something else that I think would be "Expert Review with Public Documentation Required" but I suppose you could call "Sepcification Required and Expert Review" or something. In any case, the strictness ordering of the IANA Considerations categories should be the correct ordering for their unadorned meaning, not their meaning as modified by arbitrary additional provisions making them stricter or less strict. The fact that you have to add special additional instructions to "Specification Required" to bring up it's difficulty to be equal to default "Expert Review" and the fact that you could add instructions to "Expert Review" directing the expert to only check if the docmentation is adequate for interoperatibility, thus brining its difficutly down below the level of Specification Required (since the docuentation would not have to be public) makes it pretty clear that just plain "Specification Required" is less strict than just plain "Expert Review". > In my view, Expert Review has the expert review the registration > request, and Specification Required has the expert review the > registration request *and* the specification. What about the "registration" does the expert review for Specification Required? What you say above isn't what the draft says. In any case, I think the biggest problem with the standard categories of IANA Consideration is the immense gap between First Come First Server and the next stricter rung. If you are going to destroy Specification Required by making it mean "Expert Review and Specifcation Required", you are making that huge gap even bigger and I request the addition of a new IANA Consideration category "Really Just Specification Required" to cut that gap back down again. If you go back to the history, it was quite clear: Expert Review was patterned after Jon Postel. You know, an expert who reviews things and uses their judgement. Specification Required was really much, much easier - no judgement involved, doesn't matter if you are grabbing the last code point, doesn't matter if your intended use is junk, ... as long as you publicly describe the use, you get the code point. That's it. The ordering was quite clear and, while you can argue that it is really a lattice with no strict ordering between Expert Review and Specification Required, in practice Expert Review was considered much stricter than the mere requirement to public a spec. Then people decided you needed an expert to see if the spec was really a spec. That's fine. But now you have decided that because there is an expert, instead of just deciding if the spec is a spec, suddently, out of thin air, the "Specification" expert gets to apply arbitrary judgement. I just don't see where that comes from, consider it a radical change to "Specifciation Required", and believe it makes the term "Specification Required" inaccurate and misleading. > And this sort of disagreement is exactly why this document increases > the emphasis on instructions to the expert, so each use of these > policies makes it clear what they expect the expert to consider (and > what not to consider). If there are any special instructions to an expert, then it is basically Expert Review, not Specification Required. And I'm not sure that lots of specufuc rules for an expert is always such a good idea. Something to convey the general desires for assignment policy is good but the expert should have the freedom to take into account the numbe of code points remaining, for example, which is rarely mentioned in instructions to experts that I have seen, or unanticipated contingencies that come up. >> I went to the www.iana.org/protocols page and was unable to find the >> Fruit Parameters Registry or the Fruit Access Flags... Maybe the IANA >> Considerations Section that should be in this draft shouldn't be empty >> but should create that Registry for documentation purposes... > > He-he-he........ > > Thanks again for the thorough and thoughtful review. You're welcome and see further below. > Barry On Wed, Nov 5, 2014 at 1:31 PM, Barry Leiba wrote: > Following up on a thing or two: > >>> However, it is not clear to me that there is adequate defense against >>> denial of service attacks on IANA. >> ... >>> think Section 3.3 should clearly provide that IANA can go to the IESG >>> for anything that the IANA considers abuse of registration procedures. >> >> That seems like a reasonable addition; I will do that. > > Here's what I added to the end of the section: > > NEW > IANA always has the discretion to ask the IESG for advice or > intervention when they feel it is needed, such as in cases where > policies or procedures are unclear to them, where they encounter > issues or questions they are unable to resolve, or where registration > requests or patterns of requests appear to be unusual or abusive. That looks great. >>> In Section 2.3, we find >>> "In particular, when a registry policy that requires involvement of >>> Working Groups, directorates, or other bodies ..." >>> but in the IETF, Working Groups are transient entities. Registry >>> policy involvement of a WG not allowed and I have my doubts about >>> allowing "directorates". Use of a mailing list is OK because mailing >>> lists can be permanent. >> >> That text was a recent addition. Do you have a specific suggestion >> for alternative text that gets the same point across? > > I thought about it a bit more. How about this?: > > OLD > In particular, when a registry policy that requires involvement of > Working Groups, directorates, or other bodies to be actively involved > and to support the effort, requests frequently run into concerns that > "it's not worth doing a Standards-Track RFC for something this > trivial," when, in fact, that requirement was created by the Working > Group in the first place, by placing the bar that high. > > NEW > In particular, working groups will sometimes write in policies such > as Standards Action when they develop documents. Later, someone > will come to the working group (or to the relevant community, if the > working group has since closed) with a simple request to register a > new item, and will be met with a feeling that it's not worth doing a > Standards-Track RFC for something so trivial. In such cases, it was > a mistake for the working group to have set the bar that high. I agree that errors in the direction of overly stringent requirements are much more common than errors in the other direction. But this isn't an exact science, conditions can change, etc. Anyway I agree with Brian Carpenter that not all Standards Action IANA Considerations are a "mistake"... >>> And, at the very end of Section 2.3, it seems to imply that >>> "Specification Required" implies "significant community involvement" >>> which I think is wrong. My understanding is that there needs to be an >>> expert to judge that the specification cited in the assignment request >>> is adequate for interoperability. >> >> That paragraph does not say what I meant it to say. It's possible >> that the parenthesized bit at the end is stray, but I'll have to go >> back to the earlier versions and see where that came from. It needs >> fixing; thanks for pointing it out. > > There was a missing word, but I re-worded the stuff in parentheses a > little more): > > OLD > Therefore, Working Groups and other document developers should use > care in selecting appropriate registration policies when their > documents create registries. They should select the least strict > policy that suits a registry's needs, and look for specific > justification for policies that require significant community > involvement (Specification Required, in terms of the well-known > policies). > > NEW > Therefore, working groups and other document developers should use > care in selecting appropriate registration policies when their > documents create registries. They should select the least strict > policy that suits a registry's needs, and look for specific > justification for policies that require significant community > involvement (those stricter than Specification Required, in terms of > the well-known policies). OK, that sounds good except, of course, it should say "stricter than Expert Review". > Barry Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Mon Nov 10 15:20: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 0B54A1ACFFD for ; Mon, 10 Nov 2014 15:20:37 -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 63tGlMdF8ZcL for ; Mon, 10 Nov 2014 15:20:28 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E291D1ACFF8 for ; Mon, 10 Nov 2014 15:20:22 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id d1so16175wiv.1 for ; Mon, 10 Nov 2014 15:20:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=lIWqDHJfDr+pplfM+HpeII/WSx3qbVpvCQxkq6blCDs=; b=OnmcM4ldZT5HEWnZIwhMyGgdS9T94sv8CgfETqz3osFLmTXo0N15aQNhitwF0uW250 yQiXrKtiQoFfPZYfOO5UlVmJ1bVP9P8yHWhnXWaEXguzZ3QJbvckf7G2c6TbXlQNS0dv 8FRfUAfCo+L5OeXli/sgtx5xznk84dVAiAhH4zkPA6OmHdFcGJiv3pv/3lL9Q+Azs8ta 4h3RGoZ68o6DBvLlsYt+4GQCIFqe4oiTnYqGO/ra5pgF+KMdgxyI+gPJ4zfhXKhsxFoS dAL+8xI6XmDG9QtRzxa0JYgwBYwxX3WmAaw1o4gsUSBam3uhHSf/jAKGRqpX4IzjV/hI m0zg== X-Received: by 10.194.48.82 with SMTP id j18mr37245986wjn.107.1415661621688; Mon, 10 Nov 2014 15:20:21 -0800 (PST) Received: from t2001067c037001600cf03b83a58d8bd7.wireless.v6.meeting.ietf.org ([2001:67c:370:160:cf0:3b83:a58d:8bd7]) by mx.google.com with ESMTPSA id ex2sm15165265wib.19.2014.11.10.15.20.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 15:20:21 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_DD73F084-7D80-4CB1-8ADF-B4340D007292" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: <38936223-5F53-4EC4-AA7B-15AF5F7F7AF6@inria.fr> Date: Mon, 10 Nov 2014 13:20:15 -1000 Message-Id: <85C3C2D1-7185-48CD-91A9-5D89B75101BF@gmail.com> References: <38936223-5F53-4EC4-AA7B-15AF5F7F7AF6@inria.fr> To: Vincent Roca X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Ge8gpLtoV-BtMHEmENvicEaaV9M Cc: ludovic.jacquin@hp.com, secdir@ietf.org Subject: Re: [secdir] Topic for our SecDir lunch: The PTB-PTS ICMP-based Attack against IPsec Gateways 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 Nov 2014 23:20:38 -0000 --Apple-Mail=_DD73F084-7D80-4CB1-8ADF-B4340D007292 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Vincent. Not at all opposed to bringing this up at SecDir lunch, but wouldn=92t = the IPsecME working group session and the ipsec mailing list be the more = appropriate venue? The SecDir is made up of people with (hopefully) enough knowledge about = security to review an arbitrary draft and check that security has been = considered and appropriate considerations documented.=20 The attack described in that paper is not even specifically related to = IPsec. It could plague any tunneling mechanism such as L2TP, GRE, PPTP, = IP-in-IP. Although this is an attack, it might be appropriate for the = transport area. Yoav > On Nov 10, 2014, at 11:13 AM, Vincent Roca = wrote: >=20 > Hi everybody, >=20 > There=92s a subject I=92d like to discuss with you tomorrow during our = SecDir lunch if we have time for that. > It=92s about a DoS on IPsec we have found with my previous PhD = student, Ludovic. It=92s described here: >=20 > =AB Too Big or Too Small? The PTB-PTS ICMP-based Attack against = IPsec Gateways =BB, GLOBECOM=9214. > PDF is freely available at: = https://hal.inria.fr/hal-01052994/en/ = >=20 > The study has limits since it only focusses on IPv4 and a single OS = (stable Squeeze Debian distribution). > That being said, we have an exploit using default IPsec configuration, = either preventing end-hosts to open > new TCP connections (when relying on PMTUd) or creating large initial = delay/performance penalties > (when relying on PLPMTUd). And UDP connexions will be affected too=85 > The only thing an attacker needs is to be on the IPsec tunnel path = with the ability to eavesdrop encrypted > traffic and send back a forged packet (e.g., a non encrypted Wifi = network should be sufficient, I see many > of them available at IETF ;-) >=20 > So we=92d like to have your feedback in particular on the following = two points: >=20 > - Is there an appropriate way to manage Path MTUs in presence of IPsec = tunnels when we are already > at the minimum PMTU size? >=20 > - Is there an appropriate way to make the end-host (in the =AB red =BB = protected LAN) and its IPsec gateway > understand each other when we are already at the minimum PMTU? >=20 > This is clearly a tricky situation that may not be well addressed = today. Is it described somewhere in an RFC > so that implementers have clear guidelines? We didn=92t find anything, = but it does not mean there=92s nothing. > And may the problem be extended to other tunneling technologies that = perform encapsulation? >=20 > Your feedback is welcome. > Thanks, >=20 > Ludovic and Vincent >=20 > -- > Vincent Roca, PhD/HDR, Inria research institute, France > http://privatics.inrialpes.fr/~roca = _____________________________________= __________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --Apple-Mail=_DD73F084-7D80-4CB1-8ADF-B4340D007292 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi, Vincent.

Not at all opposed to bringing this up at SecDir lunch, but = wouldn=92t the IPsecME working group session and the ipsec mailing list = be the more appropriate venue?

The SecDir is made up of people with = (hopefully) enough knowledge about security to review an arbitrary draft = and check that security has been considered and appropriate = considerations documented. 

The attack described in that paper is = not even specifically related to IPsec. It could plague any tunneling = mechanism such as L2TP, GRE, PPTP, IP-in-IP. Although this is an attack, = it might be appropriate for the transport area.

Yoav

On = Nov 10, 2014, at 11:13 AM, Vincent Roca <vincent.roca@inria.fr> wrote:

Hi everybody,

There=92s a subject I=92d like to discuss with you tomorrow = during our SecDir lunch if we have time for that.
It=92s about a DoS on IPsec we have found with my previous = PhD student, Ludovic. It=92s described here:

= =AB Too Big or Too Small? The PTB-PTS = ICMP-based Attack against IPsec Gateways =BB, = GLOBECOM=9214.
PDF is freely available at: https://hal.inria.fr/hal-01052994/en/

The = study has limits since it only focusses on IPv4 and a single OS (stable = Squeeze Debian distribution).
That being said, we = have an exploit using default IPsec configuration, either preventing = end-hosts to open
new TCP connections (when relying = on PMTUd) or creating large initial delay/performance = penalties
(when relying on PLPMTUd). And UDP = connexions will be affected too=85
The only thing = an attacker needs is to be on the IPsec tunnel path with the ability to = eavesdrop encrypted
traffic and send back a forged = packet (e.g., a non encrypted Wifi network should be sufficient, I see = many
of them available at IETF ;-)

So we=92d like to have = your feedback in particular on the following two points:

- Is there = an appropriate way to manage Path MTUs in presence of IPsec tunnels when = we are already
at the minimum PMTU size?

- Is there an appropriate = way to make the end-host (in the =AB red =BB protected LAN) = and its IPsec gateway
understand = each other when we are already at the minimum PMTU?

This is clearly a tricky = situation that may not be well addressed today. Is it described = somewhere in an RFC
so that implementers have clear = guidelines? We didn=92t find anything, but it does not mean there=92s = nothing.
And may the problem be extended to other = tunneling technologies that perform encapsulation?

Your feedback is = welcome.
Thanks,

  Ludovic and Vincent

--
   Vincent = Roca, PhD/HDR, Inria research institute, France
   http://privatics.inrialpes.fr/~roca
_____________________________= __________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: = http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

= --Apple-Mail=_DD73F084-7D80-4CB1-8ADF-B4340D007292-- From nobody Mon Nov 10 15:40: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 D09891AD087 for ; Mon, 10 Nov 2014 15:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.143 X-Spam-Level: X-Spam-Status: No, score=-7.143 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] 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 D4SZP9w2blER for ; Mon, 10 Nov 2014 15:40:26 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A8FF1AD084 for ; Mon, 10 Nov 2014 15:40:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,355,1413237600"; d="scan'208,217";a="106040898" Received: from ral033r.vpn.inria.fr ([128.93.178.33]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 11 Nov 2014 00:40:06 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_9526ACEC-DC42-4691-9081-38EE78475CDB" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Vincent Roca In-Reply-To: <85C3C2D1-7185-48CD-91A9-5D89B75101BF@gmail.com> Date: Mon, 10 Nov 2014 13:40:06 -1000 Message-Id: <428B3579-AB82-49D3-A854-293ECBA8FEDD@inria.fr> References: <38936223-5F53-4EC4-AA7B-15AF5F7F7AF6@inria.fr> <85C3C2D1-7185-48CD-91A9-5D89B75101BF@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Ljui6cEjz4psdVSlz457XPDRlCo Cc: ludovic.jacquin@hp.com, secdir@ietf.org Subject: Re: [secdir] Topic for our SecDir lunch: The PTB-PTS ICMP-based Attack against IPsec Gateways 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 Nov 2014 23:40:30 -0000 --Apple-Mail=_9526ACEC-DC42-4691-9081-38EE78475CDB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks Yoav. Yes, having this discussion on IPsec related mailing lists = is needed, but I think SecDir can also be appropriate if the problem applies to other tunneling = techniques as well (which we didn=92t test). Honestly speaking, I=92m trying to figure out how to proceed the best = and advices like yours are welcome. Cheers, Vincent Le 10 nov. 2014 =E0 13:20, Yoav Nir a =E9crit : > Hi, Vincent. >=20 > Not at all opposed to bringing this up at SecDir lunch, but wouldn=92t = the IPsecME working group session and the ipsec mailing list be the more = appropriate venue? >=20 > The SecDir is made up of people with (hopefully) enough knowledge = about security to review an arbitrary draft and check that security has = been considered and appropriate considerations documented.=20 >=20 > The attack described in that paper is not even specifically related to = IPsec. It could plague any tunneling mechanism such as L2TP, GRE, PPTP, = IP-in-IP. Although this is an attack, it might be appropriate for the = transport area. >=20 > Yoav >=20 >> On Nov 10, 2014, at 11:13 AM, Vincent Roca = wrote: >>=20 >> Hi everybody, >>=20 >> There=92s a subject I=92d like to discuss with you tomorrow during = our SecDir lunch if we have time for that. >> It=92s about a DoS on IPsec we have found with my previous PhD = student, Ludovic. It=92s described here: >>=20 >> =AB Too Big or Too Small? The PTB-PTS ICMP-based Attack against = IPsec Gateways =BB, GLOBECOM=9214. >> PDF is freely available at: = https://hal.inria.fr/hal-01052994/en/ >>=20 >> The study has limits since it only focusses on IPv4 and a single OS = (stable Squeeze Debian distribution). >> That being said, we have an exploit using default IPsec = configuration, either preventing end-hosts to open >> new TCP connections (when relying on PMTUd) or creating large initial = delay/performance penalties >> (when relying on PLPMTUd). And UDP connexions will be affected too=85 >> The only thing an attacker needs is to be on the IPsec tunnel path = with the ability to eavesdrop encrypted >> traffic and send back a forged packet (e.g., a non encrypted Wifi = network should be sufficient, I see many >> of them available at IETF ;-) >>=20 >> So we=92d like to have your feedback in particular on the following = two points: >>=20 >> - Is there an appropriate way to manage Path MTUs in presence of = IPsec tunnels when we are already >> at the minimum PMTU size? >>=20 >> - Is there an appropriate way to make the end-host (in the =AB red =BB = protected LAN) and its IPsec gateway >> understand each other when we are already at the minimum PMTU? >>=20 >> This is clearly a tricky situation that may not be well addressed = today. Is it described somewhere in an RFC >> so that implementers have clear guidelines? We didn=92t find = anything, but it does not mean there=92s nothing. >> And may the problem be extended to other tunneling technologies that = perform encapsulation? >>=20 >> Your feedback is welcome. >> Thanks, >>=20 >> Ludovic and Vincent >>=20 >> -- >> Vincent Roca, PhD/HDR, Inria research institute, France >> http://privatics.inrialpes.fr/~roca >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >=20 --Apple-Mail=_9526ACEC-DC42-4691-9081-38EE78475CDB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Thanks = Yoav. Yes, having this discussion on IPsec related mailing lists is = needed, but I think SecDir
can also be appropriate if the problem = applies to other tunneling techniques as well (which we didn=92t = test).
Honestly speaking, I=92m trying to figure out how to = proceed the best and advices like yours are = welcome.
Cheers,

  = Vincent

Le 10 nov. 2014 =E0 = 13:20, Yoav Nir <ynir.ietf@gmail.com> a =E9crit = :
Hi, Vincent.

Not at all opposed to bringing this up = at SecDir lunch, but wouldn=92t the IPsecME working group session and = the ipsec mailing list be the more appropriate venue?

The SecDir is made up of = people with (hopefully) enough knowledge about security to review an = arbitrary draft and check that security has been considered and = appropriate considerations documented. 

The attack described in that paper is = not even specifically related to IPsec. It could plague any tunneling = mechanism such as L2TP, GRE, PPTP, IP-in-IP. Although this is an attack, = it might be appropriate for the transport area.

Yoav

On = Nov 10, 2014, at 11:13 AM, Vincent Roca <vincent.roca@inria.fr> wrote:

Hi everybody,

There=92s a subject I=92d like to discuss with you tomorrow = during our SecDir lunch if we have time for that.
It=92s about a DoS on IPsec we have found with my previous = PhD student, Ludovic. It=92s described here:

= =AB Too Big or Too Small? The PTB-PTS = ICMP-based Attack against IPsec Gateways =BB, = GLOBECOM=9214.
PDF is freely available at: https://hal.inria.fr/hal-01052994/en/

The = study has limits since it only focusses on IPv4 and a single OS (stable = Squeeze Debian distribution).
That being said, we = have an exploit using default IPsec configuration, either preventing = end-hosts to open
new TCP connections (when relying = on PMTUd) or creating large initial delay/performance = penalties
(when relying on PLPMTUd). And UDP = connexions will be affected too=85
The only thing = an attacker needs is to be on the IPsec tunnel path with the ability to = eavesdrop encrypted
traffic and send back a forged = packet (e.g., a non encrypted Wifi network should be sufficient, I see = many
of them available at IETF ;-)

So we=92d like to have = your feedback in particular on the following two points:

- Is there = an appropriate way to manage Path MTUs in presence of IPsec tunnels when = we are already
at the minimum PMTU size?

- Is there an appropriate = way to make the end-host (in the =AB red =BB protected LAN) = and its IPsec gateway
understand = each other when we are already at the minimum PMTU?

This is clearly a tricky = situation that may not be well addressed today. Is it described = somewhere in an RFC
so that implementers have clear = guidelines? We didn=92t find anything, but it does not mean there=92s = nothing.
And may the problem be extended to other = tunneling technologies that perform encapsulation?

Your feedback is = welcome.
Thanks,

  Ludovic and Vincent

--
   Vincent = Roca, PhD/HDR, Inria research institute, France
   http://privatics.inrialpes.fr/~roca
_____________________________= __________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org= /mailman/listinfo/secdir
wiki: = http://tools.ietf.org/area/sec/trac/wiki/SecDirReview


= --Apple-Mail=_9526ACEC-DC42-4691-9081-38EE78475CDB-- From nobody Mon Nov 10 18:58:07 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 890791A887C; Mon, 10 Nov 2014 18:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 SpLlIgmYyTuS; Mon, 10 Nov 2014 18:58:00 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1D71AD4C8; Mon, 10 Nov 2014 18:58:00 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id gm9so8661347lab.5 for ; Mon, 10 Nov 2014 18:57:58 -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:content-transfer-encoding; bh=RNJ48VQdNZ44fi4ZomFM5HV/0T8OzaUPXg7WBIgBiIM=; b=T+gD/8+qW0QcGtYVClNwOtQW35L68wXOywPfyM4AwW+P5R7buKK5lLNJKxs+7AsZg6 l6oeU8JzXqEm9Q/qLgqawBzciWI87xpDEFjDsh2UDqYBK2oCaXBcDNRRiisPYLgragMZ 7cenBhmxQBQVpRMt4DqIQBvlin3T2Gbas45JC4jp5nq/U/iA+stu4nXBtIymK7wWULQe 04Aihl2BTU+bAAV083ORH54Cwn34ogzPwXdpaNnuuCg3gE6u985rfKw7Zmm/rs42biPG BDaKVe08cdSQRUho+eVS3nrnOFx9MVQkcu28M+GPFMxtUA9GMOZj9+bkgIUUqi/fDQik nrkQ== MIME-Version: 1.0 X-Received: by 10.112.199.40 with SMTP id jh8mr33765221lbc.5.1415674678354; Mon, 10 Nov 2014 18:57:58 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.163.227 with HTTP; Mon, 10 Nov 2014 18:57:58 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Nov 2014 16:57:58 -1000 X-Google-Sender-Auth: DoeRlXwQMCsQdHAo1rUUU5cs6Dw Message-ID: From: Barry Leiba To: Donald Eastlake Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/9IvH-IhzGTWDnhseZMDi3JSVnoE Cc: "secdir@ietf.org" , "iesg@ietf.org" , "draft-leiba-cotton-iana-5226bis.all@tools.ietf.org" Subject: Re: [secdir] SECDIR review of draft-leiba-cotton-iana-5226bis-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: Tue, 11 Nov 2014 02:58:01 -0000 > Sorry for delay in response 's OK. Delays =F1 Us. I think the only thing we're still stuck on is the Specification Required vs Expert Review thing. I've had a chat with Thomas and Harald. I have this to propose, so let me know, ASAP, what you think: -- Section 2.3 -- OLD Therefore, working groups and other document developers should use care in selecting appropriate registration policies when their documents create registries. They should select the least strict policy that suits a registry's needs, and look for specific justification for policies that require significant community involvement (those stricter than Specification Required, in terms of the well-known policies). NEW Therefore, working groups and other document developers should use care in selecting appropriate registration policies when their documents create registries. They should select the least strict policy that suits a registry's needs, and look for specific justification for policies that require significant community involvement (those stricter than Expert Review or Specification Required, in terms of the well-known policies). END -- Section 2.3.1 -- OLD The well-known policies from "First Come First Served" to "Standards Action" specify a range of policies in increasing order of strictness (using the numbering from the full list in Section 4): 4. First Come First Served No review, minimal documentation. 5. Expert Review Expert review with sufficient documentation for review. 6. Specification Required Expert review with significant, stable public documentation. NEW The well-known policies from "First Come First Served" to "Standards Action" specify a range of policies in increasing order of strictness (using the numbering from the full list in Section 4): 4. First Come First Served No review, minimal documentation. 5/6. Expert Review / Specification Required Expert review with sufficient documentation for review. / Expert review with significant, stable public documentation. END OLD The description in Section 4.10 of "IESG Approval" suggests that the IESG "can (and should) reject a request if another path for registration is available that is more appropriate and there is no compelling reason not to use that path." The IESG should give similar consideration to any registration policy more stringent than Specification Required, asking for justification and ensuring that more relaxed policies have been considered, and the strict policy is the right one. NEW The description in Section 4.10 of "IESG Approval" suggests that the IESG "can (and should) reject a request if another path for registration is available that is more appropriate and there is no compelling reason not to use that path." The IESG should give similar consideration to any registration policy more stringent than Expert Review or Specification Required, asking for justification and ensuring that more relaxed policies have been considered, and the strict policy is the right one. END That makes the two policies of equal or unspecified strictness order. WFY? Barry From nobody Mon Nov 10 20:19: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 52C901AD3CA; Mon, 10 Nov 2014 20:19:32 -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 uhYGqgG9iLKN; Mon, 10 Nov 2014 20:19:30 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95D3F1AD3A4; Mon, 10 Nov 2014 20:19:30 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id va2so6844785obc.14 for ; Mon, 10 Nov 2014 20:19:29 -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:content-transfer-encoding; bh=jZzhUzdj9D6kVYDb5osN0A2L7F1ZCL7LmCXHMGJuQw8=; b=dBeTXUUSBKfiLflK6iiSmeEguyx8ARsBcHjeE6CS+AXko88o76PeJ8LBZ+2Rs52vi6 u+OvNSJlm1f+edsU+H7f96o020WkpgGUXK1mu8K7mZzRxB7t2UFXFwmrJQ+ChpfdafXQ 7jdfmhHDJ3DSNiM4yYExx7hFHwYOMZrxhw/Wq75rIxhui5bcMdPcnP1Fg4gZYM6Ag1ij hLxRKPGCOy33IW3OxWRWEpLbTBLYYE4xfjP/Cst5sFsDv2I9yYh4gHFOykZTCvW3DZYj DFKc64jnw4b0kmrIYmFLALSp/WFz0LZ8JYIqeuEfQCUjY+wUrDRu9RsfhunlGsHw0zfB XyFg== X-Received: by 10.60.155.34 with SMTP id vt2mr30489520oeb.34.1415679569822; Mon, 10 Nov 2014 20:19:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.145.4 with HTTP; Mon, 10 Nov 2014 20:19:09 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Mon, 10 Nov 2014 23:19:09 -0500 Message-ID: To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/vqLL0P_Rgt5r3Y3vEYN0k4x8Lec Cc: "secdir@ietf.org" , "iesg@ietf.org" , "draft-leiba-cotton-iana-5226bis.all@tools.ietf.org" Subject: Re: [secdir] SECDIR review of draft-leiba-cotton-iana-5226bis-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: Tue, 11 Nov 2014 04:19:32 -0000 Hi Barry, On Mon, Nov 10, 2014 at 9:57 PM, Barry Leiba wrot= e: >> Sorry for delay in response > > 's OK. Delays =D0=AF Us. > > I think the only thing we're still stuck on is the Specification > Required vs Expert Review thing. I've had a chat with Thomas and > Harald. I have this to propose, so let me know, ASAP, what you think: > > -- Section 2.3 -- > > OLD > Therefore, working groups and other document developers should use > care in selecting appropriate registration policies when their > documents create registries. They should select the least strict > policy that suits a registry's needs, and look for specific > justification for policies that require significant community > involvement (those stricter than Specification Required, in terms of > the well-known policies). > NEW > Therefore, working groups and other document developers should use > care in selecting appropriate registration policies when their > documents create registries. They should select the least strict > policy that suits a registry's needs, and look for specific > justification for policies that require significant community > involvement (those stricter than Expert Review or Specification > Required, in terms of the well-known policies). > END That's fine. > -- Section 2.3.1 -- > > OLD > The well-known policies from "First Come First Served" to "Standards > Action" specify a range of policies in increasing order of strictness > (using the numbering from the full list in Section 4): > > 4. First Come First Served > No review, minimal documentation. > > 5. Expert Review > Expert review with sufficient documentation for review. > > 6. Specification Required > Expert review with significant, stable public documentation. > NEW > The well-known policies from "First Come First Served" to "Standards > Action" specify a range of policies in increasing order of strictness > (using the numbering from the full list in Section 4): > > 4. First Come First Served > No review, minimal documentation. > > 5/6. Expert Review / Specification Required > Expert review with sufficient documentation for review. / > Expert review with significant, stable public documentation. > END > > OLD > The description in Section 4.10 of "IESG Approval" suggests that the > IESG "can (and should) reject a request if another path for > registration is available that is more appropriate and there is no > compelling reason not to use that path." The IESG should give > similar consideration to any registration policy more stringent than > Specification Required, asking for justification and ensuring that > more relaxed policies have been considered, and the strict policy is > the right one. > NEW > The description in Section 4.10 of "IESG Approval" suggests that the > IESG "can (and should) reject a request if another path for > registration is available that is more appropriate and there is no > compelling reason not to use that path." The IESG should give > similar consideration to any registration policy more stringent than > Expert Review or Specification Required, asking for justification > and ensuring that more relaxed policies have been considered, and > the strict policy is the right one. > END > > That makes the two policies of equal or unspecified strictness order. > > WFY? I'm OK with an unspecified strictness order. But I think "Expert review with significant, stable public documentation." is highly misleading. In the absence of express additional criterion, Specification Required constrains the expert to only judging whether or not the documentation is sufficient. It should say "Significant stable public documentation sufficient for interoperability." or something like that. For the Specification Required case, the expert has a very limited remit and should be invisible to applicants. They either get back a code point or a statement that their specification was insufficient and needs more detail (or, I suppose, a statement that the code points are exhausted). I've also thought some more about this, trying to figure out why we are at such complete disagreement. Don't know that I came to any conclusion. Have you ever been in the position of seeking a code point assignment when you believed the relevant expert was both unconstrained by any specific guidelines and actively hostile to your effort? I have and I can tell you I would have loved for the criterion to be a simple Specification Required. So this may color my thinking. One possibility is that IESG members have the significant burden of having to appoint experts and somehow that makes all experts vaguely equivalent in the eyes of the IESG. So somehow you don't think that an expert authorized to use any reasonable judgement (by an unqualified "Expert Review" IANA Considerations, for example) is much different from an expert that is only authorized to determine if documentation is sufficient for interoperation (i.e., Specification Required) and think of them as about the same, even though I think it is like night and day. Another possibility is that these days most Specification Required IANA Considerations have additional instructions requiring experts to make judgements on matters other than whether the documentation is sufficient for interoperability. (In my opinion, since I think the ability of the Expert to apply reasonable judgement is the most important characteristic, that makes them really Expert Review.) Really, there are lots of unqualified Expert Review IANA Considerations. For example, look at www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml almost all the registries on that page are Expert Review with no additional guidance of which I am aware. > Barry Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Mon Nov 10 20:28: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 D67671A88C0; Mon, 10 Nov 2014 20:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 cnMjZhu3HGoc; Mon, 10 Nov 2014 20:28:47 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3971A88F0; Mon, 10 Nov 2014 20:28:46 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id pn19so8914468lab.32 for ; Mon, 10 Nov 2014 20:28:44 -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=noUf3TnbBvkxl7lbPTHRLP/v146AiPRqzyadUinLNd4=; b=X5l1Iw7asw4n120Ogfg3Lg7QQBGPUA+P1OjFishVKi2x1F0DSErXNivC5hkN//wL+4 TgabH4BCjFsrZg/ja1W+Y0JDSaPzWLDCmYTuvkq642qiRZNVywtxWyIuXf3Y+eR4tsMu Vpqz/mUsudF3kGRdewZrbCh2FdOS3LrK9DQRuo9mZtyfDQdgIj+s52HVTdOLSk1wVKG0 XC4QYvfsJsUBqshc0WDfGJGG+NHm/yJYMkMqdXRtrQSAmRSiM8uyzMVlgGdU4XrmzgQb onatMrgi5URVtIMw7qeWmBj9qNNl1SKYcn1fs8eiAunDu+CkULVXcZll4F2Vcc3Zch9E 5zXQ== MIME-Version: 1.0 X-Received: by 10.152.30.33 with SMTP id p1mr7045488lah.78.1415680124356; Mon, 10 Nov 2014 20:28:44 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.163.227 with HTTP; Mon, 10 Nov 2014 20:28:44 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Nov 2014 18:28:44 -1000 X-Google-Sender-Auth: Vhq8UfVaU2-vHXmOUUIxkt3Sy2A Message-ID: From: Barry Leiba To: Donald Eastlake Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/5VFQrpAUGqZi5NMqKau_Ra0h0Jc Cc: "iesg@ietf.org" , "draft-leiba-cotton-iana-5226bis.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-leiba-cotton-iana-5226bis-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: Tue, 11 Nov 2014 04:28:48 -0000 > I'm OK with an unspecified strictness order. But I think "Expert > review with significant, stable public documentation." is highly > misleading. In the absence of express additional criterion, > Specification Required constrains the expert to only judging whether > or not the documentation is sufficient. It should say "Significant > stable public documentation sufficient for interoperability." or > something like that. I can live with that. Shall I make the changes, with that modification? > Have you ever been in the position of seeking a code point > assignment when you believed the relevant expert was both > unconstrained by any specific guidelines and actively hostile to your > effort? I have and I can tell you I would have loved for the criterion > to be a simple Specification Required. So this may color my thinking. And that's why this version of BCP 26 is much stronger than the RFC 5226 version with respect to guidance for the designated expert. And I know that several of us on the IESG now are pushing that, strongly asking for DE guidance (often to the puzzlement of the document authors, who aren't sure what we're looking for). I think the reason guidance is often lacking is exactly because it's obvious to the people writing the document what the DE should be considering, and the problems happen much later. All that said, the current IESG is not the future IESG, and there may come a time when we again have an IESG that doesn't push on this point at all. Which is why it's good to have the strong push for DE guidance baked into BCP 26. Barry From nobody Mon Nov 10 20:56: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 64C5E1A8848; Mon, 10 Nov 2014 20:56:28 -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 Jg0wDHfGfzuj; Mon, 10 Nov 2014 20:56:27 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693841AD54C; Mon, 10 Nov 2014 20:56:27 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id uy5so6862745obc.40 for ; Mon, 10 Nov 2014 20:56:26 -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=XTbALmrz43P/kkg64N/3SoUFoBbBWMA1wWBa/Y+89Qs=; b=J/U6hAlfotLJqmmBApGMifFgmFwlJ7ghZ12JL7S7HljZ7JiPTuH0aS8iUxSvofWrlz S89X6vEySQzUjxjDbk6vVfca4PFWH6HV5noIe8OeTzcGYy0DZ/mRPQKrN5L7YcScKLZL ufcs6uH+7ytIT6+WblvDdWt+fY5447jFvQMO5J1OOjereeJ/2AhIUPwe60x8XslMsbW9 Jwrkg3gvaGXFP9oMAWlcCMmJO8WMt70M+NKl/H4Y6hCxKrNLYu4X7VhVevBuVCe9C1jn 96kceI1QBchJZkUjI3JFGV9lB0KZs2xBVfxxmz2J8wqlivsiuVRmlLfoIvaY+Hu0rZOM SVtQ== X-Received: by 10.182.50.168 with SMTP id d8mr30893898obo.2.1415681786533; Mon, 10 Nov 2014 20:56:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.145.4 with HTTP; Mon, 10 Nov 2014 20:56:06 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Mon, 10 Nov 2014 23:56:06 -0500 Message-ID: To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/YVtuIU7eHNa25o4U5Qw1BOn55kY Cc: "iesg@ietf.org" , "draft-leiba-cotton-iana-5226bis.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-leiba-cotton-iana-5226bis-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: Tue, 11 Nov 2014 04:56:28 -0000 Hi Barry, On Mon, Nov 10, 2014 at 11:28 PM, Barry Leiba wrote: >> I'm OK with an unspecified strictness order. But I think "Expert >> review with significant, stable public documentation." is highly >> misleading. In the absence of express additional criterion, >> Specification Required constrains the expert to only judging whether >> or not the documentation is sufficient. It should say "Significant >> stable public documentation sufficient for interoperability." or >> something like that. > > I can live with that. Shall I make the changes, with that modification? OK. with that I'm satisfied. >> Have you ever been in the position of seeking a code point >> assignment when you believed the relevant expert was both >> unconstrained by any specific guidelines and actively hostile to your >> effort? I have and I can tell you I would have loved for the criterion >> to be a simple Specification Required. So this may color my thinking. > > And that's why this version of BCP 26 is much stronger than the RFC > 5226 version with respect to guidance for the designated expert. And > I know that several of us on the IESG now are pushing that, strongly > asking for DE guidance (often to the puzzlement of the document > authors, who aren't sure what we're looking for). I think the reason > guidance is often lacking is exactly because it's obvious to the > people writing the document what the DE should be considering, and the > problems happen much later. I'm not so sure it's obvious. While there might be people they would trust, it is really a significant amount of work to try to come up with reasonably complete guidance - there is really no limit to the contingencies that could be covered. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > All that said, the current IESG is not the future IESG, and there may > come a time when we again have an IESG that doesn't push on this point > at all. Which is why it's good to have the strong push for DE > guidance baked into BCP 26. > > Barry From nobody Mon Nov 10 23:48: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 A8FB01AD554 for ; Mon, 10 Nov 2014 23:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3G3eD7M2PJ8 for ; Mon, 10 Nov 2014 23:48:09 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 962BA1A8923 for ; Mon, 10 Nov 2014 23:48:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 2497120440; Tue, 11 Nov 2014 02:45:56 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sahPuM92nWcU; Tue, 11 Nov 2014 02:45:55 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (dhcp-890c.meeting.ietf.org [31.133.137.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 11 Nov 2014 02:45:55 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ABB79814C6; Tue, 11 Nov 2014 02:48:06 -0500 (EST) From: Sam Hartman To: "Moriarty\, Kathleen" References: <4D1AEADB-47CE-4B79-8321-D096CFDF3AF9@emc.com> Date: Tue, 11 Nov 2014 02:48:06 -0500 In-Reply-To: (Kathleen Moriarty's message of "Fri, 24 Oct 2014 17:15:04 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/cwWjKu6wwIW3EPlop7kCNd4qEQw Cc: "secdir@ietf.org" Subject: Re: [secdir] SecDir lunch 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, 11 Nov 2014 07:48:10 -0000 Have people found good take-away lunch options for tomorrow? From nobody Mon Nov 10 23:57: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 84EE11A8956; Mon, 10 Nov 2014 23:57:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7g9-5OnuL26; Mon, 10 Nov 2014 23:57:06 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5517C1AD564; Mon, 10 Nov 2014 23:57:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 3090420454; Tue, 11 Nov 2014 02:54:53 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zzl9_rngA0yt; Tue, 11 Nov 2014 02:54:51 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (dhcp-890c.meeting.ietf.org [31.133.137.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 11 Nov 2014 02:54:51 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7AA84814C6; Tue, 11 Nov 2014 02:57:02 -0500 (EST) From: Sam Hartman To: Samuel Weiler References: Date: Tue, 11 Nov 2014 02:57:02 -0500 In-Reply-To: (Samuel Weiler's message of "Mon, 18 Aug 2014 16:38:48 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/NGOn4xhUjF5GtrcfPu0yBZC0snk Cc: draft-ietf-karp-bfd-analysis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-karp-bfd-analysis-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: Tue, 11 Nov 2014 07:57:07 -0000 My comments are prompted by Sam noting that he was hoping others would jump in. >>>>> "Samuel" == Samuel Weiler writes: Samuel> Summary: I'm not seeing anything that's grossly incorrect, Samuel> but I wonder if this doc is taking the right approach. I'm skeptical this doc is taking the right approach, but was involved in the KARP discussions and had an opportunity to raise comments there and chose not to. In general, I was not able to come up with a concrete articulation of why I thought this document wasn't quite in the right direction. However, on your two specific points, I think the doc is correct, so it's probably not the case that we're in agreement about what's wrong with the approach. Samuel> The security consideration section acknowledges that Samuel> increasing the length of the sequence number or connecting Samuel> the sequence numbers to clock time could reduce the risk of Samuel> replay attacks as, presumably, could moving to the Samuel> "meticulous" approaches that require an increasing sequence Samuel> number (and recomputation) at every packet, at the possible Samuel> cost of needing special hardware or having to increase the Samuel> time between BFD packets. These seem like simpler fixes Samuel> that adding a new hash algorithm, which is what the doc Samuel> ultimately suggests, and I wonder if adding GMAC is really Samuel> needed. There were extensive discussions of the performance arguments. My understanding is that something like GMAC might allow performance to be good enough to increase the sequence numbers fairly often, and that clearly is not true with SHA-1. There were a number of people in the KARP sessions arguing that given the performance constraints SHA-1 was the wrong security algorithm, myself included. Samuel> One thing that's not explicitly discussed, and which I would Samuel> like to see, is a general analysis of algorithm agility - Samuel> how hard is it to add a new algorithm? The doc says that Samuel> BFD has no key rollover mechanism - I suspect that adding Samuel> that and algorithm agility are more important, in the long Samuel> run, than just adding a stronger hash algorithm. (Which Samuel> isn't to say that we even need to improve those, just that Samuel> they may be more important.) This should be discussed. The design guide to which this is an analysis document requires those things be discussed. Well, in particular, the design guide requires a discussion of a gap analysis to the KARP requirements, and the KARP requirements mention algorithm agility and key rollover explicitly. Samuel> I'm also somewhat skeptical of the premise that BFD needs to Samuel> use algorithms that match the routing algorithm strength: Samuel> Moving the routing protocols to a stronger algorithm Samuel> while using weaker algorithm for BFD would allow the Samuel> attacker to bring down BFD in order to bring down the Samuel> routing protocol. BFD therefore needs to match the routing Samuel> protocols in its strength of algorithm. Samuel> Are the attack models of the two really aligned? As best I can tell, yes. In both cases you are concerned about integrity and replay. Samuel> Do the Samuel> keying models for both suggest that one or the other could Samuel> cope with weaker algorithms? Can one be more easily Samuel> rekeyed, thus making it easier to cope with weaker Samuel> algorithms? No. They are both annoying to re-key. It's likely that the IETF will pretend that both use the KARP crypto key table for keying. (Some of the glue to actualize this has not happened and there seems to be a lack of energy to do that glue) Hope this helps. --Sam From nobody Tue Nov 11 11:02: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 1BC741A1A96 for ; Tue, 11 Nov 2014 11:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, 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 n7jroT0NFTgC for ; Tue, 11 Nov 2014 11:02:27 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3C951A6EED for ; Tue, 11 Nov 2014 11:02:26 -0800 (PST) Received: from [107.17.59.174] (64-129-13-2.static.twtelecom.net [64.129.13.2] (may be forged)) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sABJ2PRu057427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Nov 2014 12:02:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 64-129-13-2.static.twtelecom.net [64.129.13.2] (may be forged) claimed to be [107.17.59.174] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Paul Hoffman In-Reply-To: Date: Tue, 11 Nov 2014 09:02:25 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <073F75DB-AB2B-44FE-B89F-548D51394EBB@vpnc.org> References: <4D1AEADB-47CE-4B79-8321-D096CFDF3AF9@emc.com> To: Sam Hartman X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/SQcQ87iA-9tFHhm9x5WnOBZuHck Cc: secdir Subject: Re: [secdir] SecDir lunch 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, 11 Nov 2014 19:02:28 -0000 On Nov 10, 2014, at 9:48 PM, Sam Hartman wrote: > Have people found good take-away lunch options for tomorrow? The ABC Store in the "rainbow gallery" has an aisle of sandwiches and = salads, and is way cheaper than any of the restaurants with take-out = sandwiches. --Paul Hoffman= From nobody Tue Nov 11 11:38: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 6053C1A0070 for ; Tue, 11 Nov 2014 11:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 CK9SB7xRYwoE for ; Tue, 11 Nov 2014 11:38:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2D61A8859 for ; Tue, 11 Nov 2014 11:38:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLN20005; Tue, 11 Nov 2014 19:38:07 +0000 (GMT) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Nov 2014 19:38:06 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.57]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Wed, 12 Nov 2014 03:38:00 +0800 From: Tina TSOU To: Paul Hoffman Thread-Topic: [secdir] SecDir lunch Thread-Index: AQHP/YPbL3xhGBk53U6MEt8rbEKfZJxbQuuAgACQDRM= Date: Tue, 11 Nov 2014 19:38:00 +0000 Message-ID: <6B299A72-0094-4C3E-A6CA-8EE64F71B437@huawei.com> References: <4D1AEADB-47CE-4B79-8321-D096CFDF3AF9@emc.com> ,<073F75DB-AB2B-44FE-B89F-548D51394EBB@vpnc.org> In-Reply-To: <073F75DB-AB2B-44FE-B89F-548D51394EBB@vpnc.org> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/mpawUGwWi4dozZZm-9Py8aqdznE Cc: Sam Hartman , secdir Subject: Re: [secdir] SecDir lunch 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, 11 Nov 2014 19:38:39 -0000 Dear all, Which room will we meet today? Thank you, Tina > On Nov 11, 2014, at 9:02 AM, "Paul Hoffman" wrote= : >=20 >> On Nov 10, 2014, at 9:48 PM, Sam Hartman wrote: >> Have people found good take-away lunch options for tomorrow? >=20 > The ABC Store in the "rainbow gallery" has an aisle of sandwiches and sal= ads, and is way cheaper than any of the restaurants with take-out sandwiche= s. >=20 > --Paul Hoffman > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Tue Nov 11 11:42: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 77D201A8823 for ; Tue, 11 Nov 2014 11:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Xs5lPEarerrP for ; Tue, 11 Nov 2014 11:42:42 -0800 (PST) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDCF71A1A36 for ; Tue, 11 Nov 2014 11:42:41 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id im17so1330002vcb.41 for ; Tue, 11 Nov 2014 11:42:41 -0800 (PST) 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=gsKmfxGwydS3PCX3eCTJmPo3mRKy4aKcV3FqsztM1Dg=; b=K9YfhTeS0S6/SxseyHuIzQ1jwzThuDr1h/fhv6zF8zwjWzj9efec4k1Ki5Uyjv07Pb vnQAtFqwMbNQ7mcggv5n48oephW95fg54M6FKw7Cbp/lPeSqITevVnPu3CgKY5XukcaR gIwxsc6KSYiY/7euPAvz94hOZtxS86p//x8UJmciE4ejmMiXBb8sj3KocUT3ixuiZPn7 Y5OCF2DeXef7yM/9zEpSv/bLJrlQ/1OIHcV26H8YG07FXvFpEbnceecFYlcSJ8PoVfIV dO5YvFN52/Xhd3NQmQC8jcICj+RknLWCpSfmspYf8H2peChuah/NWmzzKRzjAog1DJ09 feYw== X-Gm-Message-State: ALoCoQnRWE7b3ZZLRujPULRgqEJDMJ5AH/cxiIA+Z1urykKmuqAS4iga31ipdQJ1ROZrhcrrwiAc MIME-Version: 1.0 X-Received: by 10.221.37.195 with SMTP id tf3mr3124039vcb.63.1415734961186; Tue, 11 Nov 2014 11:42:41 -0800 (PST) Received: by 10.31.149.1 with HTTP; Tue, 11 Nov 2014 11:42:41 -0800 (PST) In-Reply-To: References: <4D1AEADB-47CE-4B79-8321-D096CFDF3AF9@emc.com> Date: Tue, 11 Nov 2014 09:42:41 -1000 Message-ID: From: Richard Barnes To: Sam Hartman Content-Type: multipart/alternative; boundary=001a1133480a75423305079a7b4e Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/xz3XejKBeioAr888T0Ga3pjAgHM Cc: "Moriarty, Kathleen" , "secdir@ietf.org" Subject: Re: [secdir] SecDir lunch 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, 11 Nov 2014 19:42:43 -0000 --001a1133480a75423305079a7b4e Content-Type: text/plain; charset=UTF-8 There's also a Subway and McDonalds on Ala Moana, if you want to take a short walk. On Mon, Nov 10, 2014 at 9:48 PM, Sam Hartman wrote: > Have people found good take-away lunch options for tomorrow? > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > --001a1133480a75423305079a7b4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There's also a Subway and McDonalds on Ala Moana, if y= ou want to take a short walk.

On Mon, Nov 10, 2014 at 9:48 PM, Sam Hartman <ha= rtmans-ietf@mit.edu> wrote:
Have people found good take-away lunch options for tomorrow?

_______________________________________________
secdir mailing list
secdir@ietf.org
= https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

--001a1133480a75423305079a7b4e-- From nobody Tue Nov 11 11:51: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 1EAFC1A89A2 for ; Tue, 11 Nov 2014 11:51:57 -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 MEGrnwgGcMt2 for ; Tue, 11 Nov 2014 11:51:55 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EC771A8908 for ; Tue, 11 Nov 2014 11:51:50 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so1615686wgg.21 for ; Tue, 11 Nov 2014 11:51:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XTlcAoXT7Qd7iY+pcUbZjvvT2pJXRLg1bnziSIVi6WQ=; b=RVSeeRFvQipQS5Z3FZ2sv6Ye6nNRsUehIBE6syMU/ihu6bVun8maCYJ6jiViFE7HqP S+lB2IWtqPVWZppGcnoaKMyZenFfvPz6padOhSWVcXZzDRurZZmoPtRBxgTyF9g2P+91 25MSv9MnJFubCZWVcGu/vRdokVBFPi5v3gicQtO4nsNPYjGcUJQZhomTLM6FGWegVSIT SfToFU5jmVyD6tZO/ABQujN2DNrk0RpYCVu/ERmARnWhiorA2N+NgHtWG+n3ByO6mgK/ jUw0SD6MRdpXhfiSmg+1ocwwbE6m3ohudUz1ZL7ZTs1ws/Z68aDTadqJIfVdh5MefpSc T2KQ== X-Received: by 10.180.93.233 with SMTP id cx9mr44076034wib.48.1415735509318; Tue, 11 Nov 2014 11:51:49 -0800 (PST) Received: from t2001067c037001609c4604f98381795f.wireless.v6.meeting.ietf.org (t2001067c037001609c4604f98381795f.wireless.v6.meeting.ietf.org. [2001:67c:370:160:9c46:4f9:8381:795f]) by mx.google.com with ESMTPSA id q9sm18781189wix.6.2014.11.11.11.51.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 11:51:48 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: <6B299A72-0094-4C3E-A6CA-8EE64F71B437@huawei.com> Date: Tue, 11 Nov 2014 09:51:44 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <3FF56A05-4057-4A51-B554-B37A1FED4955@gmail.com> References: <4D1AEADB-47CE-4B79-8321-D096CFDF3AF9@emc.com> <, <073F75DB-AB2B-44FE-B89F-548D51394EBB@vpnc.org> <>> <6B299A72-0094-4C3E-A6CA-8EE64F71B437@huawei.com> To: Tina TSOU X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/BBbJjySAv3KPRgDy66gANPxYp9Y Cc: Sam Hartman , Paul Hoffman , secdir Subject: Re: [secdir] SecDir lunch 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, 11 Nov 2014 19:51:57 -0000 South Pacific 2 It=E2=80=99s in something called the mid-pacific conference center (6th = floor) > On Nov 11, 2014, at 9:38 AM, Tina TSOU = wrote: >=20 > Dear all, >=20 > Which room will we meet today? >=20 >=20 > Thank you, > Tina >=20 >> On Nov 11, 2014, at 9:02 AM, "Paul Hoffman" = wrote: >>=20 >>> On Nov 10, 2014, at 9:48 PM, Sam Hartman = wrote: >>> Have people found good take-away lunch options for tomorrow? >>=20 >> The ABC Store in the "rainbow gallery" has an aisle of sandwiches and = salads, and is way cheaper than any of the restaurants with take-out = sandwiches. >>=20 >> --Paul Hoffman >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Tue Nov 11 12:02: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 33F131A6F60 for ; Tue, 11 Nov 2014 12:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 4dASNhTMkNUQ for ; Tue, 11 Nov 2014 12:02:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5DE1A90EF for ; Tue, 11 Nov 2014 12:02:47 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLN21156; Tue, 11 Nov 2014 20:02:46 +0000 (GMT) Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Nov 2014 20:02:45 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.57]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Wed, 12 Nov 2014 04:02:39 +0800 From: Tina TSOU To: Yoav Nir Thread-Topic: [secdir] SecDir lunch Thread-Index: AQHP/YPbL3xhGBk53U6MEt8rbEKfZJxbQuuAgACQDRP//326AIAAiSl+ Date: Tue, 11 Nov 2014 20:02:39 +0000 Message-ID: References: <4D1AEADB-47CE-4B79-8321-D096CFDF3AF9@emc.com> <,<073F75DB-AB2B-44FE-B89F-548D51394EBB@vpnc.org> <>> <6B299A72-0094-4C3E-A6CA-8EE64F71B437@huawei.com>, <3FF56A05-4057-4A51-B554-B37A1FED4955@gmail.com> In-Reply-To: <3FF56A05-4057-4A51-B554-B37A1FED4955@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/r1Xjg518yT8ckYydJG-VXX9yCFA Cc: Sam Hartman , Paul Hoffman , secdir Subject: Re: [secdir] SecDir lunch 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, 11 Nov 2014 20:02:57 -0000 RGVhciBZb2F2LA0KDQpUaGFua3MsIDExOjQ1YW0gb3IgMTJwbT8NCg0KDQpUaGFuayB5b3UsDQpU aW5hDQoNCj4gT24gTm92IDExLCAyMDE0LCBhdCA5OjU4IEFNLCAiWW9hdiBOaXIiIDx5bmlyLmll dGZAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IFNvdXRoIFBhY2lmaWMgMg0KPiANCj4gSXShr3Mg aW4gc29tZXRoaW5nIGNhbGxlZCB0aGUgbWlkLXBhY2lmaWMgY29uZmVyZW5jZSBjZW50ZXIgKDZ0 aCBmbG9vcikNCj4gDQo+PiBPbiBOb3YgMTEsIDIwMTQsIGF0IDk6MzggQU0sIFRpbmEgVFNPVSA8 VGluYS5Uc291LlpvdXRpbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQo+PiANCj4+IERlYXIgYWxsLA0K Pj4gDQo+PiBXaGljaCByb29tIHdpbGwgd2UgbWVldCB0b2RheT8NCj4+IA0KPj4gDQo+PiBUaGFu ayB5b3UsDQo+PiBUaW5hDQo+PiANCj4+Pj4gT24gTm92IDExLCAyMDE0LCBhdCA5OjAyIEFNLCAi UGF1bCBIb2ZmbWFuIiA8cGF1bC5ob2ZmbWFuQHZwbmMub3JnPiB3cm90ZToNCj4+Pj4gDQo+Pj4+ IE9uIE5vdiAxMCwgMjAxNCwgYXQgOTo0OCBQTSwgU2FtIEhhcnRtYW4gPGhhcnRtYW5zLWlldGZA bWl0LmVkdT4gd3JvdGU6DQo+Pj4+IEhhdmUgcGVvcGxlIGZvdW5kIGdvb2QgdGFrZS1hd2F5IGx1 bmNoIG9wdGlvbnMgZm9yIHRvbW9ycm93Pw0KPj4+IA0KPj4+IFRoZSBBQkMgU3RvcmUgaW4gdGhl ICJyYWluYm93IGdhbGxlcnkiIGhhcyBhbiBhaXNsZSBvZiBzYW5kd2ljaGVzIGFuZCBzYWxhZHMs IGFuZCBpcyB3YXkgY2hlYXBlciB0aGFuIGFueSBvZiB0aGUgcmVzdGF1cmFudHMgd2l0aCB0YWtl LW91dCBzYW5kd2ljaGVzLg0KPj4+IA0KPj4+IC0tUGF1bCBIb2ZmbWFuDQo+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBzZWNkaXIgbWFpbGlu ZyBsaXN0DQo+Pj4gc2VjZGlyQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZWNkaXINCj4+PiB3aWtpOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvYXJl YS9zZWMvdHJhYy93aWtpL1NlY0RpclJldmlldw0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2VjZGlyIG1haWxpbmcgbGlzdA0KPj4g c2VjZGlyQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NlY2Rpcg0KPj4gd2lraTogaHR0cDovL3Rvb2xzLmlldGYub3JnL2FyZWEvc2VjL3RyYWMvd2lr aS9TZWNEaXJSZXZpZXcNCj4gDQo= From nobody Tue Nov 11 12:41: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 9846E1A88BB for ; Tue, 11 Nov 2014 12:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 DQtONliutMtm for ; Tue, 11 Nov 2014 12:41:23 -0800 (PST) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880E71A1AEF for ; Tue, 11 Nov 2014 12:41:23 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id id10so1364505vcb.30 for ; Tue, 11 Nov 2014 12:41:22 -0800 (PST) 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=Z0x2rOKDwVdxNwW9oqHKxtogsJLFNFeqnFKLZ7bST8E=; b=dIf0oU54qy9kZftdjeNbDdVUMy/LHriXsogwrBlWG+B/gyUyUOw8LY9pLf4yhrZcPR okfpk8Xnx6qRk531+r5ztawRBKizcmE4CrQAsSHcoLA8jgobRPA2V56voMnxIZeCi+Lp jqq3UYuQ9JBE+5jLl1Jbe93INAYRZ70PrH99LevsmBv3HZddTRE8zh1dOSHSgeI5Hmrz WVZaZtoJSElqGSeurO6+JR5UNaVKDK6nEvRVY5ZpqqZgjSTOrdBEmn54w+5EJ6+Brphv DJ8h8wUR6vVhfn2FbdCL/AG7OwzULV5bEmcvfT5Gfl8mWFdq5OOg5ZhiYXe1m/Py9zID +75g== X-Gm-Message-State: ALoCoQlzG7k8IiWZ0wY+sBbgR4q77zuvgRDRjzCDqhIPSWdOSSsvfYTjgXZESEByuHuGPjT8nTal MIME-Version: 1.0 X-Received: by 10.52.9.37 with SMTP id w5mr9138317vda.38.1415738482717; Tue, 11 Nov 2014 12:41:22 -0800 (PST) Received: by 10.31.149.1 with HTTP; Tue, 11 Nov 2014 12:41:22 -0800 (PST) In-Reply-To: References: <4D1AEADB-47CE-4B79-8321-D096CFDF3AF9@emc.com> <6B299A72-0094-4C3E-A6CA-8EE64F71B437@huawei.com> <3FF56A05-4057-4A51-B554-B37A1FED4955@gmail.com> Date: Tue, 11 Nov 2014 10:41:22 -1000 Message-ID: From: Richard Barnes To: Tina TSOU Content-Type: multipart/alternative; boundary=20cf302efa285b89bb05079b4dcf Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/hsGvwKqe14TQV9PFCxejJTt70ZY Cc: Sam Hartman , Paul Hoffman , secdir Subject: Re: [secdir] SecDir lunch 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, 11 Nov 2014 20:41:25 -0000 --20cf302efa285b89bb05079b4dcf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I expect that as usual, we will convene some time between 11:30 and 12:00. On Tue, Nov 11, 2014 at 10:02 AM, Tina TSOU wrote: > Dear Yoav, > > Thanks, 11:45am or 12pm? > > > Thank you, > Tina > > > On Nov 11, 2014, at 9:58 AM, "Yoav Nir" wrote: > > > > South Pacific 2 > > > > It=E2=80=99s in something called the mid-pacific conference center (6th= floor) > > > >> On Nov 11, 2014, at 9:38 AM, Tina TSOU > wrote: > >> > >> Dear all, > >> > >> Which room will we meet today? > >> > >> > >> Thank you, > >> Tina > >> > >>>> On Nov 11, 2014, at 9:02 AM, "Paul Hoffman" > wrote: > >>>> > >>>> On Nov 10, 2014, at 9:48 PM, Sam Hartman > wrote: > >>>> Have people found good take-away lunch options for tomorrow? > >>> > >>> The ABC Store in the "rainbow gallery" has an aisle of sandwiches and > salads, and is way cheaper than any of the restaurants with take-out > sandwiches. > >>> > >>> --Paul Hoffman > >>> _______________________________________________ > >>> secdir mailing list > >>> secdir@ietf.org > >>> https://www.ietf.org/mailman/listinfo/secdir > >>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > >> > >> _______________________________________________ > >> secdir mailing list > >> secdir@ietf.org > >> https://www.ietf.org/mailman/listinfo/secdir > >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > --20cf302efa285b89bb05079b4dcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I expect that as usual, we will convene some time between = 11:30 and 12:00.

On Tue, Nov 11, 2014 at 10:02 AM, Tina TSOU <= Tina.Tsou= .Zouting@huawei.com> wrote:
Dear Yoav,

Thanks, 11:45am or 12pm?


Thank you,
Tina

> On Nov 11, 2014, at 9:58 AM, "Yoav Nir" <ynir.ietf@gmail.com> wrote:
>
> South Pacific 2
>
> It=E2=80=99s in something called the mid-pacific conference center (6t= h floor)
>
>> On Nov 11, 2014, at 9:38 AM, Tina TSOU <Tina.Tsou.Zouting@huawei.com> wrote:
>>
>> Dear all,
>>
>> Which room will we meet today?
>>
>>
>> Thank you,
>> Tina
>>
>>>> On Nov 11, 2014, at 9:02 AM, "Paul Hoffman" <= paul.hoffman@vpnc.org> wrot= e:
>>>>
>>>> On Nov 10, 2014, at 9:48 PM, Sam Hartman <hartmans-ietf@mit.edu> wrote:
>>>> Have people found good take-away lunch options for tomorro= w?
>>>
>>> The ABC Store in the "rainbow gallery" has an aisle = of sandwiches and salads, and is way cheaper than any of the restaurants wi= th take-out sandwiches.
>>>
>>> --Paul Hoffman
>>> _______________________________________________
>>> secdir mailing list
>>> secdir@ietf.org
>>> https://www.ietf.org/mailman/listinfo/secdir
>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDir= Review
>>
>> _______________________________________________
>> secdir mailing list
>> secdir@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdir
>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirRevi= ew
>
_______________________________________________
secdir mailing list
secdir@ietf.org
= https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

--20cf302efa285b89bb05079b4dcf-- From nobody Tue Nov 11 13:21: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 4FAB21A9104 for ; Tue, 11 Nov 2014 13:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.894 X-Spam-Level: X-Spam-Status: No, score=-4.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 xImtH6YmOyFB for ; Tue, 11 Nov 2014 13:21:33 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A641ACD0B for ; Tue, 11 Nov 2014 13:21:30 -0800 (PST) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sABLLNj3029124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Nov 2014 16:21:24 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com sABLLNj3029124 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1415740884; bh=Rp3zS6gC/jWnp229rgJFwtjWhos=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=wdgtv7PYhe17xO3GjFPSrV+ek2F4K1kfKWBFe4ilYFrRfn5knb6pshGD0Sky0bvOX F59pK5vaDy9QQboPO0cX5XqC7Jlv8AQTCJOi1ReZlii39khSqMdIlmUTNFeCLVRzPn nB8H4O42uFtlEcAh4VxzZnLxXwhHxEeXlLA3HN2s= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com sABLLNj3029124 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd54.lss.emc.com (RSA Interceptor); Tue, 11 Nov 2014 16:20:58 -0500 Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sABLKu0F012234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 16:21:08 -0500 Received: from MXHUB106.corp.emc.com (10.253.58.23) by mxhub23.corp.emc.com (128.222.70.135) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 11 Nov 2014 16:21:02 -0500 Received: from MX103CL02.corp.emc.com ([169.254.6.33]) by MXHUB106.corp.emc.com ([10.253.58.23]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 16:21:01 -0500 From: "Moriarty, Kathleen" To: Richard Barnes Thread-Topic: [secdir] SecDir lunch Thread-Index: AQHP/YPgJrP2XsQmEEKsYVXV+NBz25xcHNmAgAAJ8QCAAAPWAIAAAw2AgAAK0QD//7dC6Q== Date: Tue, 11 Nov 2014 21:21:00 +0000 Message-ID: References: <4D1AEADB-47CE-4B79-8321-D096CFDF3AF9@emc.com> <6B299A72-0094-4C3E-A6CA-8EE64F71B437@huawei.com> <3FF56A05-4057-4A51-B554-B37A1FED4955@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F1B259EF82EA4C64A8FBC22DBE62C120emccom_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/qLC8RpriyN5j4w9EI6nmCwkZETo Cc: secdir , Sam Hartman , Paul Hoffman Subject: Re: [secdir] SecDir lunch 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, 11 Nov 2014 21:21:38 -0000 --_000_F1B259EF82EA4C64A8FBC22DBE62C120emccom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes & for options, ABC has some take away and Pronto pickle. Sent from my iPhone On Nov 11, 2014, at 10:41 AM, "Richard Barnes" > wrote: I expect that as usual, we will convene some time between 11:30 and 12:00. On Tue, Nov 11, 2014 at 10:02 AM, Tina TSOU > wrote: Dear Yoav, Thanks, 11:45am or 12pm? Thank you, Tina > On Nov 11, 2014, at 9:58 AM, "Yoav Nir" > wrote: > > South Pacific 2 > > It=92s in something called the mid-pacific conference center (6th floor) > >> On Nov 11, 2014, at 9:38 AM, Tina TSOU > wrote: >> >> Dear all, >> >> Which room will we meet today? >> >> >> Thank you, >> Tina >> >>>> On Nov 11, 2014, at 9:02 AM, "Paul Hoffman" > wrote: >>>> >>>> On Nov 10, 2014, at 9:48 PM, Sam Hartman > wrote: >>>> Have people found good take-away lunch options for tomorrow? >>> >>> The ABC Store in the "rainbow gallery" has an aisle of sandwiches and s= alads, and is way cheaper than any of the restaurants with take-out sandwic= hes. >>> >>> --Paul Hoffman >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --_000_F1B259EF82EA4C64A8FBC22DBE62C120emccom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Yes & for options, ABC has some take away and Pronto pickle.

Sent from my iPhone

On Nov 11, 2014, at 10:41 AM, "Richard Barnes" <rlb@ipv.sx> wrote:

I expect that as usual, we will convene some time between = 11:30 and 12:00.

On Tue, Nov 11, 2014 at 10:02 AM, Tina TSOU <Tina.= Tsou.Zouting@huawei.com> wrote:
Dear Yoav,

Thanks, 11:45am or 12pm?


Thank you,
Tina

> On Nov 11, 2014, at 9:58 AM, "Yoav Nir" <ynir.ietf@gmail.com> wrote:
>
> South Pacific 2
>
> It=92s in something called the mid-pacific conference center (6th floo= r)
>
>> On Nov 11, 2014, at 9:38 AM, Tina TSOU <Tina.Tsou.Zouting@huawei.com> wrote:
>>
>> Dear all,
>>
>> Which room will we meet today?
>>
>>
>> Thank you,
>> Tina
>>
>>>> On Nov 11, 2014, at 9:02 AM, "Paul Hoffman" <= paul.hoffman@vpnc.org> wrot= e:
>>>>
>>>> On Nov 10, 2014, at 9:48 PM, Sam Hartman <hartmans-ietf@mit.edu> wrote:
>>>> Have people found good take-away lunch options for tomorro= w?
>>>
>>> The ABC Store in the "rainbow gallery" has an aisle = of sandwiches and salads, and is way cheaper than any of the restaurants wi= th take-out sandwiches.
>>>
>>> --Paul Hoffman
>>> _______________________________________________
>>> secdir mailing list
>>> secdir@ietf.org
>>> https://www.ietf.org/mailman/listinfo/secdir
>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>
>> _______________________________________________
>> secdir mailing list
>> secdir@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdir
>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>
_______________________________________________
secdir mailing list
secdir@ietf.org
= https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.= ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
--_000_F1B259EF82EA4C64A8FBC22DBE62C120emccom_-- From nobody Tue Nov 11 13:25: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 8676D1ACE46 for ; Tue, 11 Nov 2014 13:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.894 X-Spam-Level: X-Spam-Status: No, score=-4.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 QUjl7QRTlSfn for ; Tue, 11 Nov 2014 13:25:02 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA2B1ACE4B for ; Tue, 11 Nov 2014 13:25:02 -0800 (PST) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sABLP0Tu004166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Nov 2014 16:25:01 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com sABLP0Tu004166 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1415741101; bh=Vtxx/tfFq9Qi2jqjrufD0iFtvhU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=uVfdPpwpirzNuBkG/EpfudVsHaR/QokXnUGTH6m1U3p7hvzXT82JBdn5ZGaGtvWUi Rd+9XqEl7gJeS5yyTmjvsBZd35VSqMlx+BVaOsN8SBCJhrkbLqJeumXYKZa+DFfe3b 2HaT6UzxbyZP3/INt/IxUvod7JE1omKidlDVxnvU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com sABLP0Tu004166 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd55.lss.emc.com (RSA Interceptor); Tue, 11 Nov 2014 16:24:39 -0500 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sABLOk9N026632 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 16:24:47 -0500 Received: from MXHUB106.corp.emc.com (10.253.58.23) by mxhub26.corp.emc.com (10.254.110.182) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 11 Nov 2014 16:24:46 -0500 Received: from MX103CL02.corp.emc.com ([169.254.6.33]) by MXHUB106.corp.emc.com ([10.253.58.23]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 16:24:46 -0500 From: "Moriarty, Kathleen" To: Richard Barnes Thread-Topic: [secdir] SecDir lunch Thread-Index: AQHP/YPgJrP2XsQmEEKsYVXV+NBz25xcHNmAgAAJ8QCAAAPWAIAAAw2AgAAK0QD//7dC6YAAAQ3B Date: Tue, 11 Nov 2014 21:24:46 +0000 Message-ID: References: <4D1AEADB-47CE-4B79-8321-D096CFDF3AF9@emc.com> <6B299A72-0094-4C3E-A6CA-8EE64F71B437@huawei.com> <3FF56A05-4057-4A51-B554-B37A1FED4955@gmail.com> , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_B13E648B71454A318FDCB26F521CB7DEemccom_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/qMkGu2uxFOvH4wuoRkAuucGX4LU Cc: Sam Hartman , Paul Hoffman , secdir Subject: Re: [secdir] SecDir lunch 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, 11 Nov 2014 21:25:05 -0000 --_000_B13E648B71454A318FDCB26F521CB7DEemccom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The yes was to Richard, grab food, come to the room and we'll start by 12, = maybe earlier. Sent from my iPhone On Nov 11, 2014, at 11:22 AM, "Moriarty, Kathleen" > wrote: Yes & for options, ABC has some take away and Pronto pickle. Sent from my iPhone On Nov 11, 2014, at 10:41 AM, "Richard Barnes" > wrote: I expect that as usual, we will convene some time between 11:30 and 12:00. On Tue, Nov 11, 2014 at 10:02 AM, Tina TSOU > wrote: Dear Yoav, Thanks, 11:45am or 12pm? Thank you, Tina > On Nov 11, 2014, at 9:58 AM, "Yoav Nir" > wrote: > > South Pacific 2 > > It=92s in something called the mid-pacific conference center (6th floor) > >> On Nov 11, 2014, at 9:38 AM, Tina TSOU > wrote: >> >> Dear all, >> >> Which room will we meet today? >> >> >> Thank you, >> Tina >> >>>> On Nov 11, 2014, at 9:02 AM, "Paul Hoffman" > wrote: >>>> >>>> On Nov 10, 2014, at 9:48 PM, Sam Hartman > wrote: >>>> Have people found good take-away lunch options for tomorrow? >>> >>> The ABC Store in the "rainbow gallery" has an aisle of sandwiches and s= alads, and is way cheaper than any of the restaurants with take-out sandwic= hes. >>> >>> --Paul Hoffman >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --_000_B13E648B71454A318FDCB26F521CB7DEemccom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The yes was to Richard, grab food, come to the room and we'll start by= 12, maybe earlier.

Sent from my iPhone

On Nov 11, 2014, at 11:22 AM, "Moriarty, Kathleen" <kathleen.moriarty@emc.com> wrote:=

Yes & for options, ABC has some take away and Pronto pickle.

Sent from my iPhone

On Nov 11, 2014, at 10:41 AM, "Richard Barnes" <rlb@ipv.sx> wrote:

I expect that as usual, we will convene some time between = 11:30 and 12:00.

On Tue, Nov 11, 2014 at 10:02 AM, Tina TSOU <Tina.= Tsou.Zouting@huawei.com> wrote:
Dear Yoav,

Thanks, 11:45am or 12pm?


Thank you,
Tina

> On Nov 11, 2014, at 9:58 AM, "Yoav Nir" <ynir.ietf@gmail.com> wrote:
>
> South Pacific 2
>
> It=92s in something called the mid-pacific conference center (6th floo= r)
>
>> On Nov 11, 2014, at 9:38 AM, Tina TSOU <Tina.Tsou.Zouting@huawei.com> wrote:
>>
>> Dear all,
>>
>> Which room will we meet today?
>>
>>
>> Thank you,
>> Tina
>>
>>>> On Nov 11, 2014, at 9:02 AM, "Paul Hoffman" <= paul.hoffman@vpnc.org> wrot= e:
>>>>
>>>> On Nov 10, 2014, at 9:48 PM, Sam Hartman <hartmans-ietf@mit.edu> wrote:
>>>> Have people found good take-away lunch options for tomorro= w?
>>>
>>> The ABC Store in the "rainbow gallery" has an aisle = of sandwiches and salads, and is way cheaper than any of the restaurants wi= th take-out sandwiches.
>>>
>>> --Paul Hoffman
>>> _______________________________________________
>>> secdir mailing list
>>> secdir@ietf.org
>>> https://www.ietf.org/mailman/listinfo/secdir
>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>
>> _______________________________________________
>> secdir mailing list
>> secdir@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdir
>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>
_______________________________________________
secdir mailing list
secdir@ietf.org
= https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.= ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.= ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
--_000_B13E648B71454A318FDCB26F521CB7DEemccom_-- From nobody Tue Nov 11 13:27: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 AB0261A1B53 for ; Tue, 11 Nov 2014 13:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.894 X-Spam-Level: X-Spam-Status: No, score=-4.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 HeTeDvNs66vo for ; Tue, 11 Nov 2014 13:27:17 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6ED91A0020 for ; Tue, 11 Nov 2014 13:27:16 -0800 (PST) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sABLRABw007470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Nov 2014 16:27:11 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com sABLRABw007470 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1415741231; bh=w0wHMU7qBL3UjYHGMsUVbJzZ/Fw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=SHLXW2yfv59zESOxd7kiQKAHSrbjgOMFZCszKYtlbcGRGdz1Z3GUpNvV6x3ce3Eo3 qP9h1wKc4+/4llMcSCmDwglszBfBoy9dheqoDyjIgRE035Krn3bKC3c/Ej4uq5Dr7f 6occxaHQm3pn2JmRRTO5deDA6tOgKCLWNkVilf9Q= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com sABLRABw007470 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd02.lss.emc.com (RSA Interceptor); Tue, 11 Nov 2014 16:26:04 -0500 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sABLQt4J020467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 16:26:56 -0500 Received: from MXHUB108.corp.emc.com (10.253.58.24) by mxhub30.corp.emc.com (128.222.70.170) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 11 Nov 2014 16:26:55 -0500 Received: from MX103CL02.corp.emc.com ([169.254.6.33]) by MXHUB108.corp.emc.com ([10.253.58.24]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 16:26:55 -0500 From: "Moriarty, Kathleen" To: Vincent Roca Thread-Topic: [secdir] Topic for our SecDir lunch: The PTB-PTS ICMP-based Attack against IPsec Gateways Thread-Index: AQHP/SssbZIjXhpCOUON4Fb+N3k+xZxa0z+AgAAFjACAARlMoQ== Date: Tue, 11 Nov 2014 21:26:54 +0000 Message-ID: References: <38936223-5F53-4EC4-AA7B-15AF5F7F7AF6@inria.fr> <85C3C2D1-7185-48CD-91A9-5D89B75101BF@gmail.com>, <428B3579-AB82-49D3-A854-293ECBA8FEDD@inria.fr> In-Reply-To: <428B3579-AB82-49D3-A854-293ECBA8FEDD@inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A14F8096BB614D96AE48F3CEF790456Femccom_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/DsQBXp0SrYI1Yyu2tVmv-ixEQS0 Cc: "ludovic.jacquin@hp.com" , "secdir@ietf.org" Subject: Re: [secdir] Topic for our SecDir lunch: The PTB-PTS ICMP-based Attack against IPsec Gateways 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, 11 Nov 2014 21:27:19 -0000 --_000_A14F8096BB614D96AE48F3CEF790456Femccom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable We can touch on this at the meeting. There should be time, but I agree wit= h Yoav. Thanks, Kathleen Sent from my iPhone On Nov 10, 2014, at 1:40 PM, "Vincent Roca" > wrote: Thanks Yoav. Yes, having this discussion on IPsec related mailing lists is = needed, but I think SecDir can also be appropriate if the problem applies to other tunneling technique= s as well (which we didn=92t test). Honestly speaking, I=92m trying to figure out how to proceed the best and a= dvices like yours are welcome. Cheers, Vincent Le 10 nov. 2014 =E0 13:20, Yoav Nir > a =E9crit : Hi, Vincent. Not at all opposed to bringing this up at SecDir lunch, but wouldn=92t the = IPsecME working group session and the ipsec mailing list be the more approp= riate venue? The SecDir is made up of people with (hopefully) enough knowledge about sec= urity to review an arbitrary draft and check that security has been conside= red and appropriate considerations documented. The attack described in that paper is not even specifically related to IPse= c. It could plague any tunneling mechanism such as L2TP, GRE, PPTP, IP-in-I= P. Although this is an attack, it might be appropriate for the transport ar= ea. Yoav On Nov 10, 2014, at 11:13 AM, Vincent Roca > wrote: Hi everybody, There=92s a subject I=92d like to discuss with you tomorrow during our SecD= ir lunch if we have time for that. It=92s about a DoS on IPsec we have found with my previous PhD student, Lud= ovic. It=92s described here: =AB Too Big or Too Small? The PTB-PTS ICMP-based Attack against IPsec Gatew= ays =BB, GLOBECOM=9214. PDF is freely available at: https://hal.inria.fr/hal-01052994/en/ The study has limits since it only focusses on IPv4 and a single OS (stable= Squeeze Debian distribution). That being said, we have an exploit using default IPsec configuration, eith= er preventing end-hosts to open new TCP connections (when relying on PMTUd) or creating large initial delay= /performance penalties (when relying on PLPMTUd). And UDP connexions will be affected too=85 The only thing an attacker needs is to be on the IPsec tunnel path with the= ability to eavesdrop encrypted traffic and send back a forged packet (e.g., a non encrypted Wifi network s= hould be sufficient, I see many of them available at IETF ;-) So we=92d like to have your feedback in particular on the following two poi= nts: - Is there an appropriate way to manage Path MTUs in presence of IPsec tunn= els when we are already at the minimum PMTU size? - Is there an appropriate way to make the end-host (in the =AB red =BB prot= ected LAN) and its IPsec gateway understand each other when we are already at the minimum PMTU? This is clearly a tricky situation that may not be well addressed today. Is= it described somewhere in an RFC so that implementers have clear guidelines? We didn=92t find anything, but = it does not mean there=92s nothing. And may the problem be extended to other tunneling technologies that perfor= m encapsulation? Your feedback is welcome. Thanks, Ludovic and Vincent -- Vincent Roca, PhD/HDR, Inria research institute, France http://privatics.inrialpes.fr/~roca _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --_000_A14F8096BB614D96AE48F3CEF790456Femccom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
We can touch on this at the meeting.  There should be time, but I= agree with Yoav.

Thanks,
Kathleen

Sent from my iPhone

On Nov 10, 2014, at 1:40 PM, "Vincent Roca" <vincent.roca@inria.fr> wrote:

Thanks Yoav. Yes, having this discussion on IPsec related mailing list= s is needed, but I think SecDir
can also be appropriate if the problem applies to other tunneling tech= niques as well (which we didn=92t test).
Honestly speaking, I=92m trying to figure out how to proceed the best = and advices like yours are welcome.
Cheers,

  Vincent

Le 10 nov. 2014 =E0 13:20, Yoav Nir <ynir.ietf@gmail.com> a =E9crit :
Hi, Vincent.

Not at all opposed to bringing this up at SecDir lunch, but= wouldn=92t the IPsecME working group session and the ipsec mailing list be= the more appropriate venue?

The SecDir is made up of people with (hopefully) enough kno= wledge about security to review an arbitrary draft and check that security = has been considered and appropriate considerations documented. 

The attack described in that paper is not even specifically= related to IPsec. It could plague any tunneling mechanism such as L2TP, GR= E, PPTP, IP-in-IP. Although this is an attack, it might be appropriate for = the transport area.

Yoav

On Nov 10, 2014, at 11:13 AM, Vincent Roca <vincent.roca@inria.fr> wrote= :

Hi everybody,

There=92s a subject I=92d like to discuss with you tomorrow= during our SecDir lunch if we have time for that.
It=92s about a DoS on IPsec we have found with my previous = PhD student, Ludovic. It=92s described here:

=AB Too Big or Too Small? The PTB-PTS ICMP-based Attack agains= t IPsec Gateways =BB, GLOBECOM=9214.
PDF is freely available at: https:/= /hal.inria.fr/hal-01052994/en/

The study has limits since it only focusses on IPv4 and a s= ingle OS (stable Squeeze Debian distribution).
That being said, we have an exploit using default IPsec con= figuration, either preventing end-hosts to open
new TCP connections (when relying on PMTUd) or creating lar= ge initial delay/performance penalties
(when relying on PLPMTUd). And UDP connexions will be affec= ted too=85
The only thing an attacker needs is to be on the IPsec tunn= el path with the ability to eavesdrop encrypted
traffic and send back a forged packet (e.g., a non encrypte= d Wifi network should be sufficient, I see many
of them available at IETF ;-)

So we=92d like to have your feedback in particular on the f= ollowing two points:

- Is there an appropriate way to manage Path = MTUs in presence of IPsec tunnels when we are already
at the minimum PMTU si= ze?

- Is there an appropriate way to make the end= -host (in the =AB red =BB protected LAN) and its IPsec gateway
understand each other when we are already at = the minimum PMTU?

This is clearly a tricky situation that may not be well add= ressed today. Is it described somewhere in an RFC
so that implementers have clear guidelines? We didn=92t fin= d anything, but it does not mean there=92s nothing.
And may the problem be extended to other tunneling technolo= gies that perform encapsulation?

Your feedback is welcome.
Thanks,

  Ludovic and Vincent

--
   Vincent Roca, PhD/HDR, Inria research institute, France    htt= p://privatics.inrialpes.fr/~roca
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.o= rg/mailman/listinfo/secdir
wiki: htt= p://tools.ietf.org/area/sec/trac/wiki/SecDirReview


_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.= ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
--_000_A14F8096BB614D96AE48F3CEF790456Femccom_-- From nobody Thu Nov 13 13:11: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 B633F1AD589 for ; Thu, 13 Nov 2014 13:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.715 X-Spam-Level: X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_NEUTRAL=0.779] 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 IpLM-ymR1n_D for ; Thu, 13 Nov 2014 13:10:43 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68EF61AD57B for ; Thu, 13 Nov 2014 13:10:36 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sADLAWpb021112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 13 Nov 2014 23:10:32 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sADLAWXR000005; Thu, 13 Nov 2014 23:10:32 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21605.7751.969402.464467@fireball.kivinen.iki.fi> Date: Thu, 13 Nov 2014 23:10:31 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/i_Q2lUV3yrbiCeP6X_BWkz3_Miw 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 Nov 2014 21:10:50 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Yaron Sheffer is next in the rotation. For telechat 2014-11-25 Reviewer LC end Draft Alan DeKok T 2014-10-21 draft-ietf-tram-alpn-07 Donald Eastlake TR2014-10-30 draft-leiba-cotton-iana-5226bis-11 Dorothy Gellert T 2014-10-27 draft-ietf-manet-ibs-03 Alexey Melnikov T 2014-11-06 draft-ietf-opsawg-mibs-to-ieee80231-01 For telechat 2014-12-04 Sandy Murphy T 2014-11-25 draft-mcdonald-ipps-uri-scheme-16 Last calls and special requests: Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-07 Tero Kivinen E None draft-richardson-6tisch--security-6top-04 Matt Lepinski 2014-11-18 draft-nottingham-safe-hint-05 Catherine Meadows 2014-11-10 draft-ietf-opsawg-capwap-hybridmac-06 Yoav Nir 2014-11-14 draft-ietf-radext-nai-10 Magnus Nystrom 2014-12-01 draft-josefsson-pkix-textual-08 Hilarie Orman E None draft-richardson-6tisch--security-6top-04 Radia Perlman E None draft-ietf-lmap-framework-08 Vincent Roca 2014-11-27 draft-ietf-ccamp-rwa-info-22 Joe Salowey 2014-12-01 draft-ietf-tsvwg-sctp-prpolicies-05 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Hannes Tschofenig 2014-10-07 draft-ietf-lmap-use-cases-05 Sean Turner 2014-10-13 draft-ietf-mpls-lsp-ping-relay-reply-04 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-12 -- kivinen@iki.fi From nobody Thu Nov 13 14:20: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 143FE1ADF33; Thu, 13 Nov 2014 14:20:00 -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 OSJDYaEpZDCV; Thu, 13 Nov 2014 14:19:58 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EEDE1AD6EC; Thu, 13 Nov 2014 14:19:58 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id l15so988592wiw.16 for ; Thu, 13 Nov 2014 14:19:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=0XEqej2vsREgs8x3D5ZicbhS0Port+iU7fFbrJEh1FE=; b=F8Xcf0b8CiAwevxIV6NEaV0DK2W69u/5v4pw2rVtkixK1HRZ6GejkldL28m2Ufj4WT SkJYBzTLZEJqn5fBZQ/UHqc2HIzSjXeZ+E9VwMO6gmuEJWDPCpQoEaAHfampPYOMhfa6 z+Ft4pXvuNcvbSVyKPIivPCBglw0Hf1e1AhPFmvQa1jTu8+HfixQs/ssvh8DIgMk8sbk c51Hci1X60g64rRS5Tv924UMyn/UaT9AhzZCTCdrpMTILIGZc9eHEM8xmJrkEIU3CaEk QVwddfzqawqaovnY/Y1vrDMC1DWkp0boSZObE4JzCNdLKMYwObkQgxfNlsEOEttTyzPA 3DSQ== X-Received: by 10.194.109.69 with SMTP id hq5mr8392123wjb.86.1415917197062; Thu, 13 Nov 2014 14:19:57 -0800 (PST) Received: from dhcp-a75f.meeting.ietf.org (dhcp-a75f.meeting.ietf.org. [31.133.167.95]) by mx.google.com with ESMTPSA id gc7sm37209795wjb.16.2014.11.13.14.19.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 14:19:56 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_E675FBD2-1D56-4DD2-BA8E-34EFE5269B4C" Date: Thu, 13 Nov 2014 12:19:53 -1000 Message-Id: <7DF70E98-A89F-4401-B704-DC6FED6FFDB0@gmail.com> To: draft-ietf-radext-nai.all@tools.ietf.org, IESG Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/sLh0t3ztjikNJzn73X2BryS4q_k Cc: secdir Subject: [secdir] SecDir Review of draft-ietf-radext-nai-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: Thu, 13 Nov 2014 22:20:00 -0000 --Apple-Mail=_E675FBD2-1D56-4DD2-BA8E-34EFE5269B4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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. Summary: Document is ready. Some nits: In section 2.6: Conversion to Unicode as well as normalization SHOULD be performed by edge systems such as laptops that take "local" text as input. These edge systems are best suited to determine the users intent, and can best convert from "local" text to a normalized form. I think it=E2=80=99s weird to use =E2=80=9Claptop=E2=80=9D here, as the = luggability plays no part. =E2=80=9CPC=E2=80=9D would be better. In = fact, I don=E2=80=99t think mobile phones are any different in this = respect. The same section says that Edge systems should normalize text, so AAA = systems should not. It then goes on to say that today edge systems = don=E2=80=99t always normalize text, so the AAA systems should. That=E2=80= =99s a strange way to move forward, unless we=E2=80=99re sure that = double-normalization does not cause problems. The security considerations text is copied from RFC 4282. It still seems = sufficient. This is remarkable considering that privacy is a big part of = it, and privacy was not a hot topic on everyone=E2=80=99s mind in 2005 = when RFC 4282 was written. Yoav= --Apple-Mail=_E675FBD2-1D56-4DD2-BA8E-34EFE5269B4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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.

Summary: Document is ready.

Some nits:

In section 2.6:
Conversion to Unicode = as well as normalization SHOULD be performed by edge systems such as laptops that take "local" text as input. These edge systems are best suited to determine the users intent, and can best convert from "local" text to a normalized form.

I think it=E2=80=99s= weird to use =E2=80=9Claptop=E2=80=9D here, as the luggability plays no = part. =E2=80=9CPC=E2=80=9D would be better. In fact, I don=E2=80=99t = think mobile phones are any different in this respect.


The same section says that Edge systems should normalize = text, so AAA systems should not. It then goes on to say that today edge = systems don=E2=80=99t always normalize text, so the AAA systems should. = That=E2=80=99s a strange way to move forward, unless we=E2=80=99re sure = that double-normalization does not cause problems.

The security = considerations text is copied from RFC 4282. It still seems sufficient. = This is remarkable considering that privacy is a big part of it, and = privacy was not a hot topic on everyone=E2=80=99s mind in 2005 when RFC = 4282 was written.

Yoav
= --Apple-Mail=_E675FBD2-1D56-4DD2-BA8E-34EFE5269B4C-- From nobody Fri Nov 14 06:03: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 584DC1A010D; Fri, 14 Nov 2014 06:02: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 3vhDzHUO0o-S; Fri, 14 Nov 2014 06:02:54 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13E581A0120; Fri, 14 Nov 2014 06:02:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 6546F22402AF; Fri, 14 Nov 2014 15:02:46 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Htu8odFT-oLE; Fri, 14 Nov 2014 15:02:46 +0100 (CET) Received: from Thor.local (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id 943E8224013A; Fri, 14 Nov 2014 15:02:45 +0100 (CET) Message-ID: <54660B84.3060905@deployingradius.com> Date: Fri, 14 Nov 2014 09:02:44 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Yoav Nir References: <7DF70E98-A89F-4401-B704-DC6FED6FFDB0@gmail.com> In-Reply-To: <7DF70E98-A89F-4401-B704-DC6FED6FFDB0@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/77SCuaFCKN3A7Xb6z3d9-zJkrx0 Cc: draft-ietf-radext-nai.all@tools.ietf.org, IESG , secdir Subject: Re: [secdir] SecDir Review of draft-ietf-radext-nai-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 Nov 2014 14:02:57 -0000 Yoav Nir wrote: > Some nits: > > In section 2.6: > > Conversion to Unicode as well as normalization SHOULD be performed by > edge systems such as laptops that take "local" text as input. These > edge systems are best suited to determine the users intent, and can > best convert from "local" text to a normalized form. > > > I think it’s weird to use “laptop†here, as the luggability plays no > part. “PC†would be better. In fact, I don’t think mobile phones are any > different in this respect. True. That could be: ... edge systems (e.g. laptops, desktops, mobile phones, etc.) that ... > The same section says that Edge systems should normalize text, so AAA > systems should not. It then goes on to say that today edge systems don’t > always normalize text, so the AAA systems should. That’s a strange way > to move forward, unless we’re sure that double-normalization does not > cause problems. We can tell that the text is normalized. So there's no possibility to double normalize it. The problem here is that we WANT edge systems to normalize. They should have been normalizing. We had a discussion about this Tuesday in RADEXT. Bernard (as author of EAP - 3579) admitted it was an oversight that the document didn't say EAP-Identity MUST be UTF-8. RADEXT also has interest in working on an EAP document to fix this issue in EAP. So the document has (a) the recommendation for EAP systems to behave properly, and (b) recommendations for what AAA servers should do until the EAP systems are fixed. Alan DeKok. From nobody Fri Nov 14 08:39:47 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 714EF1A1AB1; Fri, 14 Nov 2014 08:29:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1415982573; bh=Ox4Vdk7hzenxHqiLX0FqwXe11VSo4jRj33diDGtHQY8=; 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=kc/FpD8CYwDhQtMC2HD354xJ243EoN7ZImObmmmOxrEK/U++sGc9cJ3aQ/9Bcfkna QjKAn9vAAtGaOI9Qi+oQspx1UFgf1vLvgIguWBL/sCrZrV2pqUA6CVbt/IX2sCWSUa pammK/9yx6jYDY0a3R51fh7e8rqMS7SXDVUjGYLQ= 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 250911A1AAF for ; Fri, 14 Nov 2014 08:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 SnzdxXHmU9zB for ; Fri, 14 Nov 2014 08:29:29 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9A5C1A1AB4 for ; Fri, 14 Nov 2014 08:29:28 -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 1XpJkV-0006aL-9Y; Fri, 14 Nov 2014 11:29:27 -0500 To: new-work@ietf.org Date: Fri, 14 Nov 2014 17:29:23 +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/so-AtvWwFxUp919BHPccbmCFky0 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/K7dycttU-Z9lCy1wWqVH_f4UXG0 X-Mailman-Approved-At: Fri, 14 Nov 2014 08:39:27 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Web of Things Interest Group (until 2014-12-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 Nov 2014 16:29:33 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Web of Things Interest Group: http://www.w3.org/2014/09/wot-ig-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2014-12-15 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 Dave Raggett, Staff Contact . Thank you, Coralie Mercier, W3C Communications [1] http://www.w3.org/2014/Process-20140801/#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 Mon Nov 17 21:39: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 647681AC447; Mon, 17 Nov 2014 21:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 0uIx2yRVr2j6; Mon, 17 Nov 2014 21:39:26 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943551A00D0; Mon, 17 Nov 2014 21:39:25 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id gq15so3769280lab.20 for ; Mon, 17 Nov 2014 21:39: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=66byMaXb08HlXC0BhKMNEgQOKYpKbI7ZQU3ZXjzWpkg=; b=fYxNFXd2ol1kz9iGW6l1w0Q6FNhkXq3C7eg6F4u9kzFAPKZW014YDoO6cML34KdeRn XUwBXJYaIZ353TmKehe7iI4lLbrhjUWeIbvPOcyRcg5qgqqakwzN1sV8BTaCg61H5QQQ 9WEa7FU7VBCosLEouBPA4YHRsKKX8EqA7RfgKU6vCNSYqbxYN2oCNqrtRy5/sdBVuXep pUErth3WxFAwCpadp7xnIEtGCvY1QqaOmSL8dxJNb1KA97EDDfOwc2qd6xkO7B94/W2z 2fC92S7XOi5NdPBSFD8S2Yc+GlUsBfpKHihl0y2H2q9PTl+Dzi/wtP4erywWlk/TjFXr Pc/A== MIME-Version: 1.0 X-Received: by 10.152.5.6 with SMTP id o6mr33481892lao.8.1416289163694; Mon, 17 Nov 2014 21:39:23 -0800 (PST) Received: by 10.112.16.168 with HTTP; Mon, 17 Nov 2014 21:39:23 -0800 (PST) Date: Mon, 17 Nov 2014 21:39:23 -0800 Message-ID: From: Radia Perlman To: "secdir@ietf.org" , The IESG , draft-ietf-lmap-framework.all@tools.ietf.org Content-Type: multipart/alternative; boundary=089e01419d1a8056dd05081b8452 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/J-cvIMuDJPPdon4BmhVI41Af86M Subject: [secdir] Secdir review of draft-ietf-lmap-framework-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: Tue, 18 Nov 2014 05:39:29 -0000 --089e01419d1a8056dd05081b8452 Content-Type: text/plain; charset=UTF-8 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. Summary: It's fine, though I couldn't resist making a few suggestions. LMAP is apparently a strained acronym for "Large-scale Measurement of Access network Performance", a collection of protocols designed for measuring the capacity and responsiveness of connectivity provided by broadband ISPs, though there may have been some feature creep as the protocols are sufficiently general to be used for other things. This document is a framework document defining terms and providing an overview of the intended deployment model (and intended to be INFORMATIONAL). There are companion I-Ds specifying individual protocols in more detail. As such, most of the security considerations would be discussed in those documents, though this overview document provides an overview of the types of security considerations to be discussed in those documents. The major components of LMAP are a Measurement Agent (MA) usually residing on customer premises that runs periodic performance tests and reports results, a Controller usually residing off-customer-premises that configures some large collection of Measurement Agents, and a Collector usually residing off-customer-premises that receives and records reports from the Measurement Agents. Those reports may contain statistical data concerning normal operation of the MA's platform as well as the results of specific tests. It is the Controller to MA and MA to Collector protocols that will require rigorous security analysis and which are specified in different documents within LMAP. The protocols whose performance is measured may also require a rigorous security analysis, but they are defined outside of LMAP. The security considerations section lists the sorts of issues that will need to be dealt with in the other documents. It does not go into how those issues are addressed; presumably the companion documents do. There is a much longer privacy considerations section that enumerates an intimidating set of potential privacy abuses that need to be mitigated. An important security consideration that I didn't see was dealing with the case of a corrupted MA that reports falsified information to the collector. This might occur in the case where a customer wants it to appear that the ISP is not meeting its commitments when in fact the ISP is. Whether this can be effectively mitigated depends on the platform on which the MA is deployed, but where the MA is deployed on a customer-controlled platform it must be recognized that the data collected is to some degree inherently untrustworthy. This means, for example, that in such configurations the data should not be used as the basis for a customer to get refunds of subscription fees. I saw two questionable aspects of the design (at this level of abstraction). The first has to do with who initiates the Controller to MA connection. This spec seems to imply that the connection can be initiated from either end... the Controller can initiate a connection to the MA when it wants to update the MA's configuration and the MA and initiate a connection to the controller to report errors and log debugging information. This is problematic for several reasons. Most importantly, in many scenarios the MA might move around and therefore be difficult for the Controller to find; or it might be behind a NAT or other firewall and might not be capable of accepting incoming connections (at least not without a lot of additional effort). If all such connections were initiated by the MA, including a polling interval configured by the controller, such configuration issues go away. Alternately, if the Controller initiated all connections, it becomes much easier to protect the Controller from DoS attacks, since it is generally much easier to attack a server than a client. But having connections being initiated from both directions gives the worst of both worlds. The second has to do with the MA sending error and log reports to the Controller. While it makes sense for the MA to report errors that occur in processing Controller Instructions in the responses to those commands, errors and logged events that occur asynchronously would seem (to me anyway) as more naturally being sent to the Collector, since its job is to harvest massive amounts of information from lots of MAs. It is likely to be more highly replicated and load balanced than the Controller, and thus more capable of handling bursty loads. But this has little to do with security, and I throw it out only for your consideration. Radia --089e01419d1a8056dd05081b8452 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I hav= e reviewed this document as part of the security directorate's ongoing<= br>effort to review all IETF documents being processed by the IESG.=C2=A0 D= ocument
editors and WG chairs should treat these comments just like any = other last
call comments.

Summary: It's fine, though I couldn= 't resist making a few suggestions.

LMAP is apparently a straine= d acronym for "Large-scale Measurement of Access
network Performanc= e", a collection of protocols designed for measuring the
capacity a= nd responsiveness of connectivity provided by broadband ISPs,
though the= re may have been some feature creep as the protocols are
sufficiently ge= neral to be used for other things. This document is a
framework document= defining terms and providing an overview of the intended
deployment mod= el (and intended to be INFORMATIONAL). There are companion
I-Ds specifyi= ng individual protocols in more detail. As such, most of the
security co= nsiderations would be discussed in those documents, though this
overview= document provides an overview of the types of security
considerations t= o be discussed in those documents.

The major components of LMAP are = a Measurement Agent (MA) usually residing
on customer premises that runs= periodic performance tests and reports
results, a Controller usually re= siding off-customer-premises that configures
some large collection of Me= asurement Agents, and a Collector usually
residing off-customer-premises= that receives and records reports from the
Measurement Agents. Those re= ports may contain statistical data concerning
normal operation of the MA= 's platform as well as the results of specific
tests. It is the Cont= roller to MA and MA to Collector protocols that will
require rigorous se= curity analysis and which are specified in different
documents within LM= AP. The protocols whose performance is measured may also
require a rigor= ous security analysis, but they are defined outside of LMAP.

The sec= urity considerations section lists the sorts of issues that will need
to= be dealt with in the other documents. It does not go into how those
iss= ues are addressed; presumably the companion documents do. There is a muchlonger privacy considerations section that enumerates an intimidating set= of
potential privacy abuses that need to be mitigated.

An import= ant security consideration that I didn't see was dealing with the
ca= se of a corrupted MA that reports falsified information to the collector.This might occur in the case where a customer wants it to appear that the=
ISP is not meeting its commitments when in fact the ISP is. Whether thi= s can
be effectively mitigated depends on the platform on which the MA i= s
deployed, but where the MA is deployed on a customer-controlled platfo= rm it
must be recognized that the data collected is to some degree inher= ently
untrustworthy. This means, for example, that in such configuration= s the data
should not be used as the basis for a customer to get refunds= of
subscription fees.

I saw two questionable aspects of the desi= gn (at this level of abstraction).

The first has to do with who init= iates the Controller to MA connection. This
spec seems to imply that the= connection can be initiated from either end...
the Controller can initi= ate a connection to the MA when it wants to update
the MA's configur= ation and the MA and initiate a connection to the
controller to report e= rrors and log debugging information. This is
problematic for several rea= sons. Most importantly, in many scenarios the MA
might move around and t= herefore be difficult for the Controller to find; or
it might be behind = a NAT or other firewall and might not be capable of
accepting incoming c= onnections (at least not without a lot of additional
effort). If all suc= h connections were initiated by the MA, including a
polling interval con= figured by the controller, such configuration issues go
away.

Alt= ernately, if the Controller initiated all connections, it becomes much
e= asier to protect the Controller from DoS attacks, since it is generally
= much easier to attack a server than a client. But having connections being<= br>initiated from both directions gives the worst of both worlds.

Th= e second has to do with the MA sending error and log reports to the
Cont= roller. While it makes sense for the MA to report errors that occur in
p= rocessing Controller Instructions in the responses to those commands,
er= rors and logged events that occur asynchronously would seem (to me anyway)<= br>as more naturally being sent to the Collector, since its job is to harve= st
massive amounts of information from lots of MAs. It is likely to be m= ore
highly replicated and load balanced than the Controller, and thus mo= re
capable of handling bursty loads. But this has little to do with secu= rity,
and I throw it out only for your consideration.

Radia
--089e01419d1a8056dd05081b8452-- From nobody Tue Nov 18 04:30: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 5C92D1A037F; Tue, 18 Nov 2014 04:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeoSINjBEuIr; Tue, 18 Nov 2014 04:30:43 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EFC21A037C; Tue, 18 Nov 2014 04:30:42 -0800 (PST) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 18 Nov 2014 12:30:42 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.213]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Tue, 18 Nov 2014 12:30:29 +0000 From: To: , , , Date: Tue, 18 Nov 2014 12:30:27 +0000 Thread-Topic: Secdir review of draft-ietf-lmap-framework-08 Thread-Index: AdAC8ivFtJZTcPlaRcqnJbxetNthEQAOF+Bw Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413A791BFCEMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/-wz_CAIHbYrZL3lDb4lrTIjSwSA Subject: Re: [secdir] Secdir review of draft-ietf-lmap-framework-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: Tue, 18 Nov 2014 12:30:47 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413A791BFCEMV67UKRDdoma_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmFkaWEsDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIHJldmlldy4NClNvbWUgY29tbWVu dHMgaW4tbGluZQ0KDQpCZXN0IHdpc2hlcywNClBoaWwNCg0KLS0tLS0tDQpGcm9tOiBSYWRpYSBQ ZXJsbWFuIFttYWlsdG86cmFkaWFwZXJsbWFuQGdtYWlsLmNvbV0NClNlbnQ6IDE4IE5vdmVtYmVy IDIwMTQgMDU6MzkNClRvOiBzZWNkaXJAaWV0Zi5vcmc7IFRoZSBJRVNHOyBkcmFmdC1pZXRmLWxt YXAtZnJhbWV3b3JrLmFsbEB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogU2VjZGlyIHJldmlldyBv ZiBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTA4DQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRv Y3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZw0KZWZm b3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJ RVNHLiAgRG9jdW1lbnQNCmVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2Ug Y29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0DQpjYWxsIGNvbW1lbnRzLg0KDQpTdW1t YXJ5OiBJdCdzIGZpbmUsIHRob3VnaCBJIGNvdWxkbid0IHJlc2lzdCBtYWtpbmcgYSBmZXcgc3Vn Z2VzdGlvbnMuDQoNCkxNQVAgaXMgYXBwYXJlbnRseSBhIHN0cmFpbmVkIGFjcm9ueW0gZm9yICJM YXJnZS1zY2FsZSBNZWFzdXJlbWVudCBvZiBBY2Nlc3MNCm5ldHdvcmsgUGVyZm9ybWFuY2UiLA0K W3BoaWxdIHN0cmFpbmVkIGluZGVlZC4gQnV0IHRvbyBsYXRlIHRvIGNoYW5nZSB0aGUgYWNyb255 bSENCg0KYSBjb2xsZWN0aW9uIG9mIHByb3RvY29scyBkZXNpZ25lZCBmb3IgbWVhc3VyaW5nIHRo ZQ0KY2FwYWNpdHkgYW5kIHJlc3BvbnNpdmVuZXNzIG9mIGNvbm5lY3Rpdml0eSBwcm92aWRlZCBi eSBicm9hZGJhbmQgSVNQcywNCnRob3VnaCB0aGVyZSBtYXkgaGF2ZSBiZWVuIHNvbWUgZmVhdHVy ZSBjcmVlcCBhcyB0aGUgcHJvdG9jb2xzIGFyZQ0Kc3VmZmljaWVudGx5IGdlbmVyYWwgdG8gYmUg dXNlZCBmb3Igb3RoZXIgdGhpbmdzLiBUaGlzIGRvY3VtZW50IGlzIGENCmZyYW1ld29yayBkb2N1 bWVudCBkZWZpbmluZyB0ZXJtcyBhbmQgcHJvdmlkaW5nIGFuIG92ZXJ2aWV3IG9mIHRoZSBpbnRl bmRlZA0KZGVwbG95bWVudCBtb2RlbCAoYW5kIGludGVuZGVkIHRvIGJlIElORk9STUFUSU9OQUwp LiBUaGVyZSBhcmUgY29tcGFuaW9uDQpJLURzIHNwZWNpZnlpbmcgaW5kaXZpZHVhbCBwcm90b2Nv bHMgaW4gbW9yZSBkZXRhaWwuIEFzIHN1Y2gsIG1vc3Qgb2YgdGhlDQpzZWN1cml0eSBjb25zaWRl cmF0aW9ucyB3b3VsZCBiZSBkaXNjdXNzZWQgaW4gdGhvc2UgZG9jdW1lbnRzLCB0aG91Z2ggdGhp cw0Kb3ZlcnZpZXcgZG9jdW1lbnQgcHJvdmlkZXMgYW4gb3ZlcnZpZXcgb2YgdGhlIHR5cGVzIG9m IHNlY3VyaXR5DQpjb25zaWRlcmF0aW9ucyB0byBiZSBkaXNjdXNzZWQgaW4gdGhvc2UgZG9jdW1l bnRzLg0KDQpUaGUgbWFqb3IgY29tcG9uZW50cyBvZiBMTUFQIGFyZSBhIE1lYXN1cmVtZW50IEFn ZW50IChNQSkgdXN1YWxseSByZXNpZGluZw0Kb24gY3VzdG9tZXIgcHJlbWlzZXMgdGhhdCBydW5z IHBlcmlvZGljIHBlcmZvcm1hbmNlIHRlc3RzIGFuZCByZXBvcnRzDQpyZXN1bHRzLCBhIENvbnRy b2xsZXIgdXN1YWxseSByZXNpZGluZyBvZmYtY3VzdG9tZXItcHJlbWlzZXMgdGhhdCBjb25maWd1 cmVzDQpzb21lIGxhcmdlIGNvbGxlY3Rpb24gb2YgTWVhc3VyZW1lbnQgQWdlbnRzLCBhbmQgYSBD b2xsZWN0b3IgdXN1YWxseQ0KcmVzaWRpbmcgb2ZmLWN1c3RvbWVyLXByZW1pc2VzIHRoYXQgcmVj ZWl2ZXMgYW5kIHJlY29yZHMgcmVwb3J0cyBmcm9tIHRoZQ0KTWVhc3VyZW1lbnQgQWdlbnRzLiBU aG9zZSByZXBvcnRzIG1heSBjb250YWluIHN0YXRpc3RpY2FsIGRhdGEgY29uY2VybmluZw0Kbm9y bWFsIG9wZXJhdGlvbiBvZiB0aGUgTUEncyBwbGF0Zm9ybSBhcyB3ZWxsIGFzIHRoZSByZXN1bHRz IG9mIHNwZWNpZmljDQp0ZXN0cy4gSXQgaXMgdGhlIENvbnRyb2xsZXIgdG8gTUEgYW5kIE1BIHRv IENvbGxlY3RvciBwcm90b2NvbHMgdGhhdCB3aWxsDQpyZXF1aXJlIHJpZ29yb3VzIHNlY3VyaXR5 IGFuYWx5c2lzIGFuZCB3aGljaCBhcmUgc3BlY2lmaWVkIGluIGRpZmZlcmVudA0KZG9jdW1lbnRz IHdpdGhpbiBMTUFQLg0KW3BoaWxdIHRvIG5vdGUgaW4gcGFzc2luZywgdGhleSBtYXkgYmUgdGhl IHNhbWUgb3IgZGlmZmVyZW50IHByb3RvY29sICh0aGlzIGlzIHRvIGJlIGRlY2lkZWQpDQoNClRo ZSBwcm90b2NvbHMgd2hvc2UgcGVyZm9ybWFuY2UgaXMgbWVhc3VyZWQgbWF5IGFsc28NCnJlcXVp cmUgYSByaWdvcm91cyBzZWN1cml0eSBhbmFseXNpcywgYnV0IHRoZXkgYXJlIGRlZmluZWQgb3V0 c2lkZSBvZiBMTUFQLg0KDQpUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBsaXN0 cyB0aGUgc29ydHMgb2YgaXNzdWVzIHRoYXQgd2lsbCBuZWVkDQp0byBiZSBkZWFsdCB3aXRoIGlu IHRoZSBvdGhlciBkb2N1bWVudHMuIEl0IGRvZXMgbm90IGdvIGludG8gaG93IHRob3NlDQppc3N1 ZXMgYXJlIGFkZHJlc3NlZDsgcHJlc3VtYWJseSB0aGUgY29tcGFuaW9uIGRvY3VtZW50cyBkby4N CltwaGlsXSBjb3JyZWN0LCB0aGUgcHJvdG9jb2wgZG9jKHMpIHdpbGwgaGF2ZSB0byBjb3ZlciB0 aGlzDQoNClRoZXJlIGlzIGEgbXVjaA0KbG9uZ2VyIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgc2Vj dGlvbiB0aGF0IGVudW1lcmF0ZXMgYW4gaW50aW1pZGF0aW5nIHNldCBvZg0KcG90ZW50aWFsIHBy aXZhY3kgYWJ1c2VzIHRoYXQgbmVlZCB0byBiZSBtaXRpZ2F0ZWQuDQoNCkFuIGltcG9ydGFudCBz ZWN1cml0eSBjb25zaWRlcmF0aW9uIHRoYXQgSSBkaWRuJ3Qgc2VlIHdhcyBkZWFsaW5nIHdpdGgg dGhlDQpjYXNlIG9mIGEgY29ycnVwdGVkIE1BIHRoYXQgcmVwb3J0cyBmYWxzaWZpZWQgaW5mb3Jt YXRpb24gdG8gdGhlIGNvbGxlY3Rvci4NClRoaXMgbWlnaHQgb2NjdXIgaW4gdGhlIGNhc2Ugd2hl cmUgYSBjdXN0b21lciB3YW50cyBpdCB0byBhcHBlYXIgdGhhdCB0aGUNCklTUCBpcyBub3QgbWVl dGluZyBpdHMgY29tbWl0bWVudHMgd2hlbiBpbiBmYWN0IHRoZSBJU1AgaXMuIFdoZXRoZXIgdGhp cyBjYW4NCmJlIGVmZmVjdGl2ZWx5IG1pdGlnYXRlZCBkZXBlbmRzIG9uIHRoZSBwbGF0Zm9ybSBv biB3aGljaCB0aGUgTUEgaXMNCmRlcGxveWVkLCBidXQgd2hlcmUgdGhlIE1BIGlzIGRlcGxveWVk IG9uIGEgY3VzdG9tZXItY29udHJvbGxlZCBwbGF0Zm9ybSBpdA0KbXVzdCBiZSByZWNvZ25pemVk IHRoYXQgdGhlIGRhdGEgY29sbGVjdGVkIGlzIHRvIHNvbWUgZGVncmVlIGluaGVyZW50bHkNCnVu dHJ1c3R3b3J0aHkuIFRoaXMgbWVhbnMsIGZvciBleGFtcGxlLCB0aGF0IGluIHN1Y2ggY29uZmln dXJhdGlvbnMgdGhlIGRhdGENCnNob3VsZCBub3QgYmUgdXNlZCBhcyB0aGUgYmFzaXMgZm9yIGEg Y3VzdG9tZXIgdG8gZ2V0IHJlZnVuZHMgb2YNCnN1YnNjcmlwdGlvbiBmZWVzLg0KDQpbcGhpbF0g R29vZCBwb2ludC4gRXZlbiBpZiBzb21laG93IHRoZSBNQSBpcyBwcmV2ZW50ZWQgZnJvbSBpbmpl Y3RpbmcgZmFsc2lmaWVkIHJlcG9ydHMsIGEgc29waGlzdGljYXRlZCBjdXN0b21lciBjb3VsZCBk aXN0b3J0IHRoZSBtZWFzdXJlbWVudHMgKGVnIGFkZCBib3ggdGhhdCBkcm9wcyBwYWNrZXRzKQ0K SSB3aWxsIGFkZCBzb21ldGhpbmcgYWJvdXQgdGhpcy4gdGhhbmtzLg0KDQoNCkkgc2F3IHR3byBx dWVzdGlvbmFibGUgYXNwZWN0cyBvZiB0aGUgZGVzaWduIChhdCB0aGlzIGxldmVsIG9mIGFic3Ry YWN0aW9uKS4NCg0KVGhlIGZpcnN0IGhhcyB0byBkbyB3aXRoIHdobyBpbml0aWF0ZXMgdGhlIENv bnRyb2xsZXIgdG8gTUEgY29ubmVjdGlvbi4gVGhpcw0Kc3BlYyBzZWVtcyB0byBpbXBseSB0aGF0 IHRoZSBjb25uZWN0aW9uIGNhbiBiZSBpbml0aWF0ZWQgZnJvbSBlaXRoZXIgZW5kLi4uDQp0aGUg Q29udHJvbGxlciBjYW4gaW5pdGlhdGUgYSBjb25uZWN0aW9uIHRvIHRoZSBNQSB3aGVuIGl0IHdh bnRzIHRvIHVwZGF0ZQ0KdGhlIE1BJ3MgY29uZmlndXJhdGlvbiBhbmQgdGhlIE1BIGFuZCBpbml0 aWF0ZSBhIGNvbm5lY3Rpb24gdG8gdGhlDQpjb250cm9sbGVyIHRvIHJlcG9ydCBlcnJvcnMgYW5k IGxvZyBkZWJ1Z2dpbmcgaW5mb3JtYXRpb24uIFRoaXMgaXMNCnByb2JsZW1hdGljIGZvciBzZXZl cmFsIHJlYXNvbnMuIE1vc3QgaW1wb3J0YW50bHksIGluIG1hbnkgc2NlbmFyaW9zIHRoZSBNQQ0K bWlnaHQgbW92ZSBhcm91bmQgYW5kIHRoZXJlZm9yZSBiZSBkaWZmaWN1bHQgZm9yIHRoZSBDb250 cm9sbGVyIHRvIGZpbmQ7IG9yDQppdCBtaWdodCBiZSBiZWhpbmQgYSBOQVQgb3Igb3RoZXIgZmly ZXdhbGwgYW5kIG1pZ2h0IG5vdCBiZSBjYXBhYmxlIG9mDQphY2NlcHRpbmcgaW5jb21pbmcgY29u bmVjdGlvbnMgKGF0IGxlYXN0IG5vdCB3aXRob3V0IGEgbG90IG9mIGFkZGl0aW9uYWwNCmVmZm9y dCkuIElmIGFsbCBzdWNoIGNvbm5lY3Rpb25zIHdlcmUgaW5pdGlhdGVkIGJ5IHRoZSBNQSwgaW5j bHVkaW5nIGENCnBvbGxpbmcgaW50ZXJ2YWwgY29uZmlndXJlZCBieSB0aGUgY29udHJvbGxlciwg c3VjaCBjb25maWd1cmF0aW9uIGlzc3VlcyBnbw0KYXdheS4NCg0KQWx0ZXJuYXRlbHksIGlmIHRo ZSBDb250cm9sbGVyIGluaXRpYXRlZCBhbGwgY29ubmVjdGlvbnMsIGl0IGJlY29tZXMgbXVjaA0K ZWFzaWVyIHRvIHByb3RlY3QgdGhlIENvbnRyb2xsZXIgZnJvbSBEb1MgYXR0YWNrcywgc2luY2Ug aXQgaXMgZ2VuZXJhbGx5DQptdWNoIGVhc2llciB0byBhdHRhY2sgYSBzZXJ2ZXIgdGhhbiBhIGNs aWVudC4gQnV0IGhhdmluZyBjb25uZWN0aW9ucyBiZWluZw0KaW5pdGlhdGVkIGZyb20gYm90aCBk aXJlY3Rpb25zIGdpdmVzIHRoZSB3b3JzdCBvZiBib3RoIHdvcmxkcy4NCg0KW3BoaWxdICBXZeKA mXZlIGRpc2N1c3NlZCB0aGlzIGEgYml0IChmb3IgZXhhbXBsZSwgbmVhciB0aGUgZW5kIG9mIHRo ZSBEdWJsaW4gaW50ZXJpbSkuIEkgdGhpbmsgcGVvcGxlIGZhdm91ciB0aGUgZm9ybWVyIGFwcHJv YWNoIOKAkyB0aGUgTUEgcmVndWxhcmx5IGNhbGxzIGluIHRvIGNoZWNrIGlmIHRoZSBjb25maWcg L2luc3RydWN0aW9uIGhhcyBjaGFuZ2VkLg0KDQpJ4oCZbSBub3Qgc3VyZSB3aGV0aGVyIHRoaXMg ZG9jIHNob3VsZCBzdGF0ZSB0aGF0LCBvciBnaXZlIHRoZSBwcm9zIGFuZCBjb25zICh5b3VyIHRl eHQgYWJvdmUpIOKAkyB0aGUgbGF0dGVyIHdvdWxkIGJlIHRoZSBkZWZhdWx0LCB0aG91Z2ggcGVy c29uYWxseSBJIHdvdWxkbuKAmXQgbWluZCBpZiB3ZSBzYWlkIHRoZSBmb3JtZXIuIFdoYXQgYXBw cm9hY2ggZG8gcGVvcGxlIHByZWZlcj8NCg0KDQpUaGUgc2Vjb25kIGhhcyB0byBkbyB3aXRoIHRo ZSBNQSBzZW5kaW5nIGVycm9yIGFuZCBsb2cgcmVwb3J0cyB0byB0aGUNCkNvbnRyb2xsZXIuIFdo aWxlIGl0IG1ha2VzIHNlbnNlIGZvciB0aGUgTUEgdG8gcmVwb3J0IGVycm9ycyB0aGF0IG9jY3Vy IGluDQpwcm9jZXNzaW5nIENvbnRyb2xsZXIgSW5zdHJ1Y3Rpb25zIGluIHRoZSByZXNwb25zZXMg dG8gdGhvc2UgY29tbWFuZHMsDQplcnJvcnMgYW5kIGxvZ2dlZCBldmVudHMgdGhhdCBvY2N1ciBh c3luY2hyb25vdXNseSB3b3VsZCBzZWVtICh0byBtZSBhbnl3YXkpDQphcyBtb3JlIG5hdHVyYWxs eSBiZWluZyBzZW50IHRvIHRoZSBDb2xsZWN0b3IsIHNpbmNlIGl0cyBqb2IgaXMgdG8gaGFydmVz dA0KbWFzc2l2ZSBhbW91bnRzIG9mIGluZm9ybWF0aW9uIGZyb20gbG90cyBvZiBNQXMuIEl0IGlz IGxpa2VseSB0byBiZSBtb3JlDQpoaWdobHkgcmVwbGljYXRlZCBhbmQgbG9hZCBiYWxhbmNlZCB0 aGFuIHRoZSBDb250cm9sbGVyLCBhbmQgdGh1cyBtb3JlDQpjYXBhYmxlIG9mIGhhbmRsaW5nIGJ1 cnN0eSBsb2Fkcy4gQnV0IHRoaXMgaGFzIGxpdHRsZSB0byBkbyB3aXRoIHNlY3VyaXR5LA0KYW5k IEkgdGhyb3cgaXQgb3V0IG9ubHkgZm9yIHlvdXIgY29uc2lkZXJhdGlvbi4NCg0KW3BoaWxdIEkg Z3Vlc3MgaXQgZGVwZW5kcyBob3cgbXVjaCB0cmFmZmljIGlzIGdlbmVyYXRlZCDigJMgaW4gZ2Vu ZXJhbCBJIGRvbuKAmXQgdGhpbmsgdGhlcmXigJlsbCBiZSBtdWNoLCBzbyBJ4oCZbSBpbmNsaW5l ZCB0byBkaXNhZ3JlZS4NCk5vdGUgaWYgdGhlIENvbGxlY3RvciBkaWQgZ2V0IHRoaXMgaW5mb3Jt YXRpb24sIHRoZSBDb250cm9sbGVyIHdvdWxkIGhhdmUgdG8gYmUgdG9sZCBhdCBsZWFzdCBhIHN1 bW1hcnksIHNvIGl0IGNvdWxkIG1vZGlmeSB0aGUgaW5zdHJ1Y3Rpb25zIGFzIGFwcHJvcHJpYXRl LiAoQSBjb250cm9sbGVyLWNvbGxlY3RvciBpbnRlcmZhY2UgaXMgb3V0IG9mIHNjb3BlLCBhdCB0 aGlzIHN0YWdlLikNCkFueSB0aG91Z2h0cz8NClJhZGlhDQoNCg== --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413A791BFCEMV67UKRDdoma_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6Ymx1ZTsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4 dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5n PUVOLUdCIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PGRp diBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgaWQ9IjozeGUiPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjpibHVlJz5SYWRpYSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5U aGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIHJldmlldy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjpibHVlJz5Tb21lIGNvbW1lbnRzIGluLWxpbmUgPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6Ymx1ZSc+QmVzdCB3aXNoZXMsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6Ymx1ZSc+UGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJs dWUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPi0tLS0t LTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IFJhZGlhIFBlcmxtYW4g W21haWx0bzpyYWRpYXBlcmxtYW5AZ21haWwuY29tXSA8YnI+PGI+U2VudDo8L2I+IDE4IE5vdmVt YmVyIDIwMTQgMDU6Mzk8YnI+PGI+VG86PC9iPiBzZWNkaXJAaWV0Zi5vcmc7IFRoZSBJRVNHOyBk cmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLmFsbEB0b29scy5pZXRmLm9yZzxicj48Yj5TdWJqZWN0 OjwvYj4gU2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTA4PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIic+SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMg cGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nPGJyPmVmZm9ydCB0byBy ZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4mbmJz cDsgRG9jdW1lbnQ8YnI+ZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBj b21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3Q8YnI+Y2FsbCBjb21tZW50cy48YnI+PGJy PlN1bW1hcnk6IEl0J3MgZmluZSwgdGhvdWdoIEkgY291bGRuJ3QgcmVzaXN0IG1ha2luZyBhIGZl dyBzdWdnZXN0aW9ucy48YnI+PGJyPkxNQVAgaXMgYXBwYXJlbnRseSBhIHN0cmFpbmVkIGFjcm9u eW0gZm9yICZxdW90O0xhcmdlLXNjYWxlIE1lYXN1cmVtZW50IG9mIEFjY2Vzczxicj5uZXR3b3Jr IFBlcmZvcm1hbmNlJnF1b3Q7LCA8c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZSc+PG86cD48L286cD48 L3NwYW4+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPltwaGlsXSBzdHJhaW5lZCBpbmRl ZWQuIEJ1dCB0b28gbGF0ZSB0byBjaGFuZ2UgdGhlIGFjcm9ueW0hPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiJz5hIGNvbGxlY3Rpb24gb2YgcHJvdG9jb2xzIGRlc2lnbmVkIGZv ciBtZWFzdXJpbmcgdGhlPGJyPmNhcGFjaXR5IGFuZCByZXNwb25zaXZlbmVzcyBvZiBjb25uZWN0 aXZpdHkgcHJvdmlkZWQgYnkgYnJvYWRiYW5kIElTUHMsPGJyPnRob3VnaCB0aGVyZSBtYXkgaGF2 ZSBiZWVuIHNvbWUgZmVhdHVyZSBjcmVlcCBhcyB0aGUgcHJvdG9jb2xzIGFyZTxicj5zdWZmaWNp ZW50bHkgZ2VuZXJhbCB0byBiZSB1c2VkIGZvciBvdGhlciB0aGluZ3MuIFRoaXMgZG9jdW1lbnQg aXMgYTxicj5mcmFtZXdvcmsgZG9jdW1lbnQgZGVmaW5pbmcgdGVybXMgYW5kIHByb3ZpZGluZyBh biBvdmVydmlldyBvZiB0aGUgaW50ZW5kZWQ8YnI+ZGVwbG95bWVudCBtb2RlbCAoYW5kIGludGVu ZGVkIHRvIGJlIElORk9STUFUSU9OQUwpLiBUaGVyZSBhcmUgY29tcGFuaW9uPGJyPkktRHMgc3Bl Y2lmeWluZyBpbmRpdmlkdWFsIHByb3RvY29scyBpbiBtb3JlIGRldGFpbC4gQXMgc3VjaCwgbW9z dCBvZiB0aGU8YnI+c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgd291bGQgYmUgZGlzY3Vzc2VkIGlu IHRob3NlIGRvY3VtZW50cywgdGhvdWdoIHRoaXM8YnI+b3ZlcnZpZXcgZG9jdW1lbnQgcHJvdmlk ZXMgYW4gb3ZlcnZpZXcgb2YgdGhlIHR5cGVzIG9mIHNlY3VyaXR5PGJyPmNvbnNpZGVyYXRpb25z IHRvIGJlIGRpc2N1c3NlZCBpbiB0aG9zZSBkb2N1bWVudHMuPGJyPjxicj5UaGUgbWFqb3IgY29t cG9uZW50cyBvZiBMTUFQIGFyZSBhIE1lYXN1cmVtZW50IEFnZW50IChNQSkgdXN1YWxseSByZXNp ZGluZzxicj5vbiBjdXN0b21lciBwcmVtaXNlcyB0aGF0IHJ1bnMgcGVyaW9kaWMgcGVyZm9ybWFu Y2UgdGVzdHMgYW5kIHJlcG9ydHM8YnI+cmVzdWx0cywgYSBDb250cm9sbGVyIHVzdWFsbHkgcmVz aWRpbmcgb2ZmLWN1c3RvbWVyLXByZW1pc2VzIHRoYXQgY29uZmlndXJlczxicj5zb21lIGxhcmdl IGNvbGxlY3Rpb24gb2YgTWVhc3VyZW1lbnQgQWdlbnRzLCBhbmQgYSBDb2xsZWN0b3IgdXN1YWxs eTxicj5yZXNpZGluZyBvZmYtY3VzdG9tZXItcHJlbWlzZXMgdGhhdCByZWNlaXZlcyBhbmQgcmVj b3JkcyByZXBvcnRzIGZyb20gdGhlPGJyPk1lYXN1cmVtZW50IEFnZW50cy4gVGhvc2UgcmVwb3J0 cyBtYXkgY29udGFpbiBzdGF0aXN0aWNhbCBkYXRhIGNvbmNlcm5pbmc8YnI+bm9ybWFsIG9wZXJh dGlvbiBvZiB0aGUgTUEncyBwbGF0Zm9ybSBhcyB3ZWxsIGFzIHRoZSByZXN1bHRzIG9mIHNwZWNp ZmljPGJyPnRlc3RzLiBJdCBpcyB0aGUgQ29udHJvbGxlciB0byBNQSBhbmQgTUEgdG8gQ29sbGVj dG9yIHByb3RvY29scyB0aGF0IHdpbGw8YnI+cmVxdWlyZSByaWdvcm91cyBzZWN1cml0eSBhbmFs eXNpcyBhbmQgd2hpY2ggYXJlIHNwZWNpZmllZCBpbiBkaWZmZXJlbnQ8YnI+ZG9jdW1lbnRzIHdp dGhpbiBMTUFQLiA8c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZSc+PG86cD48L286cD48L3NwYW4+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPltwaGlsXSB0byBub3RlIGluIHBhc3NpbmcsIHRo ZXkgbWF5IGJlIHRoZSBzYW1lIG9yIGRpZmZlcmVudCBwcm90b2NvbCAodGhpcyBpcyB0byBiZSBk ZWNpZGVkKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo5LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+VGhlIHByb3RvY29s cyB3aG9zZSBwZXJmb3JtYW5jZSBpcyBtZWFzdXJlZCBtYXkgYWxzbzxicj5yZXF1aXJlIGEgcmln b3JvdXMgc2VjdXJpdHkgYW5hbHlzaXMsIGJ1dCB0aGV5IGFyZSBkZWZpbmVkIG91dHNpZGUgb2Yg TE1BUC48YnI+PGJyPlRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGxpc3RzIHRo ZSBzb3J0cyBvZiBpc3N1ZXMgdGhhdCB3aWxsIG5lZWQ8YnI+dG8gYmUgZGVhbHQgd2l0aCBpbiB0 aGUgb3RoZXIgZG9jdW1lbnRzLiBJdCBkb2VzIG5vdCBnbyBpbnRvIGhvdyB0aG9zZTxicj5pc3N1 ZXMgYXJlIGFkZHJlc3NlZDsgcHJlc3VtYWJseSB0aGUgY29tcGFuaW9uIGRvY3VtZW50cyBkby4g PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWUnPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjtjb2xvcjpibHVlJz5bcGhpbF0gY29ycmVjdCwgdGhlIHByb3RvY29sIGRvYyhzKSB3aWxs IGhhdmUgdG8gY292ZXIgdGhpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJs dWUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+ VGhlcmUgaXMgYSBtdWNoPGJyPmxvbmdlciBwcml2YWN5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24g dGhhdCBlbnVtZXJhdGVzIGFuIGludGltaWRhdGluZyBzZXQgb2Y8YnI+cG90ZW50aWFsIHByaXZh Y3kgYWJ1c2VzIHRoYXQgbmVlZCB0byBiZSBtaXRpZ2F0ZWQuPGJyPjxicj5BbiBpbXBvcnRhbnQg c2VjdXJpdHkgY29uc2lkZXJhdGlvbiB0aGF0IEkgZGlkbid0IHNlZSB3YXMgZGVhbGluZyB3aXRo IHRoZTxicj5jYXNlIG9mIGEgY29ycnVwdGVkIE1BIHRoYXQgcmVwb3J0cyBmYWxzaWZpZWQgaW5m b3JtYXRpb24gdG8gdGhlIGNvbGxlY3Rvci48YnI+VGhpcyBtaWdodCBvY2N1ciBpbiB0aGUgY2Fz ZSB3aGVyZSBhIGN1c3RvbWVyIHdhbnRzIGl0IHRvIGFwcGVhciB0aGF0IHRoZTxicj5JU1AgaXMg bm90IG1lZXRpbmcgaXRzIGNvbW1pdG1lbnRzIHdoZW4gaW4gZmFjdCB0aGUgSVNQIGlzLiBXaGV0 aGVyIHRoaXMgY2FuPGJyPmJlIGVmZmVjdGl2ZWx5IG1pdGlnYXRlZCBkZXBlbmRzIG9uIHRoZSBw bGF0Zm9ybSBvbiB3aGljaCB0aGUgTUEgaXM8YnI+ZGVwbG95ZWQsIGJ1dCB3aGVyZSB0aGUgTUEg aXMgZGVwbG95ZWQgb24gYSBjdXN0b21lci1jb250cm9sbGVkIHBsYXRmb3JtIGl0PGJyPm11c3Qg YmUgcmVjb2duaXplZCB0aGF0IHRoZSBkYXRhIGNvbGxlY3RlZCBpcyB0byBzb21lIGRlZ3JlZSBp bmhlcmVudGx5PGJyPnVudHJ1c3R3b3J0aHkuIFRoaXMgbWVhbnMsIGZvciBleGFtcGxlLCB0aGF0 IGluIHN1Y2ggY29uZmlndXJhdGlvbnMgdGhlIGRhdGE8YnI+c2hvdWxkIG5vdCBiZSB1c2VkIGFz IHRoZSBiYXNpcyBmb3IgYSBjdXN0b21lciB0byBnZXQgcmVmdW5kcyBvZjxicj5zdWJzY3JpcHRp b24gZmVlcy48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZSc+PG86cD48L286cD48L3NwYW4+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOmJsdWUnPltwaGlsXSBHb29kIHBvaW50LiBFdmVuIGlmIHNvbWVob3cgdGhlIE1B IGlzIHByZXZlbnRlZCBmcm9tIGluamVjdGluZyBmYWxzaWZpZWQgcmVwb3J0cywgYSBzb3BoaXN0 aWNhdGVkIGN1c3RvbWVyIGNvdWxkIGRpc3RvcnQgdGhlIG1lYXN1cmVtZW50cyAoZWcgYWRkIGJv eCB0aGF0IGRyb3BzIHBhY2tldHMpPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 Ymx1ZSc+SSB3aWxsIGFkZCBzb21ldGhpbmcgYWJvdXQgdGhpcy4gdGhhbmtzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjVw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PGJyPjxicj5JIHNhdyB0d28gcXVl c3Rpb25hYmxlIGFzcGVjdHMgb2YgdGhlIGRlc2lnbiAoYXQgdGhpcyBsZXZlbCBvZiBhYnN0cmFj dGlvbikuPGJyPjxicj5UaGUgZmlyc3QgaGFzIHRvIGRvIHdpdGggd2hvIGluaXRpYXRlcyB0aGUg Q29udHJvbGxlciB0byBNQSBjb25uZWN0aW9uLiBUaGlzPGJyPnNwZWMgc2VlbXMgdG8gaW1wbHkg dGhhdCB0aGUgY29ubmVjdGlvbiBjYW4gYmUgaW5pdGlhdGVkIGZyb20gZWl0aGVyIGVuZC4uLjxi cj50aGUgQ29udHJvbGxlciBjYW4gaW5pdGlhdGUgYSBjb25uZWN0aW9uIHRvIHRoZSBNQSB3aGVu IGl0IHdhbnRzIHRvIHVwZGF0ZTxicj50aGUgTUEncyBjb25maWd1cmF0aW9uIGFuZCB0aGUgTUEg YW5kIGluaXRpYXRlIGEgY29ubmVjdGlvbiB0byB0aGU8YnI+Y29udHJvbGxlciB0byByZXBvcnQg ZXJyb3JzIGFuZCBsb2cgZGVidWdnaW5nIGluZm9ybWF0aW9uLiBUaGlzIGlzPGJyPnByb2JsZW1h dGljIGZvciBzZXZlcmFsIHJlYXNvbnMuIE1vc3QgaW1wb3J0YW50bHksIGluIG1hbnkgc2NlbmFy aW9zIHRoZSBNQTxicj5taWdodCBtb3ZlIGFyb3VuZCBhbmQgdGhlcmVmb3JlIGJlIGRpZmZpY3Vs dCBmb3IgdGhlIENvbnRyb2xsZXIgdG8gZmluZDsgb3I8YnI+aXQgbWlnaHQgYmUgYmVoaW5kIGEg TkFUIG9yIG90aGVyIGZpcmV3YWxsIGFuZCBtaWdodCBub3QgYmUgY2FwYWJsZSBvZjxicj5hY2Nl cHRpbmcgaW5jb21pbmcgY29ubmVjdGlvbnMgKGF0IGxlYXN0IG5vdCB3aXRob3V0IGEgbG90IG9m IGFkZGl0aW9uYWw8YnI+ZWZmb3J0KS4gSWYgYWxsIHN1Y2ggY29ubmVjdGlvbnMgd2VyZSBpbml0 aWF0ZWQgYnkgdGhlIE1BLCBpbmNsdWRpbmcgYTxicj5wb2xsaW5nIGludGVydmFsIGNvbmZpZ3Vy ZWQgYnkgdGhlIGNvbnRyb2xsZXIsIHN1Y2ggY29uZmlndXJhdGlvbiBpc3N1ZXMgZ288YnI+YXdh eS48YnI+PGJyPkFsdGVybmF0ZWx5LCBpZiB0aGUgQ29udHJvbGxlciBpbml0aWF0ZWQgYWxsIGNv bm5lY3Rpb25zLCBpdCBiZWNvbWVzIG11Y2g8YnI+ZWFzaWVyIHRvIHByb3RlY3QgdGhlIENvbnRy b2xsZXIgZnJvbSBEb1MgYXR0YWNrcywgc2luY2UgaXQgaXMgZ2VuZXJhbGx5PGJyPm11Y2ggZWFz aWVyIHRvIGF0dGFjayBhIHNlcnZlciB0aGFuIGEgY2xpZW50LiBCdXQgaGF2aW5nIGNvbm5lY3Rp b25zIGJlaW5nPGJyPmluaXRpYXRlZCBmcm9tIGJvdGggZGlyZWN0aW9ucyBnaXZlcyB0aGUgd29y c3Qgb2YgYm90aCB3b3JsZHMuPHNwYW4gc3R5bGU9J2NvbG9yOmJsdWUnPjxvOnA+PC9vOnA+PC9z cGFuPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5bcGhpbF3CoCBXZeKAmXZlIGRpc2N1c3NlZCB0aGlz IGEgYml0IChmb3IgZXhhbXBsZSwgbmVhciB0aGUgZW5kIG9mIHRoZSBEdWJsaW4gaW50ZXJpbSku IEkgdGhpbmsgcGVvcGxlIGZhdm91ciB0aGUgZm9ybWVyIGFwcHJvYWNoIOKAkyB0aGUgTUEgcmVn dWxhcmx5IGNhbGxzIGluIHRvIGNoZWNrIGlmIHRoZSBjb25maWcgL2luc3RydWN0aW9uIGhhcyBj aGFuZ2VkLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5J4oCZbSBub3Qgc3VyZSB3 aGV0aGVyIHRoaXMgZG9jIHNob3VsZCBzdGF0ZSB0aGF0LCBvciBnaXZlIHRoZSBwcm9zIGFuZCBj b25zICh5b3VyIHRleHQgYWJvdmUpIOKAkyB0aGUgbGF0dGVyIHdvdWxkIGJlIHRoZSBkZWZhdWx0 LCB0aG91Z2ggcGVyc29uYWxseSBJIHdvdWxkbuKAmXQgbWluZCBpZiB3ZSBzYWlkIHRoZSBmb3Jt ZXIuIFdoYXQgYXBwcm9hY2ggZG8gcGVvcGxlIHByZWZlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS41cHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxicj48YnI+VGhlIHNlY29uZCBoYXMgdG8gZG8gd2l0 aCB0aGUgTUEgc2VuZGluZyBlcnJvciBhbmQgbG9nIHJlcG9ydHMgdG8gdGhlPGJyPkNvbnRyb2xs ZXIuIFdoaWxlIGl0IG1ha2VzIHNlbnNlIGZvciB0aGUgTUEgdG8gcmVwb3J0IGVycm9ycyB0aGF0 IG9jY3VyIGluPGJyPnByb2Nlc3NpbmcgQ29udHJvbGxlciBJbnN0cnVjdGlvbnMgaW4gdGhlIHJl c3BvbnNlcyB0byB0aG9zZSBjb21tYW5kcyw8YnI+ZXJyb3JzIGFuZCBsb2dnZWQgZXZlbnRzIHRo YXQgb2NjdXIgYXN5bmNocm9ub3VzbHkgd291bGQgc2VlbSAodG8gbWUgYW55d2F5KTxicj5hcyBt b3JlIG5hdHVyYWxseSBiZWluZyBzZW50IHRvIHRoZSBDb2xsZWN0b3IsIHNpbmNlIGl0cyBqb2Ig aXMgdG8gaGFydmVzdDxicj5tYXNzaXZlIGFtb3VudHMgb2YgaW5mb3JtYXRpb24gZnJvbSBsb3Rz IG9mIE1Bcy4gSXQgaXMgbGlrZWx5IHRvIGJlIG1vcmU8YnI+aGlnaGx5IHJlcGxpY2F0ZWQgYW5k IGxvYWQgYmFsYW5jZWQgdGhhbiB0aGUgQ29udHJvbGxlciwgYW5kIHRodXMgbW9yZTxicj5jYXBh YmxlIG9mIGhhbmRsaW5nIGJ1cnN0eSBsb2Fkcy4gQnV0IHRoaXMgaGFzIGxpdHRsZSB0byBkbyB3 aXRoIHNlY3VyaXR5LDxicj5hbmQgSSB0aHJvdyBpdCBvdXQgb25seSBmb3IgeW91ciBjb25zaWRl cmF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5b cGhpbF0gSSBndWVzcyBpdCBkZXBlbmRzIGhvdyBtdWNoIHRyYWZmaWMgaXMgZ2VuZXJhdGVkIOKA kyBpbiBnZW5lcmFsIEkgZG9u4oCZdCB0aGluayB0aGVyZeKAmWxsIGJlIG11Y2gsIHNvIEnigJlt IGluY2xpbmVkIHRvIGRpc2FncmVlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9y OmJsdWUnPk5vdGUgaWYgdGhlIENvbGxlY3RvciBkaWQgZ2V0IHRoaXMgaW5mb3JtYXRpb24sIHRo ZSBDb250cm9sbGVyIHdvdWxkIGhhdmUgdG8gYmUgdG9sZCBhdCBsZWFzdCBhIHN1bW1hcnksIHNv IGl0IGNvdWxkIG1vZGlmeSB0aGUgaW5zdHJ1Y3Rpb25zIGFzIGFwcHJvcHJpYXRlLiAoQSBjb250 cm9sbGVyLWNvbGxlY3RvciBpbnRlcmZhY2UgaXMgb3V0IG9mIHNjb3BlLCBhdCB0aGlzIHN0YWdl Lik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5BbnkgdGhvdWdodHM/ PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjVwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+UmFkaWE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D413A791BFCEMV67UKRDdoma_-- From nobody Wed Nov 19 01:07: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 62FFB1ACFC8; Wed, 19 Nov 2014 01:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, 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 DmEfijbTUtab; Wed, 19 Nov 2014 01:07:49 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85731A0059; Wed, 19 Nov 2014 01:07:48 -0800 (PST) Received: from [192.168.131.129] ([80.92.115.84]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MDW9x-1Xjb7N35kT-00GuRd; Wed, 19 Nov 2014 10:07:36 +0100 Message-ID: <546C5DD7.3060900@gmx.net> Date: Wed, 19 Nov 2014 10:07:35 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: secdir@ietf.org, iesg@ietf.org, draft-ietf-lmap-use-cases@tools.ietf.org OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xk9IDHHuSlbfrsExC6MUmQvpItfmOruhg" X-Provags-ID: V03:K0:ArQb+w3k9fohDTnzaUXl50colMuFhc7rNXqwxoRXV9VWsLj9FLs 3+aV1ju+dIfBtLzfP0xIW7lagefxgIe3knpMbQJ/JF+lqT0kxBe5EJRdyIyqpW9z+HsT7IQ TMGZUjk6mp1sjHHGYGuUec9o9TEMpCT/AjmfhR0HDFmfYU0egLCJwVobZJqV6rT2f8X4u/e SFpWufM6pjj5uGm/k20nw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/QS-xmPQC_6CwRn9INxWVUxxlq9E Subject: [secdir] SecDir Review of draft-ietf-lmap-use-cases-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 09:07:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xk9IDHHuSlbfrsExC6MUmQvpItfmOruhg Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document outlines two main use cases for measuring broadband performance on a large scale. The document is well-written and discusses security as well as privacy concerns. I have a few remarks regarding the text in the security consideration section. You introduce the terms "Measurement Agents", "Subscriber", and "Measurement Tasks" for the first time in the security consideration section. I wonder whether you could describe the problems without actually having to reference the framework document. A few remarks regarding the listed issues: 1. a malicious party that gains control of Measurement Agents to launch DoS attacks at a target, or to alter (perhaps subtly) Measurement Tasks in order to compromise the end user's privacy, the business confidentiality of the network, or the accuracy of the measurement system. How does the DoS attack against some other party compromise the end user's privacy? I guess you are referring to the threat described in Section 5.1.3 of http://tools.ietf.org/html/rfc6973 2. a malicious party that gains control of Measurement Agents to create a platform for pervasive monitoring [RFC7258], in order to attack the privacy of Internet users and organisations. You might want to explain that the developed protocol mechanism allows data about the user's communication to be collected. This collected data allows monitoring. (I haven't followed the LMAP work in detail but it might be useful to state what type of data the system is anticipated to collect. If everything can be collected then a reference to RFC 2804 might be appropriate.) 6. a measurement system that is vague about who is responsible for privacy (data protection); this role is often termed the "data controller". I would re-write this to: 6. a measurement system that does not indicate who is responsible for the collection/processing of personal data and who is responsible for fulfilling the rights of users. You could also say something about the need to * prevent unauthorized access to collected measurement data, * give users the ability to view collected data, * give users the ability to exert control over sharing, and * enforce retention periods. Ciao Hannes --xk9IDHHuSlbfrsExC6MUmQvpItfmOruhg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUbF3XAAoJEGhJURNOOiAtcpMH/0257I86QIQvpgKFyhSeI2Fz eZ3bZW1FHk4lq07FTNdNPaDDTQrQ1mz5Og6PliDOi5RAnfj3JNewWjw8aCtDTl2m VeAZZLtQlmNhh3FILZLcj93/69IXtBfw3jzdoYLF33D5cCr+BQ0z5n36rgf6ouC/ ShxsSzy2H8mhtLHJAVA+tcUYHRA2lKwzsfOo2BT3QXgZqxLQoDT8752uoJ7gqAGA XFMsHaa9G/x0tMJqr5sNifDb5zFU53/1adGhk1XgZHKBMKXH8WH8C6+VU10v96n4 oYyqI4jdtq8Pm/wffAtF2a33gIHwefeEvbw8gWGSk5XAjmKB4/rkpt349ChfM5o= =VzuM -----END PGP SIGNATURE----- --xk9IDHHuSlbfrsExC6MUmQvpItfmOruhg-- From nobody Wed Nov 19 05:09:48 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 E95D01A00E7; Wed, 19 Nov 2014 02:07:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1416391661; bh=VVc/7RyURf2uPU4o2lX2RFB2bBFxuJ/zTiHq53vT2AM=; 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=vPwVpQCGMnRrzNnhyJ6/sb0c3/u/EXMthquiGQP9W55NAk/NtbxPzHT/Chjham3u6 nBn+aOiAu4AS3k7SlgjXGRENlj2Svo58OynQEv1zStEXduPBxVZYWpFGJCCI7qHzj2 Wk8IcOiCD1SSGUcmpk9loTFxLXMLSbtM3d3et1+M= 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 7B7531A005C for ; Wed, 19 Nov 2014 02:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 T4c1YhWQJhsI for ; Wed, 19 Nov 2014 02:07:36 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD7D1A1A40 for ; Wed, 19 Nov 2014 02:07:35 -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 1Xr2Ag-0007CD-J2 for new-work@ietf.org; Wed, 19 Nov 2014 05:07:34 -0500 To: new-work@ietf.org Date: Wed, 19 Nov 2014 11:07:33 +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/IlhNBJVYdLGUf9gKRA5JwyRuYWY 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/PD43Z3UcVFGMrrRjNyUr4NmFTH0 X-Mailman-Approved-At: Wed, 19 Nov 2014 05:09:32 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Spatial Data on the Web Working Group (until 2014-12-19) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 10:07:41 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Spatial Data on the Web Working Group: http://www.w3.org/2014/spatial/charter As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2014-12-19 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 Phil Archer , Staff contact. Thank you, Coralie Mercier, W3C Communications [1] http://www.w3.org/2014/Process-20140801/#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 Wed Nov 19 09:48: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 369531AD3D7; Wed, 19 Nov 2014 09:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQbat0PbZA3X; Wed, 19 Nov 2014 09:48:29 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3201AD3E0; Wed, 19 Nov 2014 09:48:23 -0800 (PST) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 19 Nov 2014 17:48:29 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.213]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Wed, 19 Nov 2014 17:48:21 +0000 From: To: , , , Date: Wed, 19 Nov 2014 17:48:20 +0000 Thread-Topic: SecDir Review of draft-ietf-lmap-use-cases-05 Thread-Index: AdAD2FjBxlxG6NVMQQ+SRi3/3FK+1AAQYaZQ Message-ID: References: <546C5DD7.3060900@gmx.net> In-Reply-To: <546C5DD7.3060900@gmx.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/YWg2cNpqL5aYPCAbF7OLwqX0hmk Subject: Re: [secdir] SecDir Review of draft-ietf-lmap-use-cases-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 17:48:32 -0000 SGFubmVzLA0KDQpUaGFuay15b3UgZm9yIHlvdXIgcmV2aWV3LiBTb21lIGZvbGxvdy11cHMgaW4t bGluZQ0KDQpCZXN0IHdpc2hlcw0KcGhpbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IEhhbm5lcyBUc2Nob2ZlbmlnIFttYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214 Lm5ldF0NCj4gU2VudDogMTkgTm92ZW1iZXIgMjAxNCAwOTowOA0KPiBUbzogc2VjZGlyQGlldGYu b3JnOyBpZXNnQGlldGYub3JnOyBkcmFmdC1pZXRmLWxtYXAtdXNlLQ0KPiBjYXNlc0B0b29scy5p ZXRmLm9yZw0KPiBTdWJqZWN0OiBTZWNEaXIgUmV2aWV3IG9mIGRyYWZ0LWlldGYtbG1hcC11c2Ut Y2FzZXMtMDUNCj4gDQo+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2Yg dGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MNCj4gb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFs bCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlDQo+IElFU0cuDQo+IFRoZXNl IGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBz ZWN1cml0eQ0KPiBhcmVhIGRpcmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJz IHNob3VsZCB0cmVhdCB0aGVzZQ0KPiBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3Qg Y2FsbCBjb21tZW50cy4NCj4gDQo+IFRoaXMgZG9jdW1lbnQgb3V0bGluZXMgdHdvIG1haW4gdXNl IGNhc2VzIGZvciBtZWFzdXJpbmcgYnJvYWRiYW5kDQo+IHBlcmZvcm1hbmNlIG9uIGEgbGFyZ2Ug c2NhbGUuDQo+IA0KPiBUaGUgZG9jdW1lbnQgaXMgd2VsbC13cml0dGVuIGFuZCBkaXNjdXNzZXMg c2VjdXJpdHkgYXMgd2VsbCBhcyBwcml2YWN5DQo+IGNvbmNlcm5zLg0KPiANCj4gSSBoYXZlIGEg ZmV3IHJlbWFya3MgcmVnYXJkaW5nIHRoZSB0ZXh0IGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9uDQo+IHNlY3Rpb24uDQo+IA0KPiBZb3UgaW50cm9kdWNlIHRoZSB0ZXJtcyAiTWVhc3VyZW1l bnQgQWdlbnRzIiwgIlN1YnNjcmliZXIiLCBhbmQNCj4gIk1lYXN1cmVtZW50IFRhc2tzIiBmb3Ig dGhlIGZpcnN0IHRpbWUgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24NCj4gc2VjdGlvbi4N Cj4gDQo+IEkgd29uZGVyIHdoZXRoZXIgeW91IGNvdWxkIGRlc2NyaWJlIHRoZSBwcm9ibGVtcyB3 aXRob3V0IGFjdHVhbGx5DQo+IGhhdmluZyB0byByZWZlcmVuY2UgdGhlIGZyYW1ld29yayBkb2N1 bWVudC4NCg0KW3BoaWxdIHdpbGwgc3Vic3RpdHV0ZSB0aGUgdGVybXMgdXNlZCBlYXJsaWVyIGlu IHRoZSBkb2M6IHByb2JlLCBlbmQgdXNlciBhbmQgbWVhc3VyZW1lbnQgdGVzdHMuIA0KV291bGQg cHJlZmVyIHRvIGtlZXAgdGhlIHJlZmVyZW5jZSAtIGFzIGl0IGdpdmVzIGEgcG9pbnRlciwgZm9y IHBlb3BsZSB3aG8gd2FudCB0byByZWFkIGFib3V0IHNvbWUgcG90ZW50aWFsIG1pdGlnYXRpb25z IG9mIHRoZSBzZWN1cml0eSBpc3N1ZXMuDQogDQo+IA0KPiBBIGZldyByZW1hcmtzIHJlZ2FyZGlu ZyB0aGUgbGlzdGVkIGlzc3VlczoNCj4gDQo+ICAgICAgIDEuIGEgbWFsaWNpb3VzIHBhcnR5IHRo YXQgZ2FpbnMgY29udHJvbCBvZiBNZWFzdXJlbWVudCBBZ2VudHMgdG8NCj4gICAgICAgbGF1bmNo IERvUyBhdHRhY2tzIGF0IGEgdGFyZ2V0LCBvciB0byBhbHRlciAocGVyaGFwcyBzdWJ0bHkpDQo+ ICAgICAgIE1lYXN1cmVtZW50IFRhc2tzIGluIG9yZGVyIHRvIGNvbXByb21pc2UgdGhlIGVuZCB1 c2VyJ3MgcHJpdmFjeSwNCj4gICAgICAgdGhlIGJ1c2luZXNzIGNvbmZpZGVudGlhbGl0eSBvZiB0 aGUgbmV0d29yaywgb3IgdGhlIGFjY3VyYWN5IG9mDQo+ICAgICAgIHRoZSBtZWFzdXJlbWVudCBz eXN0ZW0uDQo+IA0KPiBIb3cgZG9lcyB0aGUgRG9TIGF0dGFjayBhZ2FpbnN0IHNvbWUgb3RoZXIg cGFydHkgY29tcHJvbWlzZSB0aGUgZW5kDQo+IHVzZXIncyBwcml2YWN5PyBJIGd1ZXNzIHlvdSBh cmUgcmVmZXJyaW5nIHRvIHRoZSB0aHJlYXQgZGVzY3JpYmVkIGluDQo+IFNlY3Rpb24gNS4xLjMg b2YgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjk3Mw0KDQpbcGhpbF0gSSB0aGluayB0 aGlzIGJ1bGxldCBzaG91bGQgYmUgc3BsaXQgaW4gdHdvLiBJIHRoaW5rIHdlIHdlcmUganVzdCBt YWtpbmcgdGhlIGdlbmVyYWwgcG9pbnQgdGhhdCBEb1MgYXR0YWNrcyBhcmUgYmFkIChpbiB3YXlz IHRvbyBudW1lcm91cyB0byBtZW50aW9uISkuDQoNCjEuIGEgbWFsaWNpb3VzIHBhcnR5IHRoYXQg Z2FpbnMgY29udHJvbCBvZiBNZWFzdXJlbWVudCBBZ2VudHMgdG8NCiAgICAgIGxhdW5jaCBEb1Mg YXR0YWNrcyBhdCBhIHRhcmdldC4NCg0KMi4gYSBtYWxpY2lvdXMgcGFydHkgdGhhdCBnYWlucyBj b250cm9sIG9mIE1lYXN1cmVtZW50IEFnZW50cyB0byBhbHRlciAocGVyaGFwcyBzdWJ0bHkpDQog ICAgICBNZWFzdXJlbWVudCBUYXNrcyBpbiBvcmRlciB0byBjb21wcm9taXNlIHRoZSBlbmQgdXNl cidzIHByaXZhY3ksDQogICAgICB0aGUgYnVzaW5lc3MgY29uZmlkZW50aWFsaXR5IG9mIHRoZSBu ZXR3b3JrLCBvciB0aGUgYWNjdXJhY3kgb2YNCiAgICAgIHRoZSBtZWFzdXJlbWVudCBzeXN0ZW0u DQoNCj4gDQo+ICAgICAgIDIuIGEgbWFsaWNpb3VzIHBhcnR5IHRoYXQgZ2FpbnMgY29udHJvbCBv ZiBNZWFzdXJlbWVudCBBZ2VudHMgdG8NCj4gICAgICAgY3JlYXRlIGEgcGxhdGZvcm0gZm9yIHBl cnZhc2l2ZSBtb25pdG9yaW5nIFtSRkM3MjU4XSwgaW4gb3JkZXIgdG8NCj4gICAgICAgYXR0YWNr IHRoZSBwcml2YWN5IG9mIEludGVybmV0IHVzZXJzIGFuZCBvcmdhbmlzYXRpb25zLg0KPiANCj4g WW91IG1pZ2h0IHdhbnQgdG8gZXhwbGFpbiB0aGF0IHRoZSBkZXZlbG9wZWQgcHJvdG9jb2wgbWVj aGFuaXNtIGFsbG93cw0KPiBkYXRhIGFib3V0IHRoZSB1c2VyJ3MgY29tbXVuaWNhdGlvbiB0byBi ZSBjb2xsZWN0ZWQuIFRoaXMgY29sbGVjdGVkDQo+IGRhdGEgYWxsb3dzIG1vbml0b3JpbmcuDQo+ IA0KPiAoSSBoYXZlbid0IGZvbGxvd2VkIHRoZSBMTUFQIHdvcmsgaW4gZGV0YWlsIGJ1dCBpdCBt aWdodCBiZSB1c2VmdWwgdG8NCj4gc3RhdGUgd2hhdCB0eXBlIG9mIGRhdGEgdGhlIHN5c3RlbSBp cyBhbnRpY2lwYXRlZCB0byBjb2xsZWN0LiBJZg0KPiBldmVyeXRoaW5nIGNhbiBiZSBjb2xsZWN0 ZWQgdGhlbiBhIHJlZmVyZW5jZSB0byBSRkMgMjgwNCBtaWdodCBiZQ0KPiBhcHByb3ByaWF0ZS4p DQoNCltwaGlsXSBIb3cgYWJvdXQgYWRkaW5nIHRoaXM6DQpGb3IgZXhhbXBsZSwgaW1hZ2luZSBh IG1hbGljaW91cyBwYXJ0eSB0aGF0IGNvdWxkIGRpc3RyaWJ1dGUgdG8gdGhlIHByb2JlcyBhIG1l YXN1cmVtZW50IHRlc3QgdGhhdCByZWNvcmRlZCAoYW5kIGxhdGVyIHJlcG9ydGVkKSBhbGwgdGhl IElQIGFkZHJlc3NlcyB0aGUgZW5kIGhvc3QgY29tbXVuaWNhdGVkIHdpdGguIA0KDQo+IA0KPiAg ICAgICA2LiBhIG1lYXN1cmVtZW50IHN5c3RlbSB0aGF0IGlzIHZhZ3VlIGFib3V0IHdobyBpcyBy ZXNwb25zaWJsZQ0KPiBmb3INCj4gICAgICAgcHJpdmFjeSAoZGF0YSBwcm90ZWN0aW9uKTsgdGhp cyByb2xlIGlzIG9mdGVuIHRlcm1lZCB0aGUgImRhdGENCj4gICAgICAgY29udHJvbGxlciIuDQo+ IA0KPiBJIHdvdWxkIHJlLXdyaXRlIHRoaXMgdG86DQo+IA0KPiAgICAgICA2LiBhIG1lYXN1cmVt ZW50IHN5c3RlbSB0aGF0IGRvZXMgbm90IGluZGljYXRlIHdobyBpcyByZXNwb25zaWJsZQ0KPiBm b3IgdGhlIGNvbGxlY3Rpb24vcHJvY2Vzc2luZyBvZiBwZXJzb25hbCBkYXRhIGFuZCB3aG8gaXMg cmVzcG9uc2libGUNCj4gZm9yIGZ1bGZpbGxpbmcgdGhlIHJpZ2h0cyBvZiB1c2Vycy4NCj4gDQo+ IFlvdSBjb3VsZCBhbHNvIHNheSBzb21ldGhpbmcgYWJvdXQgdGhlIG5lZWQgdG8NCj4gDQo+ICAq IHByZXZlbnQgdW5hdXRob3JpemVkIGFjY2VzcyB0byBjb2xsZWN0ZWQgbWVhc3VyZW1lbnQgZGF0 YSwNCj4gICogZ2l2ZSB1c2VycyB0aGUgYWJpbGl0eSB0byB2aWV3IGNvbGxlY3RlZCBkYXRhLA0K PiAgKiBnaXZlIHVzZXJzIHRoZSBhYmlsaXR5IHRvIGV4ZXJ0IGNvbnRyb2wgb3ZlciBzaGFyaW5n LCBhbmQNCj4gICogZW5mb3JjZSByZXRlbnRpb24gcGVyaW9kcy4NCg0KW3BoaWxdIGhvdyBhYm91 dCB0aGlzPw0KDQo2LiBhIG1lYXN1cmVtZW50IHN5c3RlbSB0aGF0IGRvZXMgbm90IGluZGljYXRl IHdobyBpcyByZXNwb25zaWJsZSBmb3IgdGhlIGNvbGxlY3Rpb24gYW5kIHByb2Nlc3Npbmcgb2Yg cGVyc29uYWwgZGF0YSBhbmQgd2hvIGlzIHJlc3BvbnNpYmxlIGZvciBmdWxmaWxsaW5nIHRoZSBy aWdodHMgb2YgdXNlcnMuIFRoZSByZXNwb25zaWJsZSBwYXJ0eSAob2Z0ZW4gdGVybWVkIHRoZSAi ZGF0YSBjb250cm9sbGVyIikgc2hvdWxkLCBhcyBnb29kIHByYWN0aWNlLCBjb25zaWRlciBpc3N1 ZXMgc3VjaCBhcyBkZWZpbmluZzotIHRoZSBwdXJwb3NlIGZvciB3aGljaCB0aGUgZGF0YSBpcyBj b2xsZWN0ZWQgYW5kIHVzZWQ7IGhvdyB0aGUgZGF0YSBpcyBzdG9yZWQsIGFjY2Vzc2VkLCBhbmQg cHJvY2Vzc2VkOyBob3cgbG9uZyBpdCBpcyByZXRhaW5lZCBmb3I7IGFuZCBob3cgdGhlIGVuZCB1 c2VyIGNhbiB2aWV3LCB1cGRhdGUsIGFuZCBldmVuIGRlbGV0ZSB0aGVpciBwZXJzb25hbCBkYXRh LiBJZiBhbm9ueW1pc2VkIHBlcnNvbmFsIGRhdGEgaXMgc2hhcmVkIHdpdGggYSB0aGlyZCBwYXJ0 eSwgdGhlIGRhdGEgY29udHJvbGxlciBzaG91bGQgY29uc2lkZXIgdGhlIHBvc3NpYmlsaXR5IHRo YXQgdGhlIHRoaXJkIHBhcnR5IGNhbiBkZS1hbm9ueW1pc2UgaXQgYnkgY29tYmluaW5nIGl0IHdp dGggb3RoZXIgaW5mb3JtYXRpb24uICANCg0KPiANCj4gQ2lhbw0KPiBIYW5uZXMNCg0K From nobody Thu Nov 20 02:54: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 717D41A0197 for ; Thu, 20 Nov 2014 02:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.715 X-Spam-Level: X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_NEUTRAL=0.779] 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 eeHs4S-kvi7Z for ; Thu, 20 Nov 2014 02:53:56 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBAB1A01AA for ; Thu, 20 Nov 2014 02:53:55 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sAKArnHA013561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 20 Nov 2014 12:53:49 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sAKArm6J011904; Thu, 20 Nov 2014 12:53:48 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21613.51260.921484.872483@fireball.kivinen.iki.fi> Date: Thu, 20 Nov 2014 12:53:48 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ERWaeapdmO0WvI2K-A_tZWKkyYQ 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 Nov 2014 10:54:00 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Tina TSOU is next in the rotation. For telechat 2014-11-25 Reviewer LC end Draft Alan DeKok T 2014-10-21 draft-ietf-tram-alpn-07 Donald Eastlake TR2014-10-30 draft-leiba-cotton-iana-5226bis-11 Dorothy Gellert T 2014-10-27 draft-ietf-manet-ibs-03 Alexey Melnikov T 2014-11-06 draft-ietf-opsawg-mibs-to-ieee80231-01 For telechat 2014-12-04 Sandy Murphy T 2014-11-25 draft-mcdonald-ipps-uri-scheme-16 Last calls and special requests: Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-07 Tero Kivinen E None draft-richardson-6tisch--security-6top-04 Matt Lepinski 2014-11-18 draft-nottingham-safe-hint-05 Catherine Meadows 2014-11-10 draft-ietf-opsawg-capwap-hybridmac-06 Magnus Nystrom 2014-12-01 draft-josefsson-pkix-textual-08 Hilarie Orman E None draft-richardson-6tisch--security-6top-04 Vincent Roca 2014-11-27 draft-ietf-ccamp-rwa-info-22 Joe Salowey 2014-12-01 draft-ietf-tsvwg-sctp-prpolicies-05 Yaron Sheffer 2014-11-28 draft-ietf-jose-cookbook-06 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Melinda Shore 2014-12-01 draft-ietf-eman-applicability-statement-08 Takeshi Takahashi 2014-12-01 draft-ietf-grow-irr-routing-policy-considerations-05 Hannes Tschofenig 2014-12-01 draft-ietf-opsec-dhcpv6-shield-04 Sean Turner 2014-10-13 draft-ietf-mpls-lsp-ping-relay-reply-05 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-12 -- kivinen@iki.fi From nobody Thu Nov 20 07:57:04 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 B0BDC1A1A65; Thu, 20 Nov 2014 07:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.493 X-Spam-Level: X-Spam-Status: No, score=-7.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] 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 97-ETYYHV5w4; Thu, 20 Nov 2014 07:56:51 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDAF01A0A6A; Thu, 20 Nov 2014 07:56:50 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgQAKEOblSHCzIm/2dsb2JhbABagkgjI1VZBIMCtDEBAQEBAgabXgIcahYBAQEBAQF8hAIBAQEBAxIRCjgPFQIBCA0EBAEBCwMTBwMCAgIfERQJCAIEARIIDA6ICgMSAbNIilaQEA2GTwEBAQEBAQQBAQEBAQEBAQEBAReGOYgUggo3AYJ3NoEeBZJXiXUBg0eGd4cTSIJthAmDe20BgUeBAwEBAQ X-IronPort-AV: E=Sophos; i="5.07,424,1413259200"; d="scan'208,217"; a="81432035" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Nov 2014 10:56:47 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 20 Nov 2014 10:56:46 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Thu, 20 Nov 2014 10:56:44 -0500 From: "Romascanu, Dan (Dan)" To: "philip.eardley@bt.com" , "radiaperlman@gmail.com" , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-lmap-framework.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-lmap-framework-08 Thread-Index: AQHQAvIx8O0/SNtxIEiOh1J4I8qnj5xmpMqAgAMJ+yA= Date: Thu, 20 Nov 2014 15:56:44 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C90BD8B@AZ-FFEXMB04.global.avaya.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C90BD8BAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/UQo0UqWkpnaJzsJCET02P-juvYQ Subject: Re: [secdir] Secdir review of draft-ietf-lmap-framework-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, 20 Nov 2014 15:56:55 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C90BD8BAZFFEXMB04globa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIHRvIFJhZGlhIGZvciB0aGUgdmFsdWFibGUgcmV2aWV3LiBUaGV5IGRlc2VydmUgZGlz Y3Vzc2lvbiBhbmQgZWRpdHMuDQoNClBoaWwsIHNvbWUgb2YgeW91ciBxdWVzdGlvbnMgc2VlbSB0 byBiZSBhZGRyZXNzZWQgdG8gdGhlIExNQVAgY29tbXVuaXR5LiBBbSBJIHdyb25nPyBUaGUgTE1B UCBXRyBsaXN0IGlzIG5vdCBjb3BpZWQgb24gdGhlIHJlc3BvbnNlLg0KDQpSZWdhcmRzLA0KDQpE YW4NCg0KDQpGcm9tOiBwaGlsaXAuZWFyZGxleUBidC5jb20gW21haWx0bzpwaGlsaXAuZWFyZGxl eUBidC5jb21dDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxOCwgMjAxNCAyOjMwIFBNDQpUbzog cmFkaWFwZXJsbWFuQGdtYWlsLmNvbTsgc2VjZGlyQGlldGYub3JnOyBpZXNnQGlldGYub3JnOyBk cmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLmFsbEB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUkU6 IFNlY2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay0wOA0KDQpSYWRpYSwN ClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgcmV2aWV3Lg0KU29tZSBjb21tZW50cyBpbi1s aW5lDQoNCkJlc3Qgd2lzaGVzLA0KUGhpbA0KDQotLS0tLS0NCkZyb206IFJhZGlhIFBlcmxtYW4g W21haWx0bzpyYWRpYXBlcmxtYW5AZ21haWwuY29tXQ0KU2VudDogMTggTm92ZW1iZXIgMjAxNCAw NTozOQ0KVG86IHNlY2RpckBpZXRmLm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPjsgVGhlIElF U0c7IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmsuYWxsQHRvb2xzLmlldGYub3JnPG1haWx0bzpk cmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLmFsbEB0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFNl Y2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay0wOA0KDQpJIGhhdmUgcmV2 aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdz IG9uZ29pbmcNCmVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nl c3NlZCBieSB0aGUgSUVTRy4gIERvY3VtZW50DQplZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxk IHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdA0KY2FsbCBjb21t ZW50cy4NCg0KU3VtbWFyeTogSXQncyBmaW5lLCB0aG91Z2ggSSBjb3VsZG4ndCByZXNpc3QgbWFr aW5nIGEgZmV3IHN1Z2dlc3Rpb25zLg0KDQpMTUFQIGlzIGFwcGFyZW50bHkgYSBzdHJhaW5lZCBh Y3JvbnltIGZvciAiTGFyZ2Utc2NhbGUgTWVhc3VyZW1lbnQgb2YgQWNjZXNzDQpuZXR3b3JrIFBl cmZvcm1hbmNlIiwNCltwaGlsXSBzdHJhaW5lZCBpbmRlZWQuIEJ1dCB0b28gbGF0ZSB0byBjaGFu Z2UgdGhlIGFjcm9ueW0hDQoNCmEgY29sbGVjdGlvbiBvZiBwcm90b2NvbHMgZGVzaWduZWQgZm9y IG1lYXN1cmluZyB0aGUNCmNhcGFjaXR5IGFuZCByZXNwb25zaXZlbmVzcyBvZiBjb25uZWN0aXZp dHkgcHJvdmlkZWQgYnkgYnJvYWRiYW5kIElTUHMsDQp0aG91Z2ggdGhlcmUgbWF5IGhhdmUgYmVl biBzb21lIGZlYXR1cmUgY3JlZXAgYXMgdGhlIHByb3RvY29scyBhcmUNCnN1ZmZpY2llbnRseSBn ZW5lcmFsIHRvIGJlIHVzZWQgZm9yIG90aGVyIHRoaW5ncy4gVGhpcyBkb2N1bWVudCBpcyBhDQpm cmFtZXdvcmsgZG9jdW1lbnQgZGVmaW5pbmcgdGVybXMgYW5kIHByb3ZpZGluZyBhbiBvdmVydmll dyBvZiB0aGUgaW50ZW5kZWQNCmRlcGxveW1lbnQgbW9kZWwgKGFuZCBpbnRlbmRlZCB0byBiZSBJ TkZPUk1BVElPTkFMKS4gVGhlcmUgYXJlIGNvbXBhbmlvbg0KSS1EcyBzcGVjaWZ5aW5nIGluZGl2 aWR1YWwgcHJvdG9jb2xzIGluIG1vcmUgZGV0YWlsLiBBcyBzdWNoLCBtb3N0IG9mIHRoZQ0Kc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgd291bGQgYmUgZGlzY3Vzc2VkIGluIHRob3NlIGRvY3VtZW50 cywgdGhvdWdoIHRoaXMNCm92ZXJ2aWV3IGRvY3VtZW50IHByb3ZpZGVzIGFuIG92ZXJ2aWV3IG9m IHRoZSB0eXBlcyBvZiBzZWN1cml0eQ0KY29uc2lkZXJhdGlvbnMgdG8gYmUgZGlzY3Vzc2VkIGlu IHRob3NlIGRvY3VtZW50cy4NCg0KVGhlIG1ham9yIGNvbXBvbmVudHMgb2YgTE1BUCBhcmUgYSBN ZWFzdXJlbWVudCBBZ2VudCAoTUEpIHVzdWFsbHkgcmVzaWRpbmcNCm9uIGN1c3RvbWVyIHByZW1p c2VzIHRoYXQgcnVucyBwZXJpb2RpYyBwZXJmb3JtYW5jZSB0ZXN0cyBhbmQgcmVwb3J0cw0KcmVz dWx0cywgYSBDb250cm9sbGVyIHVzdWFsbHkgcmVzaWRpbmcgb2ZmLWN1c3RvbWVyLXByZW1pc2Vz IHRoYXQgY29uZmlndXJlcw0Kc29tZSBsYXJnZSBjb2xsZWN0aW9uIG9mIE1lYXN1cmVtZW50IEFn ZW50cywgYW5kIGEgQ29sbGVjdG9yIHVzdWFsbHkNCnJlc2lkaW5nIG9mZi1jdXN0b21lci1wcmVt aXNlcyB0aGF0IHJlY2VpdmVzIGFuZCByZWNvcmRzIHJlcG9ydHMgZnJvbSB0aGUNCk1lYXN1cmVt ZW50IEFnZW50cy4gVGhvc2UgcmVwb3J0cyBtYXkgY29udGFpbiBzdGF0aXN0aWNhbCBkYXRhIGNv bmNlcm5pbmcNCm5vcm1hbCBvcGVyYXRpb24gb2YgdGhlIE1BJ3MgcGxhdGZvcm0gYXMgd2VsbCBh cyB0aGUgcmVzdWx0cyBvZiBzcGVjaWZpYw0KdGVzdHMuIEl0IGlzIHRoZSBDb250cm9sbGVyIHRv IE1BIGFuZCBNQSB0byBDb2xsZWN0b3IgcHJvdG9jb2xzIHRoYXQgd2lsbA0KcmVxdWlyZSByaWdv cm91cyBzZWN1cml0eSBhbmFseXNpcyBhbmQgd2hpY2ggYXJlIHNwZWNpZmllZCBpbiBkaWZmZXJl bnQNCmRvY3VtZW50cyB3aXRoaW4gTE1BUC4NCltwaGlsXSB0byBub3RlIGluIHBhc3NpbmcsIHRo ZXkgbWF5IGJlIHRoZSBzYW1lIG9yIGRpZmZlcmVudCBwcm90b2NvbCAodGhpcyBpcyB0byBiZSBk ZWNpZGVkKQ0KDQpUaGUgcHJvdG9jb2xzIHdob3NlIHBlcmZvcm1hbmNlIGlzIG1lYXN1cmVkIG1h eSBhbHNvDQpyZXF1aXJlIGEgcmlnb3JvdXMgc2VjdXJpdHkgYW5hbHlzaXMsIGJ1dCB0aGV5IGFy ZSBkZWZpbmVkIG91dHNpZGUgb2YgTE1BUC4NCg0KVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IHNlY3Rpb24gbGlzdHMgdGhlIHNvcnRzIG9mIGlzc3VlcyB0aGF0IHdpbGwgbmVlZA0KdG8gYmUg ZGVhbHQgd2l0aCBpbiB0aGUgb3RoZXIgZG9jdW1lbnRzLiBJdCBkb2VzIG5vdCBnbyBpbnRvIGhv dyB0aG9zZQ0KaXNzdWVzIGFyZSBhZGRyZXNzZWQ7IHByZXN1bWFibHkgdGhlIGNvbXBhbmlvbiBk b2N1bWVudHMgZG8uDQpbcGhpbF0gY29ycmVjdCwgdGhlIHByb3RvY29sIGRvYyhzKSB3aWxsIGhh dmUgdG8gY292ZXIgdGhpcw0KDQpUaGVyZSBpcyBhIG11Y2gNCmxvbmdlciBwcml2YWN5IGNvbnNp ZGVyYXRpb25zIHNlY3Rpb24gdGhhdCBlbnVtZXJhdGVzIGFuIGludGltaWRhdGluZyBzZXQgb2YN CnBvdGVudGlhbCBwcml2YWN5IGFidXNlcyB0aGF0IG5lZWQgdG8gYmUgbWl0aWdhdGVkLg0KDQpB biBpbXBvcnRhbnQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiB0aGF0IEkgZGlkbid0IHNlZSB3YXMg ZGVhbGluZyB3aXRoIHRoZQ0KY2FzZSBvZiBhIGNvcnJ1cHRlZCBNQSB0aGF0IHJlcG9ydHMgZmFs c2lmaWVkIGluZm9ybWF0aW9uIHRvIHRoZSBjb2xsZWN0b3IuDQpUaGlzIG1pZ2h0IG9jY3VyIGlu IHRoZSBjYXNlIHdoZXJlIGEgY3VzdG9tZXIgd2FudHMgaXQgdG8gYXBwZWFyIHRoYXQgdGhlDQpJ U1AgaXMgbm90IG1lZXRpbmcgaXRzIGNvbW1pdG1lbnRzIHdoZW4gaW4gZmFjdCB0aGUgSVNQIGlz LiBXaGV0aGVyIHRoaXMgY2FuDQpiZSBlZmZlY3RpdmVseSBtaXRpZ2F0ZWQgZGVwZW5kcyBvbiB0 aGUgcGxhdGZvcm0gb24gd2hpY2ggdGhlIE1BIGlzDQpkZXBsb3llZCwgYnV0IHdoZXJlIHRoZSBN QSBpcyBkZXBsb3llZCBvbiBhIGN1c3RvbWVyLWNvbnRyb2xsZWQgcGxhdGZvcm0gaXQNCm11c3Qg YmUgcmVjb2duaXplZCB0aGF0IHRoZSBkYXRhIGNvbGxlY3RlZCBpcyB0byBzb21lIGRlZ3JlZSBp bmhlcmVudGx5DQp1bnRydXN0d29ydGh5LiBUaGlzIG1lYW5zLCBmb3IgZXhhbXBsZSwgdGhhdCBp biBzdWNoIGNvbmZpZ3VyYXRpb25zIHRoZSBkYXRhDQpzaG91bGQgbm90IGJlIHVzZWQgYXMgdGhl IGJhc2lzIGZvciBhIGN1c3RvbWVyIHRvIGdldCByZWZ1bmRzIG9mDQpzdWJzY3JpcHRpb24gZmVl cy4NCg0KW3BoaWxdIEdvb2QgcG9pbnQuIEV2ZW4gaWYgc29tZWhvdyB0aGUgTUEgaXMgcHJldmVu dGVkIGZyb20gaW5qZWN0aW5nIGZhbHNpZmllZCByZXBvcnRzLCBhIHNvcGhpc3RpY2F0ZWQgY3Vz dG9tZXIgY291bGQgZGlzdG9ydCB0aGUgbWVhc3VyZW1lbnRzIChlZyBhZGQgYm94IHRoYXQgZHJv cHMgcGFja2V0cykNCkkgd2lsbCBhZGQgc29tZXRoaW5nIGFib3V0IHRoaXMuIHRoYW5rcy4NCg0K DQpJIHNhdyB0d28gcXVlc3Rpb25hYmxlIGFzcGVjdHMgb2YgdGhlIGRlc2lnbiAoYXQgdGhpcyBs ZXZlbCBvZiBhYnN0cmFjdGlvbikuDQoNClRoZSBmaXJzdCBoYXMgdG8gZG8gd2l0aCB3aG8gaW5p dGlhdGVzIHRoZSBDb250cm9sbGVyIHRvIE1BIGNvbm5lY3Rpb24uIFRoaXMNCnNwZWMgc2VlbXMg dG8gaW1wbHkgdGhhdCB0aGUgY29ubmVjdGlvbiBjYW4gYmUgaW5pdGlhdGVkIGZyb20gZWl0aGVy IGVuZC4uLg0KdGhlIENvbnRyb2xsZXIgY2FuIGluaXRpYXRlIGEgY29ubmVjdGlvbiB0byB0aGUg TUEgd2hlbiBpdCB3YW50cyB0byB1cGRhdGUNCnRoZSBNQSdzIGNvbmZpZ3VyYXRpb24gYW5kIHRo ZSBNQSBhbmQgaW5pdGlhdGUgYSBjb25uZWN0aW9uIHRvIHRoZQ0KY29udHJvbGxlciB0byByZXBv cnQgZXJyb3JzIGFuZCBsb2cgZGVidWdnaW5nIGluZm9ybWF0aW9uLiBUaGlzIGlzDQpwcm9ibGVt YXRpYyBmb3Igc2V2ZXJhbCByZWFzb25zLiBNb3N0IGltcG9ydGFudGx5LCBpbiBtYW55IHNjZW5h cmlvcyB0aGUgTUENCm1pZ2h0IG1vdmUgYXJvdW5kIGFuZCB0aGVyZWZvcmUgYmUgZGlmZmljdWx0 IGZvciB0aGUgQ29udHJvbGxlciB0byBmaW5kOyBvcg0KaXQgbWlnaHQgYmUgYmVoaW5kIGEgTkFU IG9yIG90aGVyIGZpcmV3YWxsIGFuZCBtaWdodCBub3QgYmUgY2FwYWJsZSBvZg0KYWNjZXB0aW5n IGluY29taW5nIGNvbm5lY3Rpb25zIChhdCBsZWFzdCBub3Qgd2l0aG91dCBhIGxvdCBvZiBhZGRp dGlvbmFsDQplZmZvcnQpLiBJZiBhbGwgc3VjaCBjb25uZWN0aW9ucyB3ZXJlIGluaXRpYXRlZCBi eSB0aGUgTUEsIGluY2x1ZGluZyBhDQpwb2xsaW5nIGludGVydmFsIGNvbmZpZ3VyZWQgYnkgdGhl IGNvbnRyb2xsZXIsIHN1Y2ggY29uZmlndXJhdGlvbiBpc3N1ZXMgZ28NCmF3YXkuDQoNCkFsdGVy bmF0ZWx5LCBpZiB0aGUgQ29udHJvbGxlciBpbml0aWF0ZWQgYWxsIGNvbm5lY3Rpb25zLCBpdCBi ZWNvbWVzIG11Y2gNCmVhc2llciB0byBwcm90ZWN0IHRoZSBDb250cm9sbGVyIGZyb20gRG9TIGF0 dGFja3MsIHNpbmNlIGl0IGlzIGdlbmVyYWxseQ0KbXVjaCBlYXNpZXIgdG8gYXR0YWNrIGEgc2Vy dmVyIHRoYW4gYSBjbGllbnQuIEJ1dCBoYXZpbmcgY29ubmVjdGlvbnMgYmVpbmcNCmluaXRpYXRl ZCBmcm9tIGJvdGggZGlyZWN0aW9ucyBnaXZlcyB0aGUgd29yc3Qgb2YgYm90aCB3b3JsZHMuDQoN CltwaGlsXSAgV2XigJl2ZSBkaXNjdXNzZWQgdGhpcyBhIGJpdCAoZm9yIGV4YW1wbGUsIG5lYXIg dGhlIGVuZCBvZiB0aGUgRHVibGluIGludGVyaW0pLiBJIHRoaW5rIHBlb3BsZSBmYXZvdXIgdGhl IGZvcm1lciBhcHByb2FjaCDigJMgdGhlIE1BIHJlZ3VsYXJseSBjYWxscyBpbiB0byBjaGVjayBp ZiB0aGUgY29uZmlnIC9pbnN0cnVjdGlvbiBoYXMgY2hhbmdlZC4NCg0KSeKAmW0gbm90IHN1cmUg d2hldGhlciB0aGlzIGRvYyBzaG91bGQgc3RhdGUgdGhhdCwgb3IgZ2l2ZSB0aGUgcHJvcyBhbmQg Y29ucyAoeW91ciB0ZXh0IGFib3ZlKSDigJMgdGhlIGxhdHRlciB3b3VsZCBiZSB0aGUgZGVmYXVs dCwgdGhvdWdoIHBlcnNvbmFsbHkgSSB3b3VsZG7igJl0IG1pbmQgaWYgd2Ugc2FpZCB0aGUgZm9y bWVyLiBXaGF0IGFwcHJvYWNoIGRvIHBlb3BsZSBwcmVmZXI/DQoNCg0KVGhlIHNlY29uZCBoYXMg dG8gZG8gd2l0aCB0aGUgTUEgc2VuZGluZyBlcnJvciBhbmQgbG9nIHJlcG9ydHMgdG8gdGhlDQpD b250cm9sbGVyLiBXaGlsZSBpdCBtYWtlcyBzZW5zZSBmb3IgdGhlIE1BIHRvIHJlcG9ydCBlcnJv cnMgdGhhdCBvY2N1ciBpbg0KcHJvY2Vzc2luZyBDb250cm9sbGVyIEluc3RydWN0aW9ucyBpbiB0 aGUgcmVzcG9uc2VzIHRvIHRob3NlIGNvbW1hbmRzLA0KZXJyb3JzIGFuZCBsb2dnZWQgZXZlbnRz IHRoYXQgb2NjdXIgYXN5bmNocm9ub3VzbHkgd291bGQgc2VlbSAodG8gbWUgYW55d2F5KQ0KYXMg bW9yZSBuYXR1cmFsbHkgYmVpbmcgc2VudCB0byB0aGUgQ29sbGVjdG9yLCBzaW5jZSBpdHMgam9i IGlzIHRvIGhhcnZlc3QNCm1hc3NpdmUgYW1vdW50cyBvZiBpbmZvcm1hdGlvbiBmcm9tIGxvdHMg b2YgTUFzLiBJdCBpcyBsaWtlbHkgdG8gYmUgbW9yZQ0KaGlnaGx5IHJlcGxpY2F0ZWQgYW5kIGxv YWQgYmFsYW5jZWQgdGhhbiB0aGUgQ29udHJvbGxlciwgYW5kIHRodXMgbW9yZQ0KY2FwYWJsZSBv ZiBoYW5kbGluZyBidXJzdHkgbG9hZHMuIEJ1dCB0aGlzIGhhcyBsaXR0bGUgdG8gZG8gd2l0aCBz ZWN1cml0eSwNCmFuZCBJIHRocm93IGl0IG91dCBvbmx5IGZvciB5b3VyIGNvbnNpZGVyYXRpb24u DQoNCltwaGlsXSBJIGd1ZXNzIGl0IGRlcGVuZHMgaG93IG11Y2ggdHJhZmZpYyBpcyBnZW5lcmF0 ZWQg4oCTIGluIGdlbmVyYWwgSSBkb27igJl0IHRoaW5rIHRoZXJl4oCZbGwgYmUgbXVjaCwgc28g SeKAmW0gaW5jbGluZWQgdG8gZGlzYWdyZWUuDQpOb3RlIGlmIHRoZSBDb2xsZWN0b3IgZGlkIGdl dCB0aGlzIGluZm9ybWF0aW9uLCB0aGUgQ29udHJvbGxlciB3b3VsZCBoYXZlIHRvIGJlIHRvbGQg YXQgbGVhc3QgYSBzdW1tYXJ5LCBzbyBpdCBjb3VsZCBtb2RpZnkgdGhlIGluc3RydWN0aW9ucyBh cyBhcHByb3ByaWF0ZS4gKEEgY29udHJvbGxlci1jb2xsZWN0b3IgaW50ZXJmYWNlIGlzIG91dCBv ZiBzY29wZSwgYXQgdGhpcyBzdGFnZS4pDQpBbnkgdGhvdWdodHM/DQoNClJhZGlhDQoNCg== --_000_9904FB1B0159DA42B0B887B7FA8119CA5C90BD8BAZFFEXMB04globa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsdWU7DQoJZm9udC13 ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25l IG5vbmU7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24g VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJh bGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4u RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3Mg dG8gUmFkaWEgZm9yIHRoZSB2YWx1YWJsZSByZXZpZXcuIFRoZXkgZGVzZXJ2ZSBkaXNjdXNzaW9u IGFuZCBlZGl0cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGhpbCwgc29tZSBvZiB5b3VyIHF1ZXN0aW9ucyBzZWVt IHRvIGJlIGFkZHJlc3NlZCB0byB0aGUgTE1BUCBjb21tdW5pdHkuIEFtIEkgd3Jvbmc/IFRoZSBM TUFQIFdHIGxpc3QgaXMgbm90IGNvcGllZCBvbiB0aGUgcmVzcG9uc2UuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5EYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHBoaWxpcC5lYXJk bGV5QGJ0LmNvbSBbbWFpbHRvOnBoaWxpcC5lYXJkbGV5QGJ0LmNvbV0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBOb3ZlbWJlciAxOCwgMjAxNCAyOjMwIFBNPGJyPg0KPGI+VG86PC9iPiBy YWRpYXBlcmxtYW5AZ21haWwuY29tOyBzZWNkaXJAaWV0Zi5vcmc7IGllc2dAaWV0Zi5vcmc7IGRy YWZ0LWlldGYtbG1hcC1mcmFtZXdvcmsuYWxsQHRvb2xzLmlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJFOiBTZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDg8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxkaXYgaWQ9IjozeGUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibHVlIj5SYWRpYSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+VGhhbmsg eW91IHZlcnkgbXVjaCBmb3IgeW91ciByZXZpZXcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlNvbWUg Y29tbWVudHMgaW4tbGluZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibHVlIj5CZXN0IHdpc2hlcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+UGhpbDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+LS0tLS0tPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJh ZGlhIFBlcmxtYW4gWzxhIGhyZWY9Im1haWx0bzpyYWRpYXBlcmxtYW5AZ21haWwuY29tIj5tYWls dG86cmFkaWFwZXJsbWFuQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTggTm92 ZW1iZXIgMjAxNCAwNTozOTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNlY2RpckBp ZXRmLm9yZyI+c2VjZGlyQGlldGYub3JnPC9hPjsgVGhlIElFU0c7IDxhIGhyZWY9Im1haWx0bzpk cmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLmFsbEB0b29scy5pZXRmLm9yZyI+DQpkcmFmdC1pZXRm LWxtYXAtZnJhbWV3b3JrLmFsbEB0b29scy5pZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gU2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTA4PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3Vt ZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZzxicj4NCmVm Zm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUg SUVTRy4mbmJzcDsgRG9jdW1lbnQ8YnI+DQplZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRy ZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdDxicj4NCmNhbGwgY29t bWVudHMuPGJyPg0KPGJyPg0KU3VtbWFyeTogSXQncyBmaW5lLCB0aG91Z2ggSSBjb3VsZG4ndCBy ZXNpc3QgbWFraW5nIGEgZmV3IHN1Z2dlc3Rpb25zLjxicj4NCjxicj4NCkxNQVAgaXMgYXBwYXJl bnRseSBhIHN0cmFpbmVkIGFjcm9ueW0gZm9yICZxdW90O0xhcmdlLXNjYWxlIE1lYXN1cmVtZW50 IG9mIEFjY2Vzczxicj4NCm5ldHdvcmsgUGVyZm9ybWFuY2UmcXVvdDssIDxzcGFuIHN0eWxlPSJj b2xvcjpibHVlIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPltwaGlsXSBzdHJhaW5lZCBp bmRlZWQuIEJ1dCB0b28gbGF0ZSB0byBjaGFuZ2UgdGhlIGFjcm9ueW0hPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmEgY29sbGVjdGlvbiBvZiBw cm90b2NvbHMgZGVzaWduZWQgZm9yIG1lYXN1cmluZyB0aGU8YnI+DQpjYXBhY2l0eSBhbmQgcmVz cG9uc2l2ZW5lc3Mgb2YgY29ubmVjdGl2aXR5IHByb3ZpZGVkIGJ5IGJyb2FkYmFuZCBJU1BzLDxi cj4NCnRob3VnaCB0aGVyZSBtYXkgaGF2ZSBiZWVuIHNvbWUgZmVhdHVyZSBjcmVlcCBhcyB0aGUg cHJvdG9jb2xzIGFyZTxicj4NCnN1ZmZpY2llbnRseSBnZW5lcmFsIHRvIGJlIHVzZWQgZm9yIG90 aGVyIHRoaW5ncy4gVGhpcyBkb2N1bWVudCBpcyBhPGJyPg0KZnJhbWV3b3JrIGRvY3VtZW50IGRl ZmluaW5nIHRlcm1zIGFuZCBwcm92aWRpbmcgYW4gb3ZlcnZpZXcgb2YgdGhlIGludGVuZGVkPGJy Pg0KZGVwbG95bWVudCBtb2RlbCAoYW5kIGludGVuZGVkIHRvIGJlIElORk9STUFUSU9OQUwpLiBU aGVyZSBhcmUgY29tcGFuaW9uPGJyPg0KSS1EcyBzcGVjaWZ5aW5nIGluZGl2aWR1YWwgcHJvdG9j b2xzIGluIG1vcmUgZGV0YWlsLiBBcyBzdWNoLCBtb3N0IG9mIHRoZTxicj4NCnNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIHdvdWxkIGJlIGRpc2N1c3NlZCBpbiB0aG9zZSBkb2N1bWVudHMsIHRob3Vn aCB0aGlzPGJyPg0Kb3ZlcnZpZXcgZG9jdW1lbnQgcHJvdmlkZXMgYW4gb3ZlcnZpZXcgb2YgdGhl IHR5cGVzIG9mIHNlY3VyaXR5PGJyPg0KY29uc2lkZXJhdGlvbnMgdG8gYmUgZGlzY3Vzc2VkIGlu IHRob3NlIGRvY3VtZW50cy48YnI+DQo8YnI+DQpUaGUgbWFqb3IgY29tcG9uZW50cyBvZiBMTUFQ IGFyZSBhIE1lYXN1cmVtZW50IEFnZW50IChNQSkgdXN1YWxseSByZXNpZGluZzxicj4NCm9uIGN1 c3RvbWVyIHByZW1pc2VzIHRoYXQgcnVucyBwZXJpb2RpYyBwZXJmb3JtYW5jZSB0ZXN0cyBhbmQg cmVwb3J0czxicj4NCnJlc3VsdHMsIGEgQ29udHJvbGxlciB1c3VhbGx5IHJlc2lkaW5nIG9mZi1j dXN0b21lci1wcmVtaXNlcyB0aGF0IGNvbmZpZ3VyZXM8YnI+DQpzb21lIGxhcmdlIGNvbGxlY3Rp b24gb2YgTWVhc3VyZW1lbnQgQWdlbnRzLCBhbmQgYSBDb2xsZWN0b3IgdXN1YWxseTxicj4NCnJl c2lkaW5nIG9mZi1jdXN0b21lci1wcmVtaXNlcyB0aGF0IHJlY2VpdmVzIGFuZCByZWNvcmRzIHJl cG9ydHMgZnJvbSB0aGU8YnI+DQpNZWFzdXJlbWVudCBBZ2VudHMuIFRob3NlIHJlcG9ydHMgbWF5 IGNvbnRhaW4gc3RhdGlzdGljYWwgZGF0YSBjb25jZXJuaW5nPGJyPg0Kbm9ybWFsIG9wZXJhdGlv biBvZiB0aGUgTUEncyBwbGF0Zm9ybSBhcyB3ZWxsIGFzIHRoZSByZXN1bHRzIG9mIHNwZWNpZmlj PGJyPg0KdGVzdHMuIEl0IGlzIHRoZSBDb250cm9sbGVyIHRvIE1BIGFuZCBNQSB0byBDb2xsZWN0 b3IgcHJvdG9jb2xzIHRoYXQgd2lsbDxicj4NCnJlcXVpcmUgcmlnb3JvdXMgc2VjdXJpdHkgYW5h bHlzaXMgYW5kIHdoaWNoIGFyZSBzcGVjaWZpZWQgaW4gZGlmZmVyZW50PGJyPg0KZG9jdW1lbnRz IHdpdGhpbiBMTUFQLiA8c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+PG86cD48L286cD48L3NwYW4+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibHVlIj5bcGhpbF0gdG8gbm90ZSBpbiBwYXNzaW5nLCB0aGV5IG1heSBiZSB0aGUgc2Ft ZSBvciBkaWZmZXJlbnQgcHJvdG9jb2wgKHRoaXMgaXMgdG8gYmUgZGVjaWRlZCk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIHByb3RvY29s cyB3aG9zZSBwZXJmb3JtYW5jZSBpcyBtZWFzdXJlZCBtYXkgYWxzbzxicj4NCnJlcXVpcmUgYSBy aWdvcm91cyBzZWN1cml0eSBhbmFseXNpcywgYnV0IHRoZXkgYXJlIGRlZmluZWQgb3V0c2lkZSBv ZiBMTUFQLjxicj4NCjxicj4NClRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGxp c3RzIHRoZSBzb3J0cyBvZiBpc3N1ZXMgdGhhdCB3aWxsIG5lZWQ8YnI+DQp0byBiZSBkZWFsdCB3 aXRoIGluIHRoZSBvdGhlciBkb2N1bWVudHMuIEl0IGRvZXMgbm90IGdvIGludG8gaG93IHRob3Nl PGJyPg0KaXNzdWVzIGFyZSBhZGRyZXNzZWQ7IHByZXN1bWFibHkgdGhlIGNvbXBhbmlvbiBkb2N1 bWVudHMgZG8uIDxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6Ymx1ZSI+W3BoaWxdIGNvcnJlY3QsIHRoZSBwcm90b2NvbCBkb2Mocykgd2lsbCBoYXZlIHRv IGNvdmVyIHRoaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+VGhlcmUgaXMgYSBtdWNoPGJyPg0KbG9uZ2VyIHByaXZhY3kgY29uc2lkZXJhdGlv bnMgc2VjdGlvbiB0aGF0IGVudW1lcmF0ZXMgYW4gaW50aW1pZGF0aW5nIHNldCBvZjxicj4NCnBv dGVudGlhbCBwcml2YWN5IGFidXNlcyB0aGF0IG5lZWQgdG8gYmUgbWl0aWdhdGVkLjxicj4NCjxi cj4NCkFuIGltcG9ydGFudCBzZWN1cml0eSBjb25zaWRlcmF0aW9uIHRoYXQgSSBkaWRuJ3Qgc2Vl IHdhcyBkZWFsaW5nIHdpdGggdGhlPGJyPg0KY2FzZSBvZiBhIGNvcnJ1cHRlZCBNQSB0aGF0IHJl cG9ydHMgZmFsc2lmaWVkIGluZm9ybWF0aW9uIHRvIHRoZSBjb2xsZWN0b3IuPGJyPg0KVGhpcyBt aWdodCBvY2N1ciBpbiB0aGUgY2FzZSB3aGVyZSBhIGN1c3RvbWVyIHdhbnRzIGl0IHRvIGFwcGVh ciB0aGF0IHRoZTxicj4NCklTUCBpcyBub3QgbWVldGluZyBpdHMgY29tbWl0bWVudHMgd2hlbiBp biBmYWN0IHRoZSBJU1AgaXMuIFdoZXRoZXIgdGhpcyBjYW48YnI+DQpiZSBlZmZlY3RpdmVseSBt aXRpZ2F0ZWQgZGVwZW5kcyBvbiB0aGUgcGxhdGZvcm0gb24gd2hpY2ggdGhlIE1BIGlzPGJyPg0K ZGVwbG95ZWQsIGJ1dCB3aGVyZSB0aGUgTUEgaXMgZGVwbG95ZWQgb24gYSBjdXN0b21lci1jb250 cm9sbGVkIHBsYXRmb3JtIGl0PGJyPg0KbXVzdCBiZSByZWNvZ25pemVkIHRoYXQgdGhlIGRhdGEg Y29sbGVjdGVkIGlzIHRvIHNvbWUgZGVncmVlIGluaGVyZW50bHk8YnI+DQp1bnRydXN0d29ydGh5 LiBUaGlzIG1lYW5zLCBmb3IgZXhhbXBsZSwgdGhhdCBpbiBzdWNoIGNvbmZpZ3VyYXRpb25zIHRo ZSBkYXRhPGJyPg0Kc2hvdWxkIG5vdCBiZSB1c2VkIGFzIHRoZSBiYXNpcyBmb3IgYSBjdXN0b21l ciB0byBnZXQgcmVmdW5kcyBvZjxicj4NCnN1YnNjcmlwdGlvbiBmZWVzLjxzcGFuIHN0eWxlPSJj b2xvcjpibHVlIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibHVlIj5bcGhpbF0gR29vZCBwb2ludC4gRXZlbiBpZiBzb21laG93IHRoZSBNQSBpcyBw cmV2ZW50ZWQgZnJvbSBpbmplY3RpbmcgZmFsc2lmaWVkIHJlcG9ydHMsIGEgc29waGlzdGljYXRl ZCBjdXN0b21lciBjb3VsZCBkaXN0b3J0IHRoZSBtZWFzdXJlbWVudHMgKGVnIGFkZCBib3ggdGhh dCBkcm9wcw0KIHBhY2tldHMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkkgd2lsbCBhZGQgc29tZXRo aW5nIGFib3V0IHRoaXMuIHRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8 YnI+DQpJIHNhdyB0d28gcXVlc3Rpb25hYmxlIGFzcGVjdHMgb2YgdGhlIGRlc2lnbiAoYXQgdGhp cyBsZXZlbCBvZiBhYnN0cmFjdGlvbikuPGJyPg0KPGJyPg0KVGhlIGZpcnN0IGhhcyB0byBkbyB3 aXRoIHdobyBpbml0aWF0ZXMgdGhlIENvbnRyb2xsZXIgdG8gTUEgY29ubmVjdGlvbi4gVGhpczxi cj4NCnNwZWMgc2VlbXMgdG8gaW1wbHkgdGhhdCB0aGUgY29ubmVjdGlvbiBjYW4gYmUgaW5pdGlh dGVkIGZyb20gZWl0aGVyIGVuZC4uLjxicj4NCnRoZSBDb250cm9sbGVyIGNhbiBpbml0aWF0ZSBh IGNvbm5lY3Rpb24gdG8gdGhlIE1BIHdoZW4gaXQgd2FudHMgdG8gdXBkYXRlPGJyPg0KdGhlIE1B J3MgY29uZmlndXJhdGlvbiBhbmQgdGhlIE1BIGFuZCBpbml0aWF0ZSBhIGNvbm5lY3Rpb24gdG8g dGhlPGJyPg0KY29udHJvbGxlciB0byByZXBvcnQgZXJyb3JzIGFuZCBsb2cgZGVidWdnaW5nIGlu Zm9ybWF0aW9uLiBUaGlzIGlzPGJyPg0KcHJvYmxlbWF0aWMgZm9yIHNldmVyYWwgcmVhc29ucy4g TW9zdCBpbXBvcnRhbnRseSwgaW4gbWFueSBzY2VuYXJpb3MgdGhlIE1BPGJyPg0KbWlnaHQgbW92 ZSBhcm91bmQgYW5kIHRoZXJlZm9yZSBiZSBkaWZmaWN1bHQgZm9yIHRoZSBDb250cm9sbGVyIHRv IGZpbmQ7IG9yPGJyPg0KaXQgbWlnaHQgYmUgYmVoaW5kIGEgTkFUIG9yIG90aGVyIGZpcmV3YWxs IGFuZCBtaWdodCBub3QgYmUgY2FwYWJsZSBvZjxicj4NCmFjY2VwdGluZyBpbmNvbWluZyBjb25u ZWN0aW9ucyAoYXQgbGVhc3Qgbm90IHdpdGhvdXQgYSBsb3Qgb2YgYWRkaXRpb25hbDxicj4NCmVm Zm9ydCkuIElmIGFsbCBzdWNoIGNvbm5lY3Rpb25zIHdlcmUgaW5pdGlhdGVkIGJ5IHRoZSBNQSwg aW5jbHVkaW5nIGE8YnI+DQpwb2xsaW5nIGludGVydmFsIGNvbmZpZ3VyZWQgYnkgdGhlIGNvbnRy b2xsZXIsIHN1Y2ggY29uZmlndXJhdGlvbiBpc3N1ZXMgZ288YnI+DQphd2F5Ljxicj4NCjxicj4N CkFsdGVybmF0ZWx5LCBpZiB0aGUgQ29udHJvbGxlciBpbml0aWF0ZWQgYWxsIGNvbm5lY3Rpb25z LCBpdCBiZWNvbWVzIG11Y2g8YnI+DQplYXNpZXIgdG8gcHJvdGVjdCB0aGUgQ29udHJvbGxlciBm cm9tIERvUyBhdHRhY2tzLCBzaW5jZSBpdCBpcyBnZW5lcmFsbHk8YnI+DQptdWNoIGVhc2llciB0 byBhdHRhY2sgYSBzZXJ2ZXIgdGhhbiBhIGNsaWVudC4gQnV0IGhhdmluZyBjb25uZWN0aW9ucyBi ZWluZzxicj4NCmluaXRpYXRlZCBmcm9tIGJvdGggZGlyZWN0aW9ucyBnaXZlcyB0aGUgd29yc3Qg b2YgYm90aCB3b3JsZHMuPHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPjxvOnA+PC9vOnA+PC9zcGFu Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPltwaGlsXSZuYnNwOyBXZeKA mXZlIGRpc2N1c3NlZCB0aGlzIGEgYml0IChmb3IgZXhhbXBsZSwgbmVhciB0aGUgZW5kIG9mIHRo ZSBEdWJsaW4gaW50ZXJpbSkuIEkgdGhpbmsgcGVvcGxlIGZhdm91ciB0aGUgZm9ybWVyIGFwcHJv YWNoIOKAkyB0aGUgTUEgcmVndWxhcmx5IGNhbGxzIGluIHRvIGNoZWNrDQogaWYgdGhlIGNvbmZp ZyAvaW5zdHJ1Y3Rpb24gaGFzIGNoYW5nZWQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SeKAmW0gbm90IHN1cmUgd2hldGhlciB0aGlzIGRvYyBzaG91 bGQgc3RhdGUgdGhhdCwgb3IgZ2l2ZSB0aGUgcHJvcyBhbmQgY29ucyAoeW91ciB0ZXh0IGFib3Zl KSDigJMgdGhlIGxhdHRlciB3b3VsZCBiZSB0aGUgZGVmYXVsdCwgdGhvdWdoIHBlcnNvbmFsbHkg SSB3b3VsZG7igJl0IG1pbmQgaWYNCiB3ZSBzYWlkIHRoZSBmb3JtZXIuIFdoYXQgYXBwcm9hY2gg ZG8gcGVvcGxlIHByZWZlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQpU aGUgc2Vjb25kIGhhcyB0byBkbyB3aXRoIHRoZSBNQSBzZW5kaW5nIGVycm9yIGFuZCBsb2cgcmVw b3J0cyB0byB0aGU8YnI+DQpDb250cm9sbGVyLiBXaGlsZSBpdCBtYWtlcyBzZW5zZSBmb3IgdGhl IE1BIHRvIHJlcG9ydCBlcnJvcnMgdGhhdCBvY2N1ciBpbjxicj4NCnByb2Nlc3NpbmcgQ29udHJv bGxlciBJbnN0cnVjdGlvbnMgaW4gdGhlIHJlc3BvbnNlcyB0byB0aG9zZSBjb21tYW5kcyw8YnI+ DQplcnJvcnMgYW5kIGxvZ2dlZCBldmVudHMgdGhhdCBvY2N1ciBhc3luY2hyb25vdXNseSB3b3Vs ZCBzZWVtICh0byBtZSBhbnl3YXkpPGJyPg0KYXMgbW9yZSBuYXR1cmFsbHkgYmVpbmcgc2VudCB0 byB0aGUgQ29sbGVjdG9yLCBzaW5jZSBpdHMgam9iIGlzIHRvIGhhcnZlc3Q8YnI+DQptYXNzaXZl IGFtb3VudHMgb2YgaW5mb3JtYXRpb24gZnJvbSBsb3RzIG9mIE1Bcy4gSXQgaXMgbGlrZWx5IHRv IGJlIG1vcmU8YnI+DQpoaWdobHkgcmVwbGljYXRlZCBhbmQgbG9hZCBiYWxhbmNlZCB0aGFuIHRo ZSBDb250cm9sbGVyLCBhbmQgdGh1cyBtb3JlPGJyPg0KY2FwYWJsZSBvZiBoYW5kbGluZyBidXJz dHkgbG9hZHMuIEJ1dCB0aGlzIGhhcyBsaXR0bGUgdG8gZG8gd2l0aCBzZWN1cml0eSw8YnI+DQph bmQgSSB0aHJvdyBpdCBvdXQgb25seSBmb3IgeW91ciBjb25zaWRlcmF0aW9uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPltw aGlsXSBJIGd1ZXNzIGl0IGRlcGVuZHMgaG93IG11Y2ggdHJhZmZpYyBpcyBnZW5lcmF0ZWQg4oCT IGluIGdlbmVyYWwgSSBkb27igJl0IHRoaW5rIHRoZXJl4oCZbGwgYmUgbXVjaCwgc28gSeKAmW0g aW5jbGluZWQgdG8gZGlzYWdyZWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPk5vdGUgaWYgdGhlIENv bGxlY3RvciBkaWQgZ2V0IHRoaXMgaW5mb3JtYXRpb24sIHRoZSBDb250cm9sbGVyIHdvdWxkIGhh dmUgdG8gYmUgdG9sZCBhdCBsZWFzdCBhIHN1bW1hcnksIHNvIGl0IGNvdWxkIG1vZGlmeSB0aGUg aW5zdHJ1Y3Rpb25zIGFzIGFwcHJvcHJpYXRlLiAoQSBjb250cm9sbGVyLWNvbGxlY3Rvcg0KIGlu dGVyZmFjZSBpcyBvdXQgb2Ygc2NvcGUsIGF0IHRoaXMgc3RhZ2UuKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bHVlIj5BbnkgdGhvdWdodHM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPlJhZGlhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9904FB1B0159DA42B0B887B7FA8119CA5C90BD8BAZFFEXMB04globa_-- From nobody Sat Nov 22 11:40:22 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 31B891A011F; Sat, 22 Nov 2014 11:40: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 5CQWoKFlhlM0; Sat, 22 Nov 2014 11:40:17 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A3C1A00E8; Sat, 22 Nov 2014 11:40:17 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id bs8so5620772wib.3 for ; Sat, 22 Nov 2014 11:40:16 -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 :content-type:content-transfer-encoding; bh=R9BKncl9lpH1dCKZgcGrlX2ABpLV3ZLAsLlKo91YGjU=; b=FBrsqJqnhY8rOT1tl00vwB8mI6ovX+Mv99LvJwwHhxFVwCKnzJW3XxRUAVRJHdWzl+ Kt7m9bM7zT4dUr3Uuoy1mZ8TIuvy6wUzhCUctHU1FjNKtRyORBQUzk34zVVPx19Y/WRm qUFjxCkF3dqKaFmPYUQ6SdBd0acmBqbG24T4y+4umLOFCii6evrMkClt/jb6DSE49IBE 5jiW37j2j2LOB6SMz7B7f3uAogEY/9C+Uvh8NaYNcCwBZV4E+XV6RYCCYtmfd9UrsoXU AxuU0GxonFFoWYP1dbYkvT4Uz8XCH/J3PqmzOWCnX4vu2Ylg0WgDE8tGujNmh44YTDwn 2UPw== X-Received: by 10.180.218.133 with SMTP id pg5mr7889617wic.70.1416685215958; Sat, 22 Nov 2014 11:40:15 -0800 (PST) Received: from [10.0.0.6] ([109.64.160.108]) by mx.google.com with ESMTPSA id j2sm13370361wjs.28.2014.11.22.11.40.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Nov 2014 11:40:15 -0800 (PST) Message-ID: <5470E68D.3040204@gmail.com> Date: Sat, 22 Nov 2014 21:39:57 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: IETF Security Directorate , The IESG , draft-ietf-jose-cookbook.all@tools.ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/fwAjyz93HAITT_mmsT8W4mbm6xc Subject: [secdir] SecDir review of draft-ietf-jose-cookbook-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: Sat, 22 Nov 2014 19:40:19 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document contains a large set of examples of JOSE objects: JWK, JWS and JWE. The document is purely informational, though in "real life", I would expect developers to use it as an authoritative source. Summary The document is ready to be published, with some issues. By the way, I really appreciate the large effort that surely went into creating this document. Details • Unless I missed it, the document does not mention a machine readable repository of these examples, which I am sure the author has created while writing the draft. Making such a repository publicly available would result in a much more useful resource than the current document, which essentially requires testers to scrape the document when creating their test cases. • (Not a comment to the current document:) I wonder why there is nothing explicit to distinguish a public key from a private key, and they are only distinguished by the presence or absence of several parameters, something that will not be natural to most developers. PEM is doing it very well: "-----BEGIN RSA PRIVATE KEY-----". • 3.4: the text is contradictory re: zero-padding of the value "d". Is it using the minimum number of octets, or exactly 256 octets (for a 2048-bit key)? • Why invent a new term "octet key", for a simple "symmetric key"? • 4.2: the first sentence discusses PS256, the actual example is PS384. • 4.7: "only the JSON serialization" - please clarify which of the three serializations is meant. Ditto top of 4.8. • 5.1.1: since this is a "cookbook", we should be using the public key, not the private key. A private key would only be used in rare cases. Similarly 5.2.1. • 5.3.1: the "plaintext content" is a list of keys, which is either confusing to the reader, or an actual error in the document. • 5.3.5: In the General Serialization version, I don't understand why only the encrypted key is per-recipient. I would expect the PBES2 parameters too (e.g., the salt) to be per-recipient. Presumably each of them is using a different password, and there's no reason to use a common salt. Similarly in 5.4.5. • 5.7: same as above, it makes sense for the per-recipient key to have an ID, rather than the content encryption key (typically an ephemeral key). And then that ID should be in the per-recipient data in 5.7.5. And similarly for 5.8. The later Sec. 5.13 shows a syntax for multiple recipients that's inconsistent with the single-recipient case, which would make sense if we got rid of the array. • 5.11: this example seems strange to me - why would anybody NOT want to integrity-protect the key ID and algorithm? I would prefer a more realistic example, or failing that, a recommendation to developers to avoid this practice. Similarly 5.12, which is an even worse idea. Thanks, Yaron From nobody Sun Nov 23 05:24: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 465471A0217 for ; Sun, 23 Nov 2014 05:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 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.594] 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 yv4EqyFBk6mW for ; Sun, 23 Nov 2014 05:24:25 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 13D3A1A024C for ; Sun, 23 Nov 2014 05:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1416749062; d=isode.com; s=selector; i=@isode.com; bh=s6sOWdjDfSTmjyTequItcEWN/5ZybO/zO3NV1k/bYZI=; 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=JbLImX+GrzliGeoprOVNVkLDn1JRCFGMBaZ4fHhBaUJhxk2uqgmAl27YYCFxDdbxuc55Nv wSE7krwVHeuX/PTjcB5g9tv+ro7HC2Y6KBoQVhsCVHHmczpasspAkFQbN3xwYrxBRxjQN9 aQEg9DGacQcx/Q7WrDo9uoUAhELjCrU=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 23 Nov 2014 13:24:21 +0000 Message-ID: <5471DFFC.8080502@isode.com> Date: Sun, 23 Nov 2014 13:24:12 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: IETF Security Directorate , draft-ietf-opsawg-mibs-to-ieee80231.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/ZReraYAhN5jPBFGoUp3Rai9wc9k Subject: [secdir] SecDir review of draft-ietf-opsawg-mibs-to-ieee80231-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: Sun, 23 Nov 2014 13:24: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. The document formally transfers ownership of several IETF MIBs to IEEE. I agree with the Security Considerations section that there are no security considerations associated with this action. Summary The document is ready to be published. From nobody Sun Nov 23 19:21: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 9EF111A1BB1; Sun, 23 Nov 2014 19:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 tlkovY8F8ntK; Sun, 23 Nov 2014 19:21:19 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07321A1BB3; Sun, 23 Nov 2014 19:21:19 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id m8so6510505obr.13 for ; Sun, 23 Nov 2014 19:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=e++eVlKdX4a+2SEEoRAgxPBY1M1hswk3pFh1KM5/gWo=; b=duaFG61zk1KO1hB544ynLaNURNWFhKR6NHxGNoIZQXEvyb5DcaKYW2xdFIXIMYqfev H8aLT699lEeFN/aiEahyeLEfb/a9Qt0ESGY281oRXJ7F1kcS3mo3fgikYrMWXGYB5DyY 0JHpHLPs2oePFIuR1KqrnX3eHVLtFODbokM0FrizLTuXR9DMGbalajgzDIScDaAj2qeR YAetSADPEzwbcWFTo9hwxnjHPcn0kFCCPtJTUSOxGUsbxk5n1xbT2HHioD0fsoegD67t vcoVkYiCOEfRHy9OTRwMjxsufuRpnbur3LT9fT+r46b88+2m9SZ5Uaxuso0m+CSRVg+d UvBw== X-Received: by 10.202.111.3 with SMTP id m3mr6122922oic.16.1416799278934; Sun, 23 Nov 2014 19:21:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.145.4 with HTTP; Sun, 23 Nov 2014 19:20:58 -0800 (PST) From: Donald Eastlake Date: Sun, 23 Nov 2014 22:20:58 -0500 Message-ID: To: "iesg@ietf.org" , "draft-leiba-cotton-iana-5226bis.all@tools.ietf.org" , "secdir@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/NhP2p73jnoehsHw2eG5SkA28j0I Subject: [secdir] SECDIR review of draft-leiba-cotton-iana-5226bis-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, 24 Nov 2014 03:21:20 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This is a re-review. All of my comments on version -08 have been resolved in this version as per my discussions with Barr Leiba. In addition, I reviewed all other changes from -08 to -11 and did not see an problems. I believe this document is ready for publication. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Sun Nov 23 21:15: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 ABEB71A1BD6 for ; Sun, 23 Nov 2014 21:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 gAgxhnEjqjkU for ; Sun, 23 Nov 2014 21:15:12 -0800 (PST) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6407B1A1BD2 for ; Sun, 23 Nov 2014 21:15:12 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id hy4so1766642vcb.2 for ; Sun, 23 Nov 2014 21:15:11 -0800 (PST) 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=/A4P9GtGyxcKXf/E5jvb/tV3LFONewF4YTlcXmahznQ=; b=fSbxxYmqX6D1+b5ymgZNf518Aoa+JA6jfcfLeqbbTFdiTHSu4tPosSyMA+mnDFnfTh jgR2tydJ6NF3pyfMgkE3rCM59M6OpGbvs3MDEOdaIPAmLXQIAl4VRRvg+YUoDuSKFmb/ KdcOMZ17IdItGpBjeDI/d93ydm8wEHENyqNg3fC6L78nXlREQuFruWeB+/4P0f6lMogu SdkRUDFS9EOBvjguDTKvEcWLCNVGkEhizE5Wlcxk1ZlNwDMylLNWx+vnVAL8rmWBO+Rz EdY8Bk4FKR4kmOH/bGI1AmdUHY9D/38e4UJQ+JY41OqYodqD6Bbe41LM786+/5AiiNta 6zhQ== X-Gm-Message-State: ALoCoQn8oqE35CH3CZ3uv5l6Ut/Bs4W7d+4j6rpiDhMWiZrueuxv48GciUaMp90HKaZCIILPgK7u MIME-Version: 1.0 X-Received: by 10.52.167.129 with SMTP id zo1mr9751217vdb.9.1416806111457; Sun, 23 Nov 2014 21:15:11 -0800 (PST) Received: by 10.31.58.144 with HTTP; Sun, 23 Nov 2014 21:15:11 -0800 (PST) In-Reply-To: References: Date: Mon, 24 Nov 2014 10:45:11 +0530 Message-ID: From: Manav Bhatia To: Samuel Weiler Content-Type: multipart/alternative; boundary=089e0160c0befd48cf050893e017 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ImPsf-cd9hlIjQ-YxmMYwN4PFvc Cc: draft-ietf-karp-bfd-analysis.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-karp-bfd-analysis-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, 24 Nov 2014 05:15:14 -0000 --089e0160c0befd48cf050893e017 Content-Type: text/plain; charset=UTF-8 Hi Sam, I work for a fledgling startup and am able to spare very few cycles to IETF and hence the delay. Please accept my apologies for that. > In the other other two cases, I am not satisfied with the discussion to > date. > > Theoretically the two should use algorithms of similar strength. >> > > Why? (Explain your theory...) The attack vector for the BFD and the routing protocols would be similar. There is no evidence (empirical or otherwise) till date that proves that attacking one is more complex than the other. > > In fact one could argue that BFD needs stronger algorithm since an attack >> on BFD can bring down all your control protocols. >> > > Has the WG had that discussion? I thought this was common wisdom. If i were an attacker then i would aim at bringing down BFD since it brings down the entire network along with it. Given that its usually run in plaintext i would think that its the weakest link. > > > Lastly, RFC5880 (the BFD spec) says: >> An attacker who is in complete control of the link between >> the >> systems can easily drop all BFD packets but forward >> everything else >> (causing the link to be falsely declared down), or forward >> only the >> BFD packets but nothing else (causing the link to be falsely >> declared up). This attack cannot be prevented by BFD. >> >> Given that, does it make sense to go to this pain to replace MD5 >> and SHA1? >> >> >> Sure, but such attacks are outside the scope of routing protocol security. >> > > Do we have a solid definition of that scope? (Where?) > > And how vulnerable would BFD be to off-link attackers anyway? Are we > doing all of this work solely to defend against on-link attackers who have > only _incomplete_ control of the link? (It may well be a stupid question, > but, if it is stupid, then it should at least have an easy answer, right?) > Such attacks are out of scope. You can look at RFC 6862, section 3.3 Cheers, Manav > > -- Sam --089e0160c0befd48cf050893e017 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sam,

I work for a fledgling=C2=A0sta= rtup and am able to spare very few cycles to IETF and hence the delay. Plea= se accept my apologies for that.


In the other other two cases, I am not satisfied with the discussion to dat= e.

Theoretically the two should use algorithms of similar strength.

 Why?=C2=A0 (Explain your theory...)

=C2=A0T= he attack vector for the BFD and the routing protocols would be similar. Th= ere is no evidence (empirical or otherwise) till date that proves that atta= cking one is more complex than the other.



In fact one could argue that BFD needs stronger algorithm since an attack o= n BFD can bring down all your control protocols.

 Has the WG had that discussion?

I thought t= his was common wisdom. If i were an attacker then i would aim at bringing d= own BFD since it brings down the entire network along with it. Given that i= ts usually run in plaintext i would think that its the weakest link.
<= div>=C2=A0


=C2=A0 =C2=A0 =C2=A0 Lastly, RFC5880 (the BFD spec) says:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0An attacker who is in complete control of= the link between
=C2=A0 =C2=A0 =C2=A0 the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0systems can easily drop all BFD packets b= ut forward
=C2=A0 =C2=A0 =C2=A0 everything else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(causing the link to be falsely declared = down), or forward
=C2=A0 =C2=A0 =C2=A0 only the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD packets but nothing else (causing the= link to be falsely
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0declared up).=C2=A0 This attack cannot be= prevented by BFD.

=C2=A0 =C2=A0 =C2=A0 Given that, does it make sense to go to this pain to r= eplace MD5
=C2=A0 =C2=A0 =C2=A0 and SHA1?


Sure, but such attacks are outside the scope of routing protocol security.<= br>

Do we have a solid definition of that scope?=C2=A0 (Where?)

And how vulnerable would BFD be to off-link attackers anyway?=C2=A0 Are we = doing all of this work solely to defend against on-link attackers who have = only _incomplete_ control of the link?=C2=A0 (It may well be a stupid quest= ion, but, if it is stupid, then it should at least have an easy answer, rig= ht?)

Such attacks are out of scope. You= can look at RFC 6862, section 3.3

Cheers, Manav= =C2=A0

-- Sam

--089e0160c0befd48cf050893e017-- From nobody Tue Nov 25 13:24:12 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 809C61A875C; Tue, 25 Nov 2014 13:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1416950063; bh=Y4d2t1FegxuREBt5vK6R5fxEKbCse29Fzyi9zmnPdwo=; 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=U4RXh5/jPyAOLiqT4/h1ZdpLdMdEKdkelJsqz1J2uUUAUg8bkEKJaJ/FWRy/KRJM0 /YBsRFXBypGLkdFNj8qMDv6hOWWhoeGHLRM3K0vTt3cU1YE9plYLp0dtDWfrUB4otR 21U5/BTlttwjBR8WwlNxmAe8SYIfWZyUoI5oko3g= 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 4E3B11A6FF7; Tue, 25 Nov 2014 13:13:07 -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 BgnFVPS__xdP; Tue, 25 Nov 2014 13:13:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EA51A7012; Tue, 25 Nov 2014 13:13:05 -0800 (PST) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141125211305.29982.31871.idtracker@ietfa.amsl.com> Date: Tue, 25 Nov 2014 13:13:05 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/raih-LkITlkeUwA3y14fpJgwVI8 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" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/q--US75xBHd4c6iSgVWTpKLIDC4 X-Mailman-Approved-At: Tue, 25 Nov 2014 13:22:20 -0800 Subject: [secdir] [new-work] WG Review: Traffic Engineering Architecture and Signaling (teas) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 21:14:24 -0000 A new IETF working group has been proposed in the Routing 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-12-02. Traffic Engineering Architecture and Signaling (teas) ------------------------------------------------ Current Status: Proposed WG Chairs: Deborah Brungard Lou Berger Assigned Area Director: Adrian Farrel Mailing list Address: teas@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/teas Archive: http://www.ietf.org/mail-archive/web/teas/ Charter: The Traffic Engineering Architecture and Signaling (TEAS) Working Group is responsible for defining MPLS and GMPLS traffic engineering architecture, standardizing the RSVP-TE signaling protocol, and identifying required related control-protocol functions, i.e., routing and path computation element functions. Traffic Engineering (TE) is the term used to refer to techniques that enable operators to control how specific traffic flows are treated within their networks. TE is applied to packet networks via MPLS TE tunnels and LSPs. The MPLS-TE control plane was generalized to additionally support non-packet technologies via GMPLS. RSVP-TE is the signaling protocol used for both MPLS-TE and GMPLS. The TEAS WG is responsible for: a) Traffic-engineering architectures for generic applicability across packet and non-packet networks. This includes both networks that include the use of PCE and those that do not. The PCE architecture itself is out of the WG scope. b) Definition of protocol-independent metrics and parameters (measurement and/or service attributes) for describing links and tunnels/paths required for traffic engineering (and related routing, signaling and path computation). These will be developed in conjunction with requests and requirements from other WGs to ensure overall usefulness. c) Functional specification of extensions for routing (OSPF, ISIS) and for path computation (PCE) to provide general enablers of traffic-engineering systems that also use RSVP-TE. Protocol formats and procedures that embody these extensions will be done in coordination with the WGs supervising those protocols. d) Functional specification of generic (i.e., not data plane technology-specific) extensions for RSVP-TE, and the associated protocol formats and procedures that embody these extensions. e) Definition of control plane mechanisms and extensions to allow the setup and maintenance of TE paths and TE tunnels that span multiple domains and/or switching technologies, where a domain may be an IGP area, an Autonomous System, or any other region of topological visibility. f) Definition and extension of management and security techniques for RSVP-TE signaling. This includes configuring and monitoring RSVP-TE as well as mechanisms used to configure, control, and report OAM within TE networks. YANG and MIB modules may be considered. The TEAS working group is chartered to deliver the following: 1. Definition of additional abstract service, link, and path properties such as jitter, delay, and diversity. Extensions to IGPs to advertise these properties, and extensions to RSVP-TE to request and to accumulate these properties. Work with PCE WG to include these properties in computation requests. 2. Specification of terminology, architecture, and protocol requirements for abstraction and distribution of TE information between interconnected TE domains/layers. 3. Specification and protocol extensions for a GMPLS External Network-to-Network Interface (E-NNI), i.e., multi-domain GMPLS support. 4. Protocol mechanisms to signal associated LSPs in particular with different source nodes. 5. Requirements and protocol extensions for additional protection mechanisms including end-point protection, protection of P2MP LSPs, and inter-domain protection. 6. YANG models for a Traffic Engineering Database in coordination with working groups working on YANG models for network topology and for technology-specific network attributes. Requirements may be documented in stand-alone RFCs, may be folded into architecture or solutions RFCs, may be recorded on a wiki, or may be documented in an Internet-Draft that is not progressed to RFC. The TEAS WG will coordinate with the following working groups: - With the MPLS WG to maintain and extend MPLS-TE protocol mechanisms and to determine whether they should be generalized. - With the CCAMP WG to maintain and extend non-packet, data plane technology-specific TE protocol mechanisms and to determine whether they should be generalized. - With the OSPF and ISIS WGs to maintain or extend TE routing mechanisms for MPLS-TE and GMPLS. - With the PCE WG on uses of a PCE in the traffic-engineering architecture, on PCE extensions per the above, and on RSVP-TE extensions to support PCE WG identified requirements. - With the IDR WG on the use of BGP-LS in TE environments. In doing this work, the WG will cooperate with external SDOs (such as the ITU-T and the IEEE 802.1) as necessary. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Tue Nov 25 13:52:36 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 547561A890C; Tue, 25 Nov 2014 13:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1416950724; bh=hPZIeicoKTfqy4O3Go1WlUDtwvU9QKeBGPtWUu8wtws=; 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=jQ6V0QY9hQHm4QXm6Ph6+jtWO7CsdY2hEzg1szhEYpvhkBOK0C9/Tfbq2CdlEvvyO o4LH4dny7mbtPXiGXfVD7oegRTyLffCzFnQExxde/LiezZH8HXWdP1zbh0ZTS8i7Ti bmnaOa3sZNRMTWCzHqnJ9sZMJDewsVVWqqNx4q1Y= 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 EA5DB1A88F7; Tue, 25 Nov 2014 13:23:52 -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 mFADE3ePSbIw; Tue, 25 Nov 2014 13:23:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E581A88EA; Tue, 25 Nov 2014 13:23:51 -0800 (PST) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141125212351.31017.12507.idtracker@ietfa.amsl.com> Date: Tue, 25 Nov 2014 13:23:51 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/1Y0uiGs8CNrAgyaw413o7a_x5Do 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" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/aiosYG1nLexPxNr61RwWFxkLeLM X-Mailman-Approved-At: Tue, 25 Nov 2014 13:50:42 -0800 Subject: [secdir] [new-work] WG Review: Common Control and Measurement Plane (ccamp) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 21:25:24 -0000 The Common Control and Measurement Plane (ccamp) working group in the Routing 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-12-02. Common Control and Measurement Plane (ccamp) ------------------------------------------------ Current Status: Active WG Chairs: Lou Berger Deborah Brungard Secretaries: Daniele Ceccarelli Assigned Area Director: Adrian Farrel Mailing list Address: ccamp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ccamp Archive: http://www.ietf.org/mail-archive/web/ccamp/ Charter: The CCAMP working group is responsible for standardizing a common control plane and a separate common measurement plane for non-packet technologies found in the Internet and in the networks of telecom service providers (ISPs and SPs). Examples of the devices in such networks include photonic cross-connects, OEO switches, ROADMs, TDM switches, microwave links, and Ethernet switches. In this context, measurement refers to the acquisition and distribution of attributes relevant to the setting up of tunnels and paths. The working group develops extensions to core Traffic Engineering protocols that are under the care of other working groups. The CCAMP working group will coordinate with the TEAS working group to ensure that extensions that can be generalized for use with more than one technology are made appropriately, and with the working groups that have responsibility for the specific protocols. CCAMP WG work scope includes: - Definition of protocol-independent metrics and parameters (measurement attributes) for describing links and paths that are required for routing and signaling in technology-specific networks. These will be developed in conjunction with requests and requirements from other WGs to ensure overall usefulness. - Maintenance and extension of the Link Management Protocol (LMP). - Functional specification of extensions for GMPLS-related routing (OSPF, ISIS) and signaling (RSVP-TE) protocols required for path establishment and maintenance in non-packet, technology-specific networks. Protocol formats and procedures that embody these extensions will be done jointly with the WGs supervising those protocols and the TEAS working group has the responsibility to determine whether such protocol extensions should be generalized for Traffic Engineering in any network. This may include protocol work to support data planes that have already been approved by another Standards Development Organization. Note that the specification or modification of data planes is out of scope of this working group - Definition of management objects (e.g., as part of MIB modules or YANG models) and control of OAM techniques relevant to the protocols and extensions specified within the WG. The OAM work will be synchronized with the LIME WG - Describe non-packet-specific aspects of traffic engineering including for multi-areas/multi-AS/multi-layer scenarios and define protocol extensions in cooperation with the TEAS and PCE working groups. - Define how the properties of network resources gathered by a measurement protocol (or by other means such as configuration) can be distributed in existing routing protocols, such as OSPF, IS-IS, and BGP-LS. CCAMP will work with the WGs that supervise these The CCAMP WG currently works on the following tasks: - Protocol extensions in support of WSON. - Protocol extensions in support of flexible grid lambda networks. - Maintenance of existing protocol extensions for non-packet technology-specific networks (Ethernet, TDM, OTN) already specified by CCAMP. - Maintenance of LMP. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Tue Nov 25 13:52:38 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 672C01A8917; Tue, 25 Nov 2014 13:30:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1416951002; bh=dSNJvSazI+R/QkKzhZomkmhW6iw3R6OwKFdgwHfGcak=; 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=Fz3EY4iXyg6OBbvA51KByPKSuJMv5lRl1BFkUO6OoriTunW3XLVHG48hixQilk3XC b0jp2Awe601KoaN+GI2wrUlUfskqkur9/lqg20WBqq5UvXV9DsfTXh9kq5xd0j/K7w rYN16QDJN1U54fBlqYlqpbmHuUDeQeMOI4Hghg78= 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 CC6D81A88FA; Tue, 25 Nov 2014 13:28:26 -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 C0oO2hFDpYGr; Tue, 25 Nov 2014 13:28:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3350F1A878C; Tue, 25 Nov 2014 13:28:25 -0800 (PST) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141125212825.8679.58036.idtracker@ietfa.amsl.com> Date: Tue, 25 Nov 2014 13:28:25 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/6x0kTIf5BIGpV8ox9N-8BqULMMQ 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" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/HcSaEbpBlQ9cx2rjavNU0oLyywc X-Mailman-Approved-At: Tue, 25 Nov 2014 13:50:44 -0800 Subject: [secdir] [new-work] WG Review: Multiprotocol Label Switching (mpls) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 21:30:02 -0000 The Multiprotocol Label Switching (mpls) working group in the Routing 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-12-02. Multiprotocol Label Switching (mpls) ------------------------------------------------ Current Status: Active WG Chairs: Loa Andersson George Swallow Ross Callon Secretaries: Martin Vigoureux Assigned Area Director: Adrian Farrel Mailing list Address: mpls@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mpls Archive: http://www.ietf.org/mail-archive/web/mpls/ Charter: The MPLS working group is responsible for standardizing technology for label switching and for the implementation of label-switched paths over packet based link-level technologies. The working group's responsibilities include procedures and protocols for the distribution of labels between Label Switching Routers (LSRs), MPLS packet encapsulation, and for Operation, Administration, and Maintenance (OAM) including the necessary management objects expressed as YANG models or MIB modules. The current WG focus areas and work items are: - Maintain existing MPLS requirements, mechanisms, and protocols, as currently documented in RFCs, in coordination with other working groups that work in overlapping areas including the BESS, BFD, CCAMP, OPSAWG, PALS, SPRING, and TEAS working groups. - Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE for packet networks, and LSP Ping to meet new requirements. - Document MPLS-specific aspects of traffic engineering including for multi-areas/multi-AS scenarios in cooperation with the TEAS working group. - Coordinate the work on RSVP-TE with CCAMP and TEAS. In the cases where there is an overlap, generic parts will be done by the TEAS working group, MPLS data plane specific parts will be done by the MPLS working group, and support for any other specific data planes will be done by the CCAMP working group. The TEAS working group acts as the hub for coordinating this work, and the MPLS working group will track agreements about work to be done in this working group through milestones in this charter. - Define data models for MPLS working group related solutions. YANG models and MIB modules may be considered. Coordinate with the LIME and NETMOD working groups for core YANG models. - Define an overall OAM framework for topology-driven, traffic engineered, and transport profile MPLS applications. - Define the necessary extensions for MPLS key protocols for dual- stack and IPv6-only networks. - Document current implementation practices for MPLS load sharing. - Document mechanisms for securing MPLS protocols and data plane. - Document mechanisms for adding multi-topology support to existing MPLS protocols. - Define the necessary protection protocols and scenarios for transport profile MPLS applications - Document use cases for MPLS protocols. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu Nov 27 01:50: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 C0A2F1A88BD for ; Thu, 27 Nov 2014 01:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.269 X-Spam-Level: X-Spam-Status: No, score=0.269 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 GLntQe50onUe for ; Thu, 27 Nov 2014 01:50:49 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B30861A88BA for ; Thu, 27 Nov 2014 01:50:48 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sAR9ojog004915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 27 Nov 2014 11:50:45 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sAR9ojML026221; Thu, 27 Nov 2014 11:50:45 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21622.62453.110044.679950@fireball.kivinen.iki.fi> Date: Thu, 27 Nov 2014 11:50:45 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/2f4jUNcJEEy4pHRPGBT1fORIwPs 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 Nov 2014 09:50:52 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Dacheng Zhang is next in the rotation. For telechat 2014-12-04 Reviewer LC end Draft Sandy Murphy T 2014-11-25 draft-mcdonald-ipps-uri-scheme-16 For telechat 2014-12-18 Sean Turner T 2014-12-15 draft-ietf-ianaplan-icg-response-06 Carl Wallace T 2014-12-05 draft-ietf-json-text-sequence-09 Last calls and special requests: Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-07 Tero Kivinen E None draft-richardson-6tisch--security-6top-04 Matt Lepinski 2014-11-18 draft-nottingham-safe-hint-05 Catherine Meadows 2014-11-10 draft-ietf-opsawg-capwap-hybridmac-06 Magnus Nystrom 2014-12-01 draft-josefsson-pkix-textual-08 Hilarie Orman E None draft-richardson-6tisch--security-6top-04 Vincent Roca 2014-11-27 draft-ietf-ccamp-rwa-info-22 Joe Salowey 2014-12-01 draft-ietf-tsvwg-sctp-prpolicies-05 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Melinda Shore 2014-12-01 draft-ietf-eman-applicability-statement-08 Takeshi Takahashi 2014-12-01 draft-ietf-grow-irr-routing-policy-considerations-05 Hannes Tschofenig 2014-12-01 draft-ietf-opsec-dhcpv6-shield-04 Tina TSOU 2014-12-08 draft-ietf-dnsop-dnssec-key-timing-06 Sean Turner 2014-10-13 draft-ietf-mpls-lsp-ping-relay-reply-05 David Waltermire 2014-12-09 draft-ietf-kitten-cammac-00 Sam Weiler 2014-12-08 draft-ietf-l3vpn-acceptown-community-08 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-12 Brian Weis 2014-12-08 draft-ietf-l3vpn-end-system-04 Klaas Wierenga 2014-12-08 draft-ietf-mpls-tp-te-mib-09 Paul Wouters 2014-12-04 draft-ietf-tcpm-accecn-reqs-07 Tom Yu 2014-12-10 draft-ietf-tls-prohibiting-rc4-01 -- kivinen@iki.fi From nobody Sat Nov 29 16:02:38 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 853FA1A0011; Sat, 29 Nov 2014 16:02:31 -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 h13Foeh0V4Hd; Sat, 29 Nov 2014 16:02:28 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F5BC1A0010; Sat, 29 Nov 2014 16:02:25 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id kq14so8621327pab.26 for ; Sat, 29 Nov 2014 16:02:24 -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 :content-type:content-transfer-encoding; bh=dh5G1NnQWKvi4Xeuq/FGWYOMQ2Hf7vv2Ey021oqPuMY=; b=qWfx7mNptS5bsslU1oPq26e/ukS9IL8qYhU0mYJc+VN6U4NTjEVj13aTeYIswxaEeF coTlFMxs9syuznZRyWxhxxIeBFAnyi7kPpza7lWgVqpFqDjsFfKb/wLFGRU9zonrsYR2 ayEhn3PsJ/8OsPjQPJrRHoGuq49M6JAS8LsM/MabOYmVxqbjDO1O7mVnH4LqzMccmXjI 1SRUdUBtz9tdy8y4c1m8Ji6pWoH8pjN3wNeSPVkoKBgWpWhX/e5ieAD0WQ7FlYMJUFBt XpOSoIEo6Xy/fRJ5ypfaJ6whSZgtRrvzTw2KC7GJKVfBiSC11SJh4LDI9LqJ2pLGvoT0 dR8Q== X-Received: by 10.68.68.206 with SMTP id y14mr84950160pbt.165.1417305744705; Sat, 29 Nov 2014 16:02:24 -0800 (PST) Received: from spandex.local (209-193-46-232-rb1.sol.dsl.dynamic.acsalaska.net. [209.193.46.232]) by mx.google.com with ESMTPSA id pg9sm13558239pdb.71.2014.11.29.16.02.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 29 Nov 2014 16:02:24 -0800 (PST) Message-ID: <547A5E8E.1070002@gmail.com> Date: Sat, 29 Nov 2014 15:02:22 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: draft-ietf-eman-applicability-statement.all@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/_BQEy-zebZ6AjU43CKOkGJ80Zrs Cc: IESG , secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-eman-applicability-statement-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: Sun, 30 Nov 2014 00:02: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. Summary: Security considerations section is insufficient. Otherwise the document is in pretty good shape (with nits). This document is essentially a set of use cases guiding the energy management's (eman) working group's work, as well as providing a description of the relationship of the IETF's eman's framework to other relevant energy monitoring standards. Of particular interest, perhaps, is that eman is using SNMP to convey energy device information. The use cases are very clearly described, and we're grateful for the "essential properties" breakout summaries ("target devices," "how powered," and "reporting") at the bottom of each use case. All that said, I was extremely surprised to get to the "Security considerations" section and find that it consisted of but two generic sentences about SNMP. We are all aware of issues related to the sensitivity of the electric grid, and powered devices, to security vulnerabilities and that this is a time of heightened scrutiny of how the grid is secured. This necessarily extends to monitoring, and there is certainly a *lot* of information that may be gleaned by an attacker from monitoring power consumption, as well as manipulation of the grid by an attacker inserting bogus monitoring messages. There does not appear to have been any work done within the group on developing a threat model for energy monitoring, which strikes me as problematic. However, even in the absence of an interest in developing one, a quick summary of the sorts of attacks that must be considered in the development and deployment of energy monitoring mechanisms strikes me as far, far, far more useful than a one-sentence rundown of generic security mechanisms provided by SNMPv3. Minor comments: 1) This is more by way of guidance, but it should be noted that while the information model may be portable to YANG, netconf, and others, the security models and technologies used to secure those protocols may be (and are) different, and security properties need to be given serious consideration before moving the information model to another conveyance. 2) the I-D nit checker found a number of problems in the references, as well as a few other problems. https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-eman-applicability-statement-08.txt Trivial nits: 1) In section 1.2, the document name/reference should be separated from the document description by a colon and space 2) In that same section there's a stray period at the very bottom of page 4 3) Section 2, first paragraph: "This section a presents energy management scenarios [ ... ]". That 'a' (third word) needs to be removed. 4) For some reason the section header for section 2.8 does not appear bolded, while those for other subsections do. Melinda