From jmh@joelhalpern.com Thu Sep 6 10:06:41 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2E721F874F; Thu, 6 Sep 2012 10:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+e7IHgQpJBp; Thu, 6 Sep 2012 10:06:40 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id A0D5F21F86A8; Thu, 6 Sep 2012 10:06:40 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 03AD755892E; Thu, 6 Sep 2012 10:06:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 794281C9F38; Thu, 6 Sep 2012 10:06:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.1.20] (pool-108-2-221-176.phlapa.fios.verizon.net [108.2.221.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id BD3841C049B; Thu, 6 Sep 2012 10:06:38 -0700 (PDT) Message-ID: <5048D819.1080706@joelhalpern.com> Date: Thu, 06 Sep 2012 13:06:33 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "lisp@ietf.org" , "karp@ietf.org" References: <20120906002129.10667.70960.idtracker@ietfa.amsl.com> In-Reply-To: <20120906002129.10667.70960.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120906002129.10667.70960.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] Fwd: Help the NomCom: Nominations and Feedback X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 17:06:41 -0000 Please help the community. Thank you, Joel -------- Original Message -------- Subject: Help the NomCom: Nominations and Feedback Date: Wed, 05 Sep 2012 17:21:29 -0700 From: NomCom Chair To: Working Group Chairs The IETF Nominations Committee (NomCom) is currently seeking nominations for individuals to serve on the IESG, IAB, and IAOC. Additionally, this is an announcement that the NomCom is seeking feedback on individuals who have accepted nominations for IETF leadership positions. It is very important to the NomCom process that we get input from a broad spectrum of the community. Therefore, in case members of your working group do not read the IETF announcement and discussion lists, the NomCom would appreciate your help in disseminating the following information. The NomCom website contains information about this year's NomCom including the positions we are seeking to fill, and the qualifications required for these positions: https://www.ietf.org/group/nomcom/2012/ The NomCom is accepting nominations until September 24. Nominations for any position can be made using the following web tool: https://www.ietf.org/group/nomcom/2012/nominate Feedback about individuals who the NomCom is considering can be providing using the following web tool: https://www.ietf.org/group/nomcom/2012/input The feedback tool provides a list of individuals who have agreed to be considered for each position. We will be updating this list in the coming weeks as more individuals accept nominations. Feedback provided to the NomCom is kept strictly confidential! Note that use of the NomCom web tools require an ietf.org (i.e., datatracker) account. You can create an ietf.org account by visiting the following URL: https://datatracker.ietf.org/accounts/create/ As an alternative to using the web tools, you can send email to the NomCom at nomcom12@ietf.org to make a nomination or provide input to the committee. Thank you for your help, - Matt Lepinski nomcom-chair@ietf.org From jmh@joelhalpern.com Tue Sep 11 12:04:30 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62D321F8552 for ; Tue, 11 Sep 2012 12:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.017 X-Spam-Level: X-Spam-Status: No, score=-102.017 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2toHm76OEHd for ; Tue, 11 Sep 2012 12:04:30 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 28EEF21F8551 for ; Tue, 11 Sep 2012 12:04:30 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id B61D95583E1 for ; Tue, 11 Sep 2012 12:04:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 863E5240D0C; Tue, 11 Sep 2012 12:04:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-52-249.clppva.btas.verizon.net [71.161.52.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 5B6AC240D0B; Tue, 11 Sep 2012 12:04:27 -0700 (PDT) Message-ID: <504F8B33.9070704@joelhalpern.com> Date: Tue, 11 Sep 2012 15:04:19 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Stewart Bryant Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "karp@ietf.org" Subject: [karp] draft-ietf-karp-routing-tcp-analysis X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 19:04:31 -0000 (My apologies to the authors and the WG for the lateness of this writeup.) Document Writeup As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? As indicated in the header, this document is intended for informational status. It is an analysis of protocols, according to the KARP guidelines, and as such belongs as an informational document. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document analyzes BGP, LDP, PCEP and MSDP according to guidelines set forth in section 4.2 of Keying and Authentication for Routing Protocols Design Guidelines [RFC6518]. Working Group Summary The working group was happy with this document. Joe Touch expressed concerns about the descriptions of TCP-MD5 and TCP-AO. All the specific concerns he raised have been addressed, but his comments suggest that he may have additional unspecified concerns. Document Quality This document has been reviewed by the Working Group and by the chairs. It does a good job laying out both the common issues across the protocols it analyses, and the protocol specific issues. The level of detail is appropriate to the working group goals as laid out in the charter and the guidelines document. Personnel Joel Halpern is the document shepherd. Stewart Bryant is the responsible Area Director. Joel and Brian Weis are the responsible Working Group Chairs. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document Shepherd has read this document both before the WG last call, and after the resolution of comments. It is in good shape, and the shepherd believes it is ready for publication as an Informational RFC. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? While not extensively reviewed, there were sufficiently many distinct individuals who reviewed the document, issues were raised and resolved. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The document is clearly a security related document. While it has had review from indivduals who are quite knowledgable about security, I anticipate and welcome the Security Directorate review. The document does not contain formal language material needing special treatment. And operational security issues of routing protocols are dealt with by the working group in a separate document, so normal operations and management review should suffice for this. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are no special concerns with this document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. The shepherd has confirmed with each document author that all known IPR has been disclosed. The working group was also asked if anyone knew of undisclosed IPR, and no such indications were brought forward. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been filed that reference this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The working group has a tendency towards quiet. The shepherd, wearing his co-chair hat, believes that the support is reasonably broad, even though not vocal. The working group does understand the document, and there are no dissenters. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) There have been no threats of appeal nor any other indications of significant unhappiness. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. ID nits complains about references, which I consider an issue to be left for final editing. Otherwise, it does not report any problems. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. There are no relevant formal review criteria. The shepherd did keep in mind the relevant guidelines in RFC 6518 in reviewing this document, and it meets those guidelines. (13) Have all references within this document been identified as either normative or informative? The references section is split into Normative and Informative references, and the individual references are places appropriately. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? The only normative reference which is not an RFC is draft-ietf-karp-threats-reqs, which is in the process of being revised for the IESG. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. As this is an informative document, there are inherently no downward normative references. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Publication of this document will not affect the status of any existing RFCs. This is not a revision of, nor a supplement to, any existing RFC. Rather, it is a new work product being created by this working group. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document does not assign any code points, and therefore has no IANA actions, considerations, or impact. It has no IANA considerations section, rather than having a section stating this explicitly which would need to be removed during final editing. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None (see 17). (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None, as there is no formal language material to be verified by automated tools. Yours, Joel M. Halpern From gregory.ietf@gmail.com Mon Sep 24 13:04:24 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D0821F887F; Mon, 24 Sep 2012 13:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiQZ45oooZ3a; Mon, 24 Sep 2012 13:04:23 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 37EC421F87E5; Mon, 24 Sep 2012 13:04:23 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so6538438obb.31 for ; Mon, 24 Sep 2012 13:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D0uLOnB+l1oLcM759kfr+SY7LvsN4BKZjXfCY2TmR8M=; b=nc/8vBFOiXenXD/UoPCLFOwJK9CFIM/KHUwmeF2cx5RPNWT5W8nEqT59hJuGgGyxSL fAS2wSzBiJA/UEFBDikI1YcoGSaBLdW2BCGdVoqvdbhRGzTrs5VFSn7OI5lguk6lE3bO TmLP+RXB3gSEIp5VP3WdwsDOxS/88hsiZnU1Q8Sk7VVizmK1y3eIdijdoAFAEnAJbJWc /pSwH9BZuzWI/3YxFPx4pqUsjzNKGuHT5X9ufTirFjpL8aNzNLgZPGn8zO6j82flDjYk XwZ7kM0qw+rklJVh8HJVsELkESsG1WIGalDQE9i55o9z99T7I5jWlyUeo/Dg5Jk1E4cd 7Jsw== MIME-Version: 1.0 Received: by 10.182.38.71 with SMTP id e7mr10609546obk.67.1348517062709; Mon, 24 Sep 2012 13:04:22 -0700 (PDT) Received: by 10.76.130.83 with HTTP; Mon, 24 Sep 2012 13:04:22 -0700 (PDT) In-Reply-To: <20120719152210.17609.76012.idtracker@ietfa.amsl.com> References: <20120719152210.17609.76012.idtracker@ietfa.amsl.com> Date: Mon, 24 Sep 2012 13:04:22 -0700 Message-ID: From: Gregory Lebovitz To: Stephen Farrell Content-Type: multipart/alternative; boundary=f46d0447f27c7f146904ca78185a Cc: draft-ietf-karp-threats-reqs@tools.ietf.org, karp-chairs@tools.ietf.org, The IESG , karp@ietf.org Subject: Re: [karp] Stephen Farrell's No Objection on draft-ietf-karp-threats-reqs-05: (with COMMENT) X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 20:04:24 -0000 --f46d0447f27c7f146904ca78185a Content-Type: text/plain; charset=ISO-8859-1 Hey Stephen, We are trying to close out draft-ietf-karp-threats-reqs asap. Responses are inline below Please let us know what you think... On Thu, Jul 19, 2012 at 8:22 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-karp-threats-reqs-05: No Objection > -- SNIP -- > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - Are there any weird cases where a lack of address > aggregtaion (esp for IPv6) could create a privacy > issue that would mean that a confidentiality service > might be needed? (Just checking) > G> Possibly, but the KARP charter is very clear that confidentiality is out-of-scope at this time. > > - s/privacy/confidentiality/ please > G> Done in upcoming v06. > > - the language telling secdir reviewers what to do ought > be less presecriptive > G> OLD: G> Security Area reviewers of routing area documents - These people are tasked by the Security Area Directors to perform reviews on routing protocol specifications as they pass through working group last call or IESG review. They will pay particular attention to the use of cryptographic authentication and newly specified security mechanisms for the routing protocols. They should ensure that incremental security improvements are being made, in line with this roadmap. G> NEW: G> Security Area reviewers of routing area documents - These people are tasked by the Security Area Directors to perform reviews on routing protocol specifications as they pass through working group last call or IESG review. Their particular attention to the use of cryptographic authentication and newly specified security mechanisms for the routing protocols is appreciated. They also help to ensure that incremental security improvements are being made, in line with this roadmap. G> Does that help? If I'm still not addressing your concern, would you be so kind as to propose text? > - I agree with Sean's discuss > G> Being addressed in upcoming -06. G> Thanks for the review!! -- ---- IETF related email from Gregory M. Lebovitz --f46d0447f27c7f146904ca78185a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Stephen,
We are trying to close out draft-ietf-karp-threats-reqs as= ap. Responses are inline below Please let us know what you think...

=
On Thu, Jul 19, 2012 at 8:22 AM, Stephen Farrell= <stephen.farrell@cs.tcd.ie> wrote:
Stephen Farrell has entered the following ba= llot position for
draft-ietf-karp-threats-reqs-05: No Objection

-- SNIP --
=A0

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- Are there any weird cases where a lack of address
aggregtaion (esp for IPv6) could create a privacy
issue that would mean that a confidentiality service
might be needed? (Just checking)

G> = Possibly, but the KARP charter is very clear that confidentiality is out-of= -scope at this time.
=A0

- s/privacy/confidentiality/ please

G&g= t; Done in upcoming v06.
=A0

- the language telling secdir reviewers what to do ought
be less presecriptive


G&= gt; OLD:
G> Security Area reviewers of routing area docum= ents - These
=A0 =A0 =A0 =A0 =A0 =A0 people are tasked by the Sec= urity Area Directors to perform
=A0 =A0 =A0 =A0 =A0 =A0 reviews on routing protocol specifications as = they pass through
=A0 =A0 =A0 =A0 =A0 =A0 working group last call= or IESG review. They will pay particular
=A0 =A0 =A0 =A0 =A0 =A0= attention to the use of cryptographic authentication and newly
=A0 =A0 =A0 =A0 =A0 =A0 specified security mechanisms for the routing = protocols. They
=A0 =A0 =A0 =A0 =A0 =A0 should ensure that increm= ental security improvements are being
=A0 =A0 =A0 =A0 =A0 =A0 mad= e, in line with this roadmap.

G> NEW:
G> Security Area rev= iewers of routing area documents - These
=A0 =A0 =A0 =A0 =A0 =A0 = people are tasked by the Security Area Directors to perform
=A0 = =A0 =A0 =A0 =A0 =A0 reviews on routing protocol specifications as they pass= through
=A0 =A0 =A0 =A0 =A0 =A0 working group last call or IESG review. Their = particular
=A0 =A0 =A0 =A0 =A0 =A0 attention to the use of crypto= graphic authentication and newly
=A0 =A0 =A0 =A0 =A0 =A0 specifie= d security mechanisms for the routing protocols is appreciated. They
=A0 =A0 =A0 =A0 =A0 =A0 also help to ensure that incremental security = improvements are being
=A0 =A0 =A0 =A0 =A0 =A0 made, in line with= this roadmap.

=A0G>=A0Does that help? If= I'm still not addressing your concern, would you be so kind as to prop= ose text?


- I agree with Sean's discuss

G>= Being addressed in upcoming -06.

G> Thanks for= the review!!
--
----
IETF related email from
Gregory = M. Lebovitz

--f46d0447f27c7f146904ca78185a-- From bew@cisco.com Mon Sep 24 17:24:01 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952FE21F885B for ; Mon, 24 Sep 2012 17:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZNI84NUzT-E for ; Mon, 24 Sep 2012 17:24:00 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id DB1D121F885A for ; Mon, 24 Sep 2012 17:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1171; q=dns/txt; s=iport; t=1348532640; x=1349742240; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=SdK52cx7x1DW4yNOQUaNhxpF+gUYXI2K1ZfCIqg2IGA=; b=jn5E3vTRAnOAufQMQVdoZtdrUjENO3FPOyyxmMhGCRqd+JbqKDZxEtRk O7/Z6gv/BOFOdFK6Xub+009QiF4Ne/ViuDMNx8vJbE/wZxqSE27GJport CJt25P9fJ66MnYuJbLUnzMTiaRGr4Pm3y9hSL3ET7RIoIs379dmJs0nhI k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOr4YFCrRDoG/2dsb2JhbABCA75ngQiCIAEBAQMBAQEBDwEnNAsQC0YnMAYTCRmHXQUBC5huoC2LG4MdgkVgA4hWiV6DMY46gWmDB4FD X-IronPort-AV: E=Sophos;i="4.80,478,1344211200"; d="scan'208";a="56240556" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 25 Sep 2012 00:24:00 +0000 Received: from dhcp-128-107-151-50.cisco.com (dhcp-128-107-151-50.cisco.com [128.107.151.50]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8P0O0ui009451; Tue, 25 Sep 2012 00:24:00 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: <70DAA4B8-C39E-457C-93C0-31DBABF1373E@gmail.com> Date: Mon, 24 Sep 2012 17:24:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <70DAA4B8-C39E-457C-93C0-31DBABF1373E@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1278) Cc: karp@ietf.org Subject: Re: [karp] Issue with KARP meeting minutes X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 00:24:01 -0000 Hi Ran, On Aug 14, 2012, at 2:43 PM, RJ Atkinson wrote: > >=20 > At present, the meeting minutes are unclear in multiple > places about which person said what. =20 >=20 > As an example, the word "Steve" could refer to several different=20 > people in the room -- and even to several different people who > are mentioned in the KARP WG meeting minutes. That name is not > the only problematic one. Thanks for pointing this out. >=20 > Could the WG Chairs please edit the minutes to expand > people's names more fully in order to remove the=20 > confusion/ambiguity about who said what ? Done - speakers are referred to by their name the first time they come = to the microphone, and by their initials thereafter. Let us know if = there are any further problems. Thanks, Brian >=20 > Thanks, >=20 > Ran >=20 > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp --=20 Brian Weis Security Standards and Technology, SRG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From stephen.farrell@cs.tcd.ie Mon Sep 24 17:30:18 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7630B1F0CA5; Mon, 24 Sep 2012 17:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ao7d+H-wDwwz; Mon, 24 Sep 2012 17:30:17 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 86E0B1F041D; Mon, 24 Sep 2012 17:30:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id ECBB0171480; Tue, 25 Sep 2012 01:30:16 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1348533016; bh=8f0UWz1syCppsR HzWYnIzwdMBnlFd/7/gfAsq7IMEsM=; b=TG/WLlkplFItwkj21Q6qwmF1nq/Mqw mbNy7yDDB6y9/3L1D1QvoCy0alf4V2UFTqU8e/BVnc3thjq8eBRE9wo7EdSuFJnL z9e2jju/9+hC1z3+t2t9ZIoq9oEc0WlMnyb9dX43p68rsQs3gEjRzUQ/l4YMR020 2lK/siJk1rq7/82Rai6pF8l3HNvUZ/0jGwmQeWsPjaidjcw600AWgc1nBEkTLge2 a4Dk+pc5jFsg9z18l4bjsj9fEeydxdt+afUQdhADouiMkZbRPYMJ271/XcygFwp2 dXau63lBfVLAyYkF7to3dJkq+s/0UvxdUkt1gy+vNnUSNylqJtX8Wyzg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id P5tyrD5iPko4; Tue, 25 Sep 2012 01:30:16 +0100 (IST) Received: from [10.87.48.8] (unknown [86.46.22.78]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6BD4817147E; Tue, 25 Sep 2012 01:30:14 +0100 (IST) Message-ID: <5060FB16.6080100@cs.tcd.ie> Date: Tue, 25 Sep 2012 01:30:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Gregory Lebovitz References: <20120719152210.17609.76012.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-karp-threats-reqs@tools.ietf.org, karp-chairs@tools.ietf.org, The IESG , karp@ietf.org Subject: Re: [karp] Stephen Farrell's No Objection on draft-ietf-karp-threats-reqs-05: (with COMMENT) X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 00:30:18 -0000 On 09/24/2012 09:04 PM, Gregory Lebovitz wrote: > Hey Stephen, > We are trying to close out draft-ietf-karp-threats-reqs asap. Great. My comments were from July 19th, but I understand how asap and summer work;-) > Responses are > inline below Please let us know what you think... > > On Thu, Jul 19, 2012 at 8:22 AM, Stephen Farrell > wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-karp-threats-reqs-05: No Objection >> > > -- SNIP -- > > >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - Are there any weird cases where a lack of address >> aggregtaion (esp for IPv6) could create a privacy >> issue that would mean that a confidentiality service >> might be needed? (Just checking) >> > > G> Possibly, but the KARP charter is very clear that confidentiality is > out-of-scope at this time. It was a comment, and I don't recall the context now, but if e.g. the draft said "no privacy issues exist" then your "Possibly" above would seem to invalidate that claim. If no such claim is made, probably no change is needed. (I've not re-read -05 to check.) >> - s/privacy/confidentiality/ please >> > G> Done in upcoming v06. Great. >> - the language telling secdir reviewers what to do ought >> be less presecriptive >> > G> OLD: > G> Security Area reviewers of routing area documents - These > people are tasked by the Security Area Directors to perform > reviews on routing protocol specifications as they pass through > working group last call or IESG review. They will pay particular > attention to the use of cryptographic authentication and newly > specified security mechanisms for the routing protocols. They > should ensure that incremental security improvements are being > made, in line with this roadmap. > > G> NEW: > G> Security Area reviewers of routing area documents - These > people are tasked by the Security Area Directors to perform > reviews on routing protocol specifications as they pass through > working group last call or IESG review. Their particular > attention to the use of cryptographic authentication and newly > specified security mechanisms for the routing protocols is > appreciated. They > also help to ensure that incremental security improvements are > being > made, in line with this roadmap. > > G> Does that help? If I'm still not addressing your concern, would you be > so kind as to propose text? Works for me. Thanks, S. > > >> - I agree with Sean's discuss >> > > G> Being addressed in upcoming -06. > > G> Thanks for the review!! > From gregory.ietf@gmail.com Mon Sep 24 19:31:25 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1E121F88D8; Mon, 24 Sep 2012 19:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsDN7GCuipgT; Mon, 24 Sep 2012 19:31:25 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D877C21F8847; Mon, 24 Sep 2012 19:31:24 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so6851214obb.31 for ; Mon, 24 Sep 2012 19:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=apjjzwKV6s+z4uQeqA5NKODlyDaWFwpprZ6QRy4P3Uk=; b=ToGuuOulIp1f1f6lZL043DCW3cgUah3RZnRxbWm5Cr8+qkxXUCQaJVHyJ273fyE00V yhhA2cpyZNflHXA6gsJfgSMFfjWyngFTuAUWvuzfbIozkiFUJOQAZ+ISU7xk1eSYWkeI x3v74ROokujLGAHvUsjRuCyUGH8a1v8w0kQ+wFP+SjtRZQHtamXmBGBxTzP/LFh0NNqo xidrArO2G/Q9L3nkShK/hAxGFRsEH+fTXwNg1hMvy90JoJj+Mdym0uTkB335sOAyVQlI hcAvZeTmjczN2C7HMICWoKGnIm0SNM5eZJA8SgHrtELkC+9fgtlROHueg2/Bnrg3/Zzt Qlgg== MIME-Version: 1.0 Received: by 10.60.12.42 with SMTP id v10mr11100255oeb.131.1348540284539; Mon, 24 Sep 2012 19:31:24 -0700 (PDT) Received: by 10.76.130.83 with HTTP; Mon, 24 Sep 2012 19:31:24 -0700 (PDT) In-Reply-To: <5060FB16.6080100@cs.tcd.ie> References: <20120719152210.17609.76012.idtracker@ietfa.amsl.com> <5060FB16.6080100@cs.tcd.ie> Date: Mon, 24 Sep 2012 19:31:24 -0700 Message-ID: From: Gregory Lebovitz To: Stephen Farrell Content-Type: multipart/alternative; boundary=e89a8fb20524a0117204ca7d807e Cc: draft-ietf-karp-threats-reqs@tools.ietf.org, karp-chairs@tools.ietf.org, The IESG , karp@ietf.org Subject: Re: [karp] Stephen Farrell's No Objection on draft-ietf-karp-threats-reqs-05: (with COMMENT) X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 02:31:25 -0000 --e89a8fb20524a0117204ca7d807e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 24, 2012 at 5:30 PM, Stephen Farrell wrote: > > > On 09/24/2012 09:04 PM, Gregory Lebovitz wrote: > > Hey Stephen, > > We are trying to close out draft-ietf-karp-threats-reqs asap. > > Great. My comments were from July 19th, but I understand how > asap and summer work;-) > G> Point taken ;-) > > > Responses are > > inline below Please let us know what you think... > > > > On Thu, Jul 19, 2012 at 8:22 AM, Stephen Farrell > > wrote: > > > >> Stephen Farrell has entered the following ballot position for > >> draft-ietf-karp-threats-reqs-05: No Objection > >> > > > > -- SNIP -- > > > > > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> > >> - Are there any weird cases where a lack of address > >> aggregtaion (esp for IPv6) could create a privacy > >> issue that would mean that a confidentiality service > >> might be needed? (Just checking) > >> > > > > G> Possibly, but the KARP charter is very clear that confidentiality is > > out-of-scope at this time. > > It was a comment, and I don't recall the context now, but > if e.g. the draft said "no privacy issues exist" then your > "Possibly" above would seem to invalidate that claim. If > no such claim is made, probably no change is needed. (I've > not re-read -05 to check.) > G> No such comment in the draft. So we are closed on this one. > > >> - s/privacy/confidentiality/ please > >> > > G> Done in upcoming v06. > > Great. > > >> - the language telling secdir reviewers what to do ought > >> be less presecriptive > >> > > G> OLD: > > G> Security Area reviewers of routing area documents - These > > people are tasked by the Security Area Directors to perform > > reviews on routing protocol specifications as they pass > through > > working group last call or IESG review. They will pay > particular > > attention to the use of cryptographic authentication and > newly > > specified security mechanisms for the routing protocols. They > > should ensure that incremental security improvements are > being > > made, in line with this roadmap. > > > > G> NEW: > > G> Security Area reviewers of routing area documents - These > > people are tasked by the Security Area Directors to perform > > reviews on routing protocol specifications as they pass > through > > working group last call or IESG review. Their particular > > attention to the use of cryptographic authentication and > newly > > specified security mechanisms for the routing protocols is > > appreciated. They > > also help to ensure that incremental security improvements > are > > being > > made, in line with this roadmap. > > > > G> Does that help? If I'm still not addressing your concern, would you > be > > so kind as to propose text? > > Works for me. > G> Great. Thanks for the quick reply, G> Gregory > > Thanks, > S. > > > > > > >> - I agree with Sean's discuss > >> > > > > G> Being addressed in upcoming -06. > > > > G> Thanks for the review!! > > > -- ---- IETF related email from Gregory M. Lebovitz --e89a8fb20524a0117204ca7d807e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Sep 24, 2012 at 5:30 PM, Stephen Farrell <stephen.farrell@= cs.tcd.ie> wrote:


On 09/24/2012 09:04 PM, Gregory Lebovitz wrote:
> Hey Stephen,
> We are trying to close out draft-ietf-karp-threats-reqs asap.

Great. My comments were from July 19th, but I understand how
asap and summer work;-)

G> Point tak= en ;-)
=A0

> Responses are
> inline below Please let us know what you think...
>
> On Thu, Jul 19, 2012 at 8:22 AM, Stephen Farrell
> <stephen.farrell@cs.tc= d.ie>wrote:
>
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-karp-threats-reqs-05: No Objection
>>
>
> -- SNIP --
>
>
>>
>> ------------------------------------------------------------------= ----
>> COMMENT:
>> ------------------------------------------------------------------= ----
>>
>>
>> - Are there any weird cases where a lack of address
>> aggregtaion (esp for IPv6) could create a privacy
>> issue that would mean that a confidentiality service
>> might be needed? (Just checking)
>>
>
> G> Possibly, but the KARP charter is very clear that confidentialit= y is
> out-of-scope at this time.

It was a comment, and I don't recall the context now, but
if e.g. the draft said "no privacy issues exist" then your
"Possibly" above would seem to invalidate that claim. If
no such claim is made, probably no change is needed. (I've
not re-read -05 to check.)

G> No suc= h comment in the draft. So we are closed on this one.
=A0

>> - s/privacy/confidentiality/ please
>>
> G> Done in upcoming v06.

Great.

>> - the language telling secdir reviewers what to do ought
>> be less presecriptive
>>
> G> OLD:
> G> Security Area reviewers of routing area documents - These
> =A0 =A0 =A0 =A0 =A0 =A0 people are tasked by the Security Area Directo= rs to perform
> =A0 =A0 =A0 =A0 =A0 =A0 reviews on routing protocol specifications as = they pass through
> =A0 =A0 =A0 =A0 =A0 =A0 working group last call or IESG review. They w= ill pay particular
> =A0 =A0 =A0 =A0 =A0 =A0 attention to the use of cryptographic authenti= cation and newly
> =A0 =A0 =A0 =A0 =A0 =A0 specified security mechanisms for the routing = protocols. They
> =A0 =A0 =A0 =A0 =A0 =A0 should ensure that incremental security improv= ements are being
> =A0 =A0 =A0 =A0 =A0 =A0 made, in line with this roadmap.
>
> G> NEW:
> G> Security Area reviewers of routing area documents - These
> =A0 =A0 =A0 =A0 =A0 =A0 people are tasked by the Security Area Directo= rs to perform
> =A0 =A0 =A0 =A0 =A0 =A0 reviews on routing protocol specifications as = they pass through
> =A0 =A0 =A0 =A0 =A0 =A0 working group last call or IESG review. Their = particular
> =A0 =A0 =A0 =A0 =A0 =A0 attention to the use of cryptographic authenti= cation and newly
> =A0 =A0 =A0 =A0 =A0 =A0 specified security mechanisms for the routing = protocols is
> appreciated. They
> =A0 =A0 =A0 =A0 =A0 =A0 also help to ensure that incremental security = improvements are
> being
> =A0 =A0 =A0 =A0 =A0 =A0 made, in line with this roadmap.
>
> =A0G> Does that help? If I'm still not addressing your concern,= would you be
> so kind as to propose text?

Works for me.

G> Great. Thanks= for the quick reply,
G> Gregory
=A0

Thanks,
S.

>
>
>> - I agree with Sean's discuss
>>
>
> G> Being addressed in upcoming -06.
>
> G> Thanks for the review!!
>



--
= ----
IETF related email from
Gregory M. Lebovitz

--e89a8fb20524a0117204ca7d807e-- From internet-drafts@ietf.org Wed Sep 26 17:14:51 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3E821F861F; Wed, 26 Sep 2012 17:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxtC7P7TKrta; Wed, 26 Sep 2012 17:14:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5E621F8613; Wed, 26 Sep 2012 17:14:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120927001450.26814.82060.idtracker@ietfa.amsl.com> Date: Wed, 26 Sep 2012 17:14:50 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-threats-reqs-06.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 00:14:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Keying and Authentication for Routing Pro= tocols Working Group of the IETF. Title : Keying and Authentication for Routing Protocols (KARP) O= verview, Threats, and Requirements Author(s) : Gregory Lebovitz Manav Bhatia Filename : draft-ietf-karp-threats-reqs-06.txt Pages : 32 Date : 2012-09-26 Abstract: Different routing protocols employ different mechanisms for securing protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying and Authentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed and a set of requirements for KARP design teams to follow. RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" is a companion to this document; KARP design teams will use them together to review and overhaul routing protocols. These two documents reflect the input of both the IETF Security Area and IETF Routing Area in order to form a mutually agreeable work plan. This document has three main parts. The first part provides an overview of the KARP effort. The second part lists the threats from RFC 4593 (Generic Threats To Routing Protocols) that are in scope for attacks against routing protocol transport systems. This includes any mechanisms built into the routing protocols themselves, to authenticate packets. The third part enumerates the requirements that routing protocol specifications must meet when addressing those threats for RFC 6518's "Work Phase 1", the update to a routing protocol's existing transport security. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-karp-threats-reqs-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-karp-threats-reqs-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/