From nobody Mon Jun 2 04:55:28 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1161A030F for ; Mon, 2 Jun 2014 04:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.152 X-Spam-Level: X-Spam-Status: No, score=-1.152 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.651, 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 OohcoLocphsR for ; Mon, 2 Jun 2014 04:55:23 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 49D521A01C7 for ; Mon, 2 Jun 2014 04:55:23 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 0B7A428B0046 for ; Mon, 2 Jun 2014 07:55:18 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 7A8411F8032; Mon, 2 Jun 2014 07:55:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Mon, 2 Jun 2014 07:55:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <90768A77-7B4A-475F-8F12-D1E967386F4E@tislabs.com> References: To: "sidr@ietf.org" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/aKHlBCE3wWJFTQWbwt9iqmX4sUU Cc: Sandra Murphy Subject: Re: [sidr] WGLC for draft-ietf-sidr-origin-validation-signaling-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 11:55:26 -0000 The wglc has ended. The response has not been strong enough to indicate = consensus for publication and there have been a few suggestions for = changes. This draft has been in the wg for a long time, but with = sporadic attention. The authors are encouraged to address the = suggestions for changes and discuss on the list. Thanks to Roque for pointing out the relationship to RFC4271. The idr = chairs have been asked if idr wants to review this document, as well. = We will report to the wg whether idr will be involved in the = consideration of this draft. --Sandy and Chris On Apr 25, 2014, at 7:53 PM, Sandra Murphy wrote: > The authors of BGP Prefix Origin Validation State Extended Community, = draft-ietf-sidr-origin-validation-signaling-04 have requested a WGLC. >=20 > This message begins a two week WGLC, to end on 9 May 2014. =20 >=20 > The draft is available at = http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling. >=20 > Please do send comments to the list, indicating whether you do or do = not believe that the draft is ready for publication. >=20 > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Jun 2 05:11:01 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9701A01DF for ; Mon, 2 Jun 2014 05:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 kwaKwkAEbe97 for ; Mon, 2 Jun 2014 05:10:57 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 93B9D1A01C7 for ; Mon, 2 Jun 2014 05:10:57 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 648CD28B0046 for ; Mon, 2 Jun 2014 08:10:52 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id CF5BA1F8032; Mon, 2 Jun 2014 08:10:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Mon, 2 Jun 2014 08:10:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "sidr@ietf.org" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/WGHahyiAQ9zuwu-zgda7NaK82ic Cc: Sandra Murphy Subject: Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 12:11:00 -0000 The adoption call has ended. The consensus is clearly, strongly, that the working group thinks this = is an important area that the working group needs to address. A significant fraction of the responses indicated that discussing the = problem should be the initial focus of the wg, before the solution the = draft proposes (if any) would be adopted. The authors are requested to submit a working group draft with the = problem discussion only, to serve as a focus for discussion. The chairs = suggest that the solution should be submitted as the topic of a second = draft, but not yet adopted as a working group draft until the problem = discussion has progressed. The responses to this adoption call was especially broad, from members = of the wg that are not ordinarily active. That is a good thing. The = chairs encourage all those who responded to stay involved in the = discussion going forward. --Sandy and Chris On Apr 25, 2014, at 12:05 PM, Sandra Murphy wrote: > The authors of draft-huston-rpki-validation-01.txt, RPKI Validation = Reconsidered, have requested wg adoption. >=20 > See http://tools.ietf.org/html/draft-huston-rpki-validation-01. >=20 > Please do respond to the list as to whether you support the wg = adopting this as a work item. You do not need to comment on the content = of this draft at this time. You are asked to indicate if you think that = this is work that the wg should be doing and whether this draft is an = acceptable starting point. Adding whether you can/will review or not is = useful. >=20 > Note that active support is required for adoption. Silence is a vote = against adoption. >=20 > This adoption call will end on 9 May 2014. >=20 > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Jun 2 11:51:11 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B64E1A0348; Mon, 2 Jun 2014 11:51:09 -0700 (PDT) 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 oVdupHbrafUC; Mon, 2 Jun 2014 11:51:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AF91A03ED; Mon, 2 Jun 2014 11:51:02 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140602185102.18066.29847.idtracker@ietfa.amsl.com> Date: Mon, 02 Jun 2014 11:51:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/-NALlaIZlD_vVEDIG2NNtHVpZiQ Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Protocol Action: 'Policy Qualifiers in RPKI Certificates' to Proposed Standard (draft-ietf-sidr-policy-qualifiers-01.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 18:51:09 -0000 The IESG has approved the following document: - 'Policy Qualifiers in RPKI Certificates' (draft-ietf-sidr-policy-qualifiers-01.txt) as Proposed Standard This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Alia Atlas and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sidr-policy-qualifiers/ Technical Summary This document updates RFC 6487 by clarifying the inclusion of policy qualifiers in the certificate policies extension of RPKI resource certificates. RFC 6487 does not specifically allow or disallow the PolicyQualifierInfo objects that are allowed by RFC5280. Working Group Summary Working group discussion was energetic but brief during adoption and almost immediate wglc. Consensus was clear. Document Quality This extension was verified to be consistent with three (all known) RPKI validator implementations. Neither MIB, Media Type, nor other expert review was applicable to this draft. Personnel The Document Shepherd is Sandra Murphy The Responsible Area Director is Alia Atlas From nobody Tue Jun 10 08:55:14 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF81B1A01DF; Tue, 10 Jun 2014 08:55:08 -0700 (PDT) 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 kvhtVa2LWt6n; Tue, 10 Jun 2014 08:55:07 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 66FBC1A01A6; Tue, 10 Jun 2014 08:55:07 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 0D67E28B0041; Tue, 10 Jun 2014 11:55:07 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 042361F8032; Tue, 10 Jun 2014 11:55:07 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <11159_1402415346_539728F2_11159_3728_16_53C29892C857584299CBF5D05346208A07161787@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Tue, 10 Jun 2014 11:55:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8DE674B8-45B5-4102-B974-B9312106E2A8@parsons.com> References: <002a01cf84b8$b0f55230$12dff690$@ndzh.com> <11159_1402415346_539728F2_11159_3728_16_53C29892C857584299CBF5D05346208A07161787@PEXCVZYM11.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/FZhg9M_fLfG_s14LLJ3-ddRX940 Cc: idr wg , Sandra Murphy , "sidr@ietf.org list" Subject: Re: [sidr] [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 15:55:09 -0000 It would be useful to include sidr on this discussion. I've added the = wg to the cc list. --Sandy On Jun 10, 2014, at 11:49 AM, wrote: > 5) The text in =AB deployment consideration =BB seems a bit weak. > I would say that: =93In deployment scenarios where not all the = speakers in an autonomous > system are upgraded to support the extensions defined in this = document, in order to avoid routing loops, it is REQUIRED to define = policies=94 =85 > =20 > 6) For the same purpose, IMO: > OLD: The default SHOULD be for the validation step to be disabled. > NEW: The default MUST be for the validation step to be disabled. > =20 > Thanks, > Regards, > Bruno > =20 > =20 > From: DECRAENE Bruno IMT/OLN=20 > Sent: Tuesday, June 10, 2014 5:40 PM > To: 'Susan Hares'; idr wg > Cc: Murphy, Sandra; 'John G. Scudder' > Subject: RE: [Idr] 1 WG call for Review = draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes > =20 > Hi, > =20 > Thanks for the cross WG review. Please find below some proposed = comments. > =20 > 1) For people not following SIDR, could you please elaborate on = why http://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 has not = been used? (via the registration of a new Point of Insertion specific to = origin validation) (as I though draft-ietf-idr-custom-decision was = intended to be the last time BGP decision process would be modified) > =20 > 2) Could the document specify the action to be taken when = multiple =93Origin validation state extended=94 community are present = with different validation state? And how are handled validation state = value > 2. (from current text, it would not be considered an error, just = lower priority. But I would prefer an explicit statement to avoid = surprising error handling behavior) > =20 > 3) Rfc 6811 is referenced twice in important sections. What about = moving it to =93normative reference=94? > =20 > 4) Following discussion triggered by = http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00 I = understood that the IDR conclusion was that a non-transitive community = may be attached on the outbound policy of an eBGP session; hence may = received over an eBGP session. Given this, IMO the security = consideration needs more text. (assuming that the ability for a = neighboring AS to influence/force the origin validation state is = considered acceptable, which would probably need to be discussed in = SIDR) > =20 > Thanks, > Regards, > Bruno > =20 > =20 > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Tuesday, June 10, 2014 4:32 PM > To: idr wg > Cc: Murphy, Sandra; 'John G. Scudder' > Subject: [Idr] 1 WG call for Review = draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes > =20 > IDR: > =20 > The SIDR WG has asked for cross review of the = draft-ietf-sidr-origin-validation-signaling-04. This draft changes the = RFC 4271 decision process in the following manner: > =20 > =20 > If a BGP router supports prefix origin validation and is configured = for the extensions defined in this document, the validation step SHOULD = be performed prior to any of the steps defined in the decision process = of [RFC4271]. The validation step is stated as follows: > =20 > When comparing a pair of routes for a BGP destination, the route > with the lowest "validation state" value is preferred. > =20 > In all other respects, the decision process remains unchanged. > =20 > The draft is at: > =20 > = http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-04 > =20 > John and I would like to hear your comments regarding the RFC 4271 = revision. Please send comments that include =93support=94 or =93no = support=94. > =20 > Sue and John > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Jun 10 14:49:52 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55C61A0305 for ; Tue, 10 Jun 2014 14:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 uW4xsnfC-zoF for ; Tue, 10 Jun 2014 14:49:47 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 599B21A018F for ; Tue, 10 Jun 2014 14:49:47 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 1485928B003D for ; Tue, 10 Jun 2014 17:49:47 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 0B48D1F8032; Tue, 10 Jun 2014 17:49:47 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_09CFA5BD-4723-44D5-BB0F-2AC68BF3479B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Tue, 10 Jun 2014 17:49:46 -0400 References: To: "sidr@ietf.org list" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/AxfDswFIZFV8GrNQ4JFYiaPdpvE Cc: Sandra Murphy Subject: [sidr] Fwd: Improving and Restructuring the Routing Area X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 21:49:49 -0000 --Apple-Mail=_09CFA5BD-4723-44D5-BB0F-2AC68BF3479B Content-Type: multipart/alternative; boundary="Apple-Mail=_D8495DE6-EFAB-4B68-96B7-B68CC206E7DD" --Apple-Mail=_D8495DE6-EFAB-4B68-96B7-B68CC206E7DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The routing ADs have started an effort to improve the quality and = productivity in the routing area. Please read the following. Note that the discussion will happen on the routing-discussion@ietf.org = mailing list. It is an open mailing list, so subscribe and participate. --Sandy Begin forwarded message: > From: Alia Atlas > Subject: Improving and Restructuring the Routing Area > Date: June 10, 2014 3:57:45 PM EDT > To: routing-discussion@ietf.org >=20 > To all participants in the Routing Area, >=20 > Adrian and I are working on improving the quality, speed, and > experience of getting work done in the IETF Routing Area. There are > three initiatives that we are working: WG Draft QA, Routing Area > specific WG chair training, and reorganizing the working groups in the > area. >=20 > First, we intend to use our Routing Directorate more proactively by > introducing a Working Group Draft Quality Assurance (WG Draft QA) > process where the same selected routing directorate member will review > a draft during WG draft adoption and during WG last call. The process > will be documented on the Routing Area wiki > (http://trac.tools.ietf.org/area/rtg/trac/wiki). This should allow > directorate reviews to report technical issues that can actually get > fixed early in the process (equivalent of bug reports) as opposed to > just noting the concerns in the drafts (equivalent of release notes). >=20 > Second, as was discussed during the recent IESG retreat, in addition > to the IETF-wide WG chair training, we intend to have a series of > training sessions for WG Chairs in the Routing Area addressing topics > such as judging consensus, project management, motivating volunteers, > using the datatracker (via a sandbox version that can be played > with safely), and sharing experiences between WG chairs. >=20 > Third, we intend to reorganize the working groups in the Routing area. > We feel that it is important to focus on areas where there is active > interest in standardization and to be open and able to accept new work > into the area. As you know, we have had several new working groups > (nvo3, i2rs, sfc, spring) created in the last few years and we need to > be open and able to handle more new work as it comes in. We would > also like to improve the signal-to-noise ratio experienced by > participants in the different working groups and improve the quantity > and quality of discussion and reviews. It is likely that not all WGs > in the Routing Area will be directly affected. >=20 > Here is the time-line for reorganizing the WGs. >=20 > NOW: public discussion on routing-discussion@ietf.org about how to > reorganize the working groups to best meet our motivations. > Additional focused discussions are expected on the > rtg-chairs@ietf.org and rtg-dir@ietf.org mailing lists. >=20 > In Toronto: There will be meetings with the WG chairs and the > Routing Directorate to get the ideas described and agreed upon. >=20 > At the Routing Area Meeting in Toronto: Discuss the set of > reorganized WGs and general charter content in the Routing Area > meeting. >=20 > September 2014: Based upon the feedback, suggestions, and > discussion, Adrian and I finalize the reorganized WG charters. We > start the internal IESG discussion and public reviews. >=20 > October 2014: Formal rechartering process completes. >=20 > In Honolulu: The new set of WGs meet. >=20 > After Honolulu: Adrian and I deal with any issues and charter > updates based upon a few months of experience. >=20 > Here are the motivations that Adrian and I would like to be considered > when coming up with ideas for how the WGs should be reorganized. >=20 > 1) Move towards organizing working groups on functional > responsibilities rather than scoping them to specific protocols. >=20 > 2) Split giant working groups so relevant work is done in one place > and there is an improved signal-to-noise ratio for participants who > are only interested in a slice of the current working group's work. >=20 > 3) Create synergies for scattered functionality (example ideas: > OAM, FRR, traffic-engineering) >=20 > 4) Create a DISPATCH working group for clear new idea discussion; > rtgwg serves some of this purpose but doesn't have a clear process > and isn't drawing in the new ideas. >=20 > 5) Focus Routing Area time on design centers rather than on far > corner cases. >=20 > 6) Each working group should have clear, well defined, and = achievable goals. >=20 > Noting that the Routing Area has inherited some of its WG structure > from the sub-IP area, it is not a goal to force IP routing and MPLS > routing to remain separated. >=20 > The goal of this reorganization is not closing working groups. Adrian > and Alia are perfectly capable of closing working groups without going > through restructuring. >=20 > For those of you that have read this far, thank you. Getting this 80% > right is going to take some serious discussion and thought. We all > work in the Routing Area together with different perspectives. Please > think carefully and help us have a highly focused discussion. >=20 > Thanks, > Alia and Adrian >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion --Apple-Mail=_D8495DE6-EFAB-4B68-96B7-B68CC206E7DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = routing ADs have started an effort to improve the quality and = productivity in the routing area.  Please read the = following.




Begin forwarded message:

From: Alia Atlas <akatlas@gmail.com>
Subject: = Improving and Restructuring the Routing = Area
Date: June 10, 2014 3:57:45 PM EDT

To all participants in the = Routing Area,

Adrian and I are working on = improving the quality, speed, and
experience of getting work = done in the IETF Routing Area.  There are
three initiatives that we are working: WG Draft QA, Routing = Area
specific WG chair training, and reorganizing the working = groups in the
area.

First, we intend = to use our Routing Directorate more proactively by
introducing a Working Group Draft Quality Assurance (WG Draft = QA)
process where the same selected routing directorate member = will review
a draft during WG draft adoption and during WG = last call.  The process
will be documented on the Routing Area wiki
directorate reviews to report technical issues that can = actually get
fixed early in the process (equivalent of bug reports) as opposed = to
just noting the concerns in the drafts (equivalent of = release notes).

Second, as was discussed during = the recent IESG retreat, in addition
to the IETF-wide WG chair training, we intend to have a series = of
training sessions for WG Chairs in the Routing Area = addressing topics
such as judging consensus, project = management, motivating volunteers,
using the datatracker (via a sandbox version that can be = played
with safely), and sharing experiences between WG = chairs.

Third, we intend to reorganize the = working groups in the Routing area.
We feel that it is important to focus on areas where there is = active
interest in standardization and to be open and able to = accept new work
into the area.  As you know, we have had = several new working groups
(nvo3, i2rs, sfc, spring) created in the last few years and we need = to
be open and able to handle more new work as it comes in. =  We would
also like to improve the signal-to-noise ratio = experienced by
participants in the different working groups and improve the = quantity
and quality of discussion and reviews.  It is = likely that not all WGs
in the Routing Area will be directly = affected.

Here is the time-line for reorganizing the = WGs.

   NOW: public discussion on routing-discussion@ietf.org about how to
   Additional focused discussions are expected on = the

   In Toronto: There will be meetings with the WG = chairs and the
   Routing Directorate to get the = ideas described and agreed upon.

  =  At the Routing Area Meeting in Toronto: Discuss the set of
   reorganized WGs and general charter content in the = Routing Area
  =  meeting.

   September 2014: = Based upon the feedback, suggestions, and
  =  discussion, Adrian and I finalize the reorganized WG charters. =  We
   start the internal IESG discussion and public = reviews.

   October 2014: Formal = rechartering process completes.

   In = Honolulu: The new set of WGs meet.

   After Honolulu: Adrian and I deal with any = issues and charter
   updates based upon a few = months of experience.

Here are the motivations = that Adrian and I would like to be considered
when coming up with ideas for how the WGs should be = reorganized.

   1) Move towards = organizing working groups on functional
  =  responsibilities rather than scoping them to specific = protocols.

   2) Split giant working groups so = relevant work is done in one place
   and there is = an improved signal-to-noise ratio for participants who
  =  are only interested in a slice of the current working group's = work.

   3) Create synergies for scattered = functionality (example ideas:
   OAM, FRR, = traffic-engineering)

   4) Create a = DISPATCH working group for clear new idea discussion;
   rtgwg serves some of this purpose but doesn't have a = clear process
   and isn't drawing in the new = ideas.

   5) Focus Routing Area time = on design centers rather than on far
   corner cases.

   6) = Each working group should have clear, well defined, and achievable = goals.

Noting that the Routing Area has = inherited some of its WG structure
from the sub-IP area, it is not a goal to force IP routing and = MPLS
routing to remain separated.

The = goal of this reorganization is not closing working groups. =  Adrian
and Alia are perfectly capable of closing working = groups without going
through restructuring.

For those of you = that have read this far, thank you.  Getting this = 80%
right is going to take some serious discussion and = thought.  We all
work in the Routing Area together with = different perspectives.  Please
think carefully and help us have a highly focused = discussion.

Thanks,
Alia and = Adrian

_______________________________________________
routing-discussion = mailing list
routing-discussion@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussion

= --Apple-Mail=_D8495DE6-EFAB-4B68-96B7-B68CC206E7DD-- --Apple-Mail=_09CFA5BD-4723-44D5-BB0F-2AC68BF3479B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTl316AAoJEHplpQeet0IZ2QMP+gKU6wAOZ8F1FPgdtCGOb3EB JYFe34lRbhm3mEWRQOvToPasge7yinUTt4MrsorhW1pEfY+ttuYmf558HKgPw/H7 /K3PyHOoqX54dImSHI8ghKSMM4QoK93tXBS7HT0eZ8jMlnF2oMEBnakndzilVcDp ADyxODImZKZb3WwMcx6EByJUnlrFAOUOB5N3OTsLBocHhZKHzpTr3HNnIRIyg6ye XYETu98WRvS96KgwmkZk9BsXO0fsoWYRbKd6l8pWIY+QxT9s+YiJkEmgVdCZmyIU iPRRcrIEX+Y1TUz3OfcES0gUOV2cTiNYfqaLkxs+ldjlyFDdTtPlQ0AHyv+YA5DF Azy5TQ1t5pIXk3xLqaRN2VxUZ6kQ3A+zoCrQ3fN5O5NJ03vYTPZI5FubTaIIBB+p a1jOTL9ve/hlwpa+og5hAJxxNAhLAExvU+CLAk11UW3EUgDjKGfcV49gMoVL5auY 2WYyWzb2LKKCsrNr4z9P9ULWpUKrQbi+ENga5pAUxx8mnsOSDYvokQK4iLPnS6zf c4sza7CwJZuy0ZNnME2j+aZhqOwdaWKRy5wWiyoqNlFdRJJFviWvXp0zPos5QGOM oKRLZiTBG6qaf5zdMJ89S6Lk8Zl/wJEXOtCFkPpcVF8m+LunpTZ6ObGGCSI0Sj6H nBO5ijSHRGS2B24PJZw8 =4E6w -----END PGP SIGNATURE----- --Apple-Mail=_09CFA5BD-4723-44D5-BB0F-2AC68BF3479B-- From nobody Wed Jun 11 13:25:37 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D961A0279; Wed, 11 Jun 2014 13:25:34 -0700 (PDT) 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 xCjuyW0boiaa; Wed, 11 Jun 2014 13:25:33 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB201A0081; Wed, 11 Jun 2014 13:25:32 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id r2so4932617igi.0 for ; Wed, 11 Jun 2014 13:25:32 -0700 (PDT) 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=+LCnqSXW56Outvtlmf2l9lDkeBxm+EVOlqQKbIHKS7Q=; b=qp0hI5UupEJOSOB+txAyx/ggIRXBTrLvELnsUnicvW2nXFCDfLkrDehNThFMA9FrHF olX22OSZ+14MJWuJ8GnWlDXvrCNd6RR4BBbtDgfTtEyJfKxdMZ1U/j+6TiIo3oN+XH7o 59Lxp4sDuzDz7qw3N+XOK+VrUd5/TLVTRU+MtsoRofbAouye6dj4a3UI9anQ7Sqv8ItH ttfyqxgHt64pUttsCGMNx2IFVU7CS84/T0p9O6kjtCcvwPZsuneno0uvvHdsOOClsSZI fWwPZFKAhJLT9qE45zKQjBdAeXtj/0UiuAciM7Yp35ixeM2lwVDvJyfUS0efM4ypRr+1 in1A== MIME-Version: 1.0 X-Received: by 10.50.62.40 with SMTP id v8mr232505igr.21.1402518332203; Wed, 11 Jun 2014 13:25:32 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Wed, 11 Jun 2014 13:25:31 -0700 (PDT) In-Reply-To: <8DE674B8-45B5-4102-B974-B9312106E2A8@parsons.com> References: <002a01cf84b8$b0f55230$12dff690$@ndzh.com> <11159_1402415346_539728F2_11159_3728_16_53C29892C857584299CBF5D05346208A07161787@PEXCVZYM11.corporate.adroot.infra.ftgroup> <8DE674B8-45B5-4102-B974-B9312106E2A8@parsons.com> Date: Wed, 11 Jun 2014 22:25:31 +0200 X-Google-Sender-Auth: 7JkRniBXSIPdimBrkb0VY15vWBo Message-ID: From: Robert Raszuk To: Sandra Murphy , Bruno Decraene Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/ZOhpG6TGZ2uIpAyv0QrfMXijQMI Cc: idr wg , "sidr@ietf.org list" Subject: Re: [sidr] [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 20:25:34 -0000 Hi Bruno & all, Just focusing on Q1: > 1) For people not following SIDR, could you please elaborate > on why http://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 > has not been used? (via the registration of a new Point of > Insertion specific to origin validation) (as I though draft-ietf-idr- > custom-decision was intended to be the last time BGP decision > process would be modified) Few observations: A. draft-ietf-sidr-origin-validation-signaling does not really modify a BGP best path selection .. it adds a check before BGP best path selection algorithm kicks in. B. Adding new POI is not needed as we already have a POI = 128 which is to be executed before any step in BGP best path selection hence at exactly the same point as this draft recommends. therefor one obvious question comes in: C. Based on A & B there is clear conflict not addresses in the draft. Assume both custom decision with POI = 128 "ABSOLUTE_VALUE" as well as origin validation are enabled. Moreover assume they result in opposite decisions. So the question of the day is: "Which of those two is the one to win the pre best path check ?" Effectively - which of those two is more important ? The answer to this question should be included in the draft. And I do suspect authors of both drafts will answer: mine ! Thx, R. From nobody Thu Jun 12 00:45:46 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AED1A02AF; Thu, 12 Jun 2014 00:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 zJV5QTmpcU62; Thu, 12 Jun 2014 00:45:41 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804CA1A02DF; Thu, 12 Jun 2014 00:45:41 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id B5CCC3B4572; Thu, 12 Jun 2014 09:45:39 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 984CA35C04E; Thu, 12 Jun 2014 09:45:39 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 12 Jun 2014 09:45:39 +0200 From: To: Robert Raszuk , Sandra Murphy Thread-Topic: [sidr] [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Thread-Index: AQHPhbNM1WOEZypNVEOpxmOi+68BQ5ttFKhw Date: Thu, 12 Jun 2014 07:45:38 +0000 Message-ID: <3364_1402559139_53995AA3_3364_2738_1_53C29892C857584299CBF5D05346208A07162318@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <002a01cf84b8$b0f55230$12dff690$@ndzh.com> <11159_1402415346_539728F2_11159_3728_16_53C29892C857584299CBF5D05346208A07161787@PEXCVZYM11.corporate.adroot.infra.ftgroup> <8DE674B8-45B5-4102-B974-B9312106E2A8@parsons.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.12.55119 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/1XrGsd_VyiqN-1cQlEA9ELmwjVQ Cc: idr wg , "sidr@ietf.org list" Subject: Re: [sidr] [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 07:45:44 -0000 SGkgUm9iZXJ0LCBhbGwNCg0KPiBGcm9tOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6 dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgUm9iZXJ0ICBSYXN6dWsgPiBTZW50OiBXZWRuZXNk YXksIEp1bmUgMTEsIDIwMTQgMTA6MjYgUE0NCj4gDQo+IEhpIEJydW5vICYgYWxsLA0KPiANCj4g SnVzdCBmb2N1c2luZyBvbiBRMToNCj4gDQo+ID4gMSkgIEZvciBwZW9wbGUgbm90IGZvbGxvd2lu ZyBTSURSLCBjb3VsZCB5b3UgcGxlYXNlIGVsYWJvcmF0ZSBvbiB3aHkNCj4gPiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1jdXN0b20tZGVjaXNpb24tMDQNCj4gPiBo YXMgbm90IGJlZW4gdXNlZD8gKHZpYSB0aGUgcmVnaXN0cmF0aW9uIG9mIGEgbmV3IFBvaW50IG9m IEluc2VydGlvbg0KPiA+IHNwZWNpZmljIHRvIG9yaWdpbiB2YWxpZGF0aW9uKSAoYXMgSSB0aG91 Z2ggZHJhZnQtaWV0Zi1pZHItDQo+ID4gY3VzdG9tLWRlY2lzaW9uIHdhcyBpbnRlbmRlZCB0byBi ZSB0aGUgbGFzdCB0aW1lIEJHUCBkZWNpc2lvbiBwcm9jZXNzDQo+ID4gd291bGQgYmUgbW9kaWZp ZWQpDQo+IA0KPiBGZXcgb2JzZXJ2YXRpb25zOg0KPiANCj4gQS4gZHJhZnQtaWV0Zi1zaWRyLW9y aWdpbi12YWxpZGF0aW9uLXNpZ25hbGluZyBkb2VzIG5vdCByZWFsbHkgbW9kaWZ5IGEgQkdQIGJl c3QNCj4gcGF0aCBzZWxlY3Rpb24gLi4gaXQgYWRkcyBhIGNoZWNrIGJlZm9yZSBCR1AgYmVzdCBw YXRoIHNlbGVjdGlvbiBhbGdvcml0aG0NCj4ga2lja3MgaW4uDQoNCg0KIjMuIENoYW5nZXMgdG8g dGhlIEJHUCBEZWNpc2lvbiBQcm9jZXNzIg0KWy4uLl0NCiJXaGVuIGNvbXBhcmluZyBhIHBhaXIg b2Ygcm91dGVzIGZvciBhIEJHUCBkZXN0aW5hdGlvbiwgdGhlIHJvdXRlIHdpdGggdGhlIGxvd2Vz dCAidmFsaWRhdGlvbiBzdGF0ZSIgdmFsdWUgaXMgcHJlZmVycmVkLiINCg0KTXkgcmVhZGluZyBp cyB0aGF0IGl0IGRvZXMgY2hhbmdlIHRoZSBCR1AgZGVjaXNpb24gcHJvY2VzcyBhbmQgdGhlIHJl bGF0aXZlIHByaW9yaXR5IG9mIHRoZSByb3V0ZXMuDQoNCj4gQi4gQWRkaW5nIG5ldyBQT0kgaXMg bm90IG5lZWRlZCBhcyB3ZSBhbHJlYWR5IGhhdmUgYSBQT0kgPSAxMjggd2hpY2ggaXMgdG8NCj4g YmUgZXhlY3V0ZWQgYmVmb3JlIGFueSBzdGVwIGluIEJHUCBiZXN0IHBhdGggc2VsZWN0aW9uIGhl bmNlIGF0IGV4YWN0bHkgdGhlDQo+IHNhbWUgcG9pbnQgYXMgdGhpcyBkcmFmdCByZWNvbW1lbmRz Lg0KDQpVc2luZyBQT0k9MTI4IGlzIGluZGVlZCBhbiBvcHRpb24uIEhvd2V2ZXIgaW4gdGhlb3J5 IHRoZXJlIGNvdWxkIGFscmVhZHkgYmUgZXhpc3RpbmcgdXNhZ2Ugb2YgUE9JPTEyOCwgaGVuY2Ug cG9zc2libGUgY29uZmxpY3QuIEluIHN1Y2ggY2FzZSwgdGhlIHN1Yi1maWVsZCAiQ29tbXVuaXR5 LUlEIiBkZWZpbmUgdGhlIHByaW9yaXR5LiBJdCdzIGEgcHJpb3JpIG5vdCBwb3NzaWJsZSB0byBk ZWZpbmUgd2hldGhlciBvcmlnaW4tdmFsaWRhdGlvbiBzaG91ZCBoYXZlIGEgbG93IG9yIGhpZ2gg dmFsdWUgY29tcGFyZWQgdG8gYW5vdGhlciBwb3NzaWJsZSBleGlzdGluZyB1c2FnZS4NCg0KIA0K PiB0aGVyZWZvciBvbmUgb2J2aW91cyBxdWVzdGlvbiBjb21lcyBpbjoNCj4gDQo+IEMuIEJhc2Vk IG9uIEEgJiBCIHRoZXJlIGlzIGNsZWFyIGNvbmZsaWN0IG5vdCBhZGRyZXNzZXMgaW4gdGhlIGRy YWZ0Lg0KPiBBc3N1bWUgYm90aCBjdXN0b20gZGVjaXNpb24gd2l0aCBQT0kgPSAxMjggIkFCU09M VVRFX1ZBTFVFIiBhcyB3ZWxsIGFzDQo+IG9yaWdpbiB2YWxpZGF0aW9uIGFyZSBlbmFibGVkLiBN b3Jlb3ZlciBhc3N1bWUgdGhleSByZXN1bHQgaW4gb3Bwb3NpdGUNCj4gZGVjaXNpb25zLiBTbyB0 aGUgcXVlc3Rpb24gb2YgdGhlIGRheSBpczogIldoaWNoIG9mIHRob3NlIHR3byBpcyB0aGUgb25l IHRvDQo+IHdpbiB0aGUgcHJlIGJlc3QgcGF0aCBjaGVjayA/IiBFZmZlY3RpdmVseSAtIHdoaWNo IG9mIHRob3NlIHR3byBpcyBtb3JlDQo+IGltcG9ydGFudCA/DQoNCllvdSBhcmUgcmVhZGluZyBt eSBtaW5kIDotKS4NCkkgYXNzdW1lZCB0aGF0IHRoZSBmaXJzdCBkb2N1bWVudCBiZWNvbWluZyBS RkMgZnJlZWx5IGRlZmluZSBpdHMgYmVoYXZpb3IgYW5kIHRoZW4gdGhlIHNlY29uZCB3aWxsIG5l ZWQgdG8gYWRhcHQgKGkuZS4gcG9zaXRpb24gaXRzZWxmIHdpdGggcmVnYXJkIHRvIHRoZSBmaXJz dCBvbmUpLiBIb3dldmVyLCBnaXZlbiB0aGF0IGJvdGggZG9jdW1lbnRzIGFyZSB3b3JrZWQgaW4g ZGlmZmVyZW50IFdHLCB0aGVyZSBpcyBhIHJpc2sgdGhhdCB0aGlzIGlzIG1pc3NlZC4NCiANCj4g VGhlIGFuc3dlciB0byB0aGlzIHF1ZXN0aW9uIHNob3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUgZHJh ZnQuIEFuZCBJIGRvIHN1c3BlY3QNCj4gYXV0aG9ycyBvZiBib3RoIGRyYWZ0cyB3aWxsIGFuc3dl cjogbWluZSAhDQoNCjotKQ0KSW5kZWVkIGl0J3MgdXAgdG8gdGhlIGF1dGhvcnMvV0csIGJ1dCB0 byBtZSAiQWJzb2x1dGUiIHNlZW1zIGFib3ZlIGFueSBvdGhlciBjcml0ZXJpYS4NCg0KVGhhbmtz LA0KQnJ1bm8NCg0KPiBUaHgsDQo+IFIuDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2Vz LCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVj dSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0 ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5n ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJl LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9u IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBi ZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJl ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Thu Jun 12 01:06:19 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7E41A0641; Thu, 12 Jun 2014 01:06:17 -0700 (PDT) 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 g45JNtVPTh0k; Thu, 12 Jun 2014 01:06:16 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BEA81A02B3; Thu, 12 Jun 2014 01:06:15 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h3so1737517igd.8 for ; Thu, 12 Jun 2014 01:06:15 -0700 (PDT) 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=Rm2zSQvEUQjLx+RDE2e8pEM1irmMiyDXTzryhc9Pfug=; b=gj5Vtq7PJIRXEa4qQCf+L5sZ1/+JmvyujvR8H7RegBYINWNdiilGC23MiWjnf4QdK8 NPitx/MytY6+73YBGdovLVL8Jiv5ksAFBItQVR4mKfdnLaA0Dd8Ko0aB3s38EUVuPK5j YYYRt7+OQYULrQ6o12VxuWxXzYjnqmfABPcYpWv242lZ5S9f5HmoTMWyFavpGW2GloTC o5iJqIcIa4BJYoyhEIHQ+WsiX9/gEo++2wX7sdjav+nn2MW0DuWB2nOXsPl5smCzTRfP htgLMsvmAnGJXWY1rPholLMDkPyn+sUkm2m+M031Q5jxElfKPMrDrgnV1yAZfOT4r5WH bAQQ== MIME-Version: 1.0 X-Received: by 10.43.87.200 with SMTP id ax8mr8190171icc.97.1402560375267; Thu, 12 Jun 2014 01:06:15 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Thu, 12 Jun 2014 01:06:14 -0700 (PDT) In-Reply-To: <3364_1402559139_53995AA3_3364_2738_1_53C29892C857584299CBF5D05346208A07162318@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <002a01cf84b8$b0f55230$12dff690$@ndzh.com> <11159_1402415346_539728F2_11159_3728_16_53C29892C857584299CBF5D05346208A07161787@PEXCVZYM11.corporate.adroot.infra.ftgroup> <8DE674B8-45B5-4102-B974-B9312106E2A8@parsons.com> <3364_1402559139_53995AA3_3364_2738_1_53C29892C857584299CBF5D05346208A07162318@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Thu, 12 Jun 2014 10:06:14 +0200 X-Google-Sender-Auth: TaRGTt9HcJdoOlVux6_r5Y5bNRw Message-ID: From: Robert Raszuk To: Bruno Decraene Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/BV1xAXkngfhcdGgvDbZXiLiu4wg Cc: idr wg , Sandra Murphy , "sidr@ietf.org list" Subject: Re: [sidr] [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 08:06:17 -0000 Hi Bruno, Glad we are in sync ;-) > It's a priori not possible to define whether origin-validation shoud have > a low or high value compared to another possible existing usage. Well I do not think it can be left as such. The entire point of adding the new extended community for propagation of origin validation result (valid, nf, invalid) is to accomplish consistency in IBGP. If you leave it open (ie not specified a priori) there is risk of different selections of best path in your domain for a given net (possibly with different exit points) . Frankly since this ext community is non transitive one could also depref the routes via local pref .. yes yes I can hear already voices .. don't touch it - my local pref is for customers ! Except what this draft defines will easily ignore all those customer local preferences anyway ... IMO it is all about wisely choosing local pref values. Cheers, R. > On Thu, Jun 12, 2014 at 9:45 AM, wrote: > > Hi Robert, all > >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk > Sent: Wednesday, June 11, 2014 10:26 PM >> >> Hi Bruno & all, >> >> Just focusing on Q1: >> >> > 1) For people not following SIDR, could you please elaborate on why >> > http://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 >> > has not been used? (via the registration of a new Point of Insertion >> > specific to origin validation) (as I though draft-ietf-idr- >> > custom-decision was intended to be the last time BGP decision process >> > would be modified) >> >> Few observations: >> >> A. draft-ietf-sidr-origin-validation-signaling does not really modify a = BGP best >> path selection .. it adds a check before BGP best path selection algorit= hm >> kicks in. > > > "3. Changes to the BGP Decision Process" > [...] > "When comparing a pair of routes for a BGP destination, the route with th= e lowest "validation state" value is preferred." > > My reading is that it does change the BGP decision process and the relati= ve priority of the routes. > >> B. Adding new POI is not needed as we already have a POI =3D 128 which i= s to >> be executed before any step in BGP best path selection hence at exactly = the >> same point as this draft recommends. > > Using POI=3D128 is indeed an option. However in theory there could alread= y be existing usage of POI=3D128, hence possible conflict. In such case, th= e sub-field "Community-ID" define the priority. It's a priori not possible = to define whether origin-validation shoud have a low or high value compared= to another possible existing usage. > > >> therefor one obvious question comes in: >> >> C. Based on A & B there is clear conflict not addresses in the draft. >> Assume both custom decision with POI =3D 128 "ABSOLUTE_VALUE" as well as >> origin validation are enabled. Moreover assume they result in opposite >> decisions. So the question of the day is: "Which of those two is the one= to >> win the pre best path check ?" Effectively - which of those two is more >> important ? > > You are reading my mind :-). > I assumed that the first document becoming RFC freely define its behavior= and then the second will need to adapt (i.e. position itself with regard t= o the first one). However, given that both documents are worked in differen= t WG, there is a risk that this is missed. > >> The answer to this question should be included in the draft. And I do su= spect >> authors of both drafts will answer: mine ! > > :-) > Indeed it's up to the authors/WG, but to me "Absolute" seems above any ot= her criteria. > > Thanks, > Bruno > >> Thx, >> R. > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Jun 12 09:58:49 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE50D1B27C6; Thu, 12 Jun 2014 09:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 ihW5eU170rle; Thu, 12 Jun 2014 09:58:45 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1131A0505; Thu, 12 Jun 2014 09:58:45 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id A60E428B003D; Thu, 12 Jun 2014 12:58:44 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 89EF11F8032; Thu, 12 Jun 2014 12:58:44 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_EF07511B-8CA4-4C61-8C3B-113058338A72"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Thu, 12 Jun 2014 12:58:43 -0400 Message-Id: References: To: "Keyur Patel (keyupate)" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/A4LgH5FdpMDqKfh5TY5vh1uajdc Cc: bruno.decraene@orange.com, "sidr@ietf.org list" , idr wg Subject: Re: [sidr] [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 16:58:47 -0000 --Apple-Mail=_EF07511B-8CA4-4C61-8C3B-113058338A72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Forwarded to sidr to keep them in this discussion. --Sandy On Jun 12, 2014, at 12:52 PM, "Keyur Patel (keyupate)" = wrote: > Hi Bruno, >=20 > Thanks for the draft review. Comments inlined #Keyur >=20 > From: > Date: Tue, 10 Jun 2014 15:40:05 +0000 > To: Susan Hares , idr wg > Cc: "'John G. Scudder'" , "Murphy, Sandra" = > Subject: Re: [Idr] 1 WG call for Review = draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes >=20 > Hi, > =20 > Thanks for the cross WG review. Please find below some proposed = comments. > =20 > 1) For people not following SIDR, could you please elaborate on = why http://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 has not = been used? (via the registration of a new Point of Insertion specific to = origin validation) (as I though draft-ietf-idr-custom-decision was = intended to be the last time BGP decision process would be modified) > =20 > #Keyur: The draft don't suggest modifications to the BGP best path = algorithm. Infact the next rev of the draft should fix and remove = section 3 as well. The extended community used in draft is use to = signal BGP best path validation state within an IBGP network. >=20 > 2) Could the document specify the action to be taken when = multiple =93Origin validation state extended=94 community are present = with different validation state? And how are handled validation state = value > 2. (from current text, it would not be considered an error, just = lower priority. But I would prefer an explicit statement to avoid = surprising error handling behavior) >=20 > #Keyur: There SHOULD not be multiple such extended communities for a = given BGP path. We can add the necessary text. > =20 > 3) Rfc 6811 is referenced twice in important sections. What about = moving it to =93normative reference=94? > =20 > #Keyur: Sure. >=20 > 4) Following discussion triggered by = http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00 I = understood that the IDR conclusion was that a non-transitive community = may be attached on the outbound policy of an eBGP session; hence may = received over an eBGP session. Given this, IMO the security = consideration needs more text. (assuming that the ability for a = neighboring AS to influence/force the origin validation state is = considered acceptable, which would probably need to be discussed in = SIDR) > #Keyur: Ideally, the usage of this community should NOT be encouraged = across inter-as boundaries. We can add necessary text to reflect that = part.=20 > =20 >=20 > Regards, > Keyur >=20 > Thanks, > Regards, > Bruno > =20 > =20 > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Tuesday, June 10, 2014 4:32 PM > To: idr wg > Cc: Murphy, Sandra; 'John G. Scudder' > Subject: [Idr] 1 WG call for Review = draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes > =20 > IDR: > =20 > The SIDR WG has asked for cross review of the = draft-ietf-sidr-origin-validation-signaling-04. This draft changes the = RFC 4271 decision process in the following manner: > =20 > =20 > If a BGP router supports prefix origin validation and is configured = for the extensions defined in this document, the validation step SHOULD = be performed prior to any of the steps defined in the decision process = of [RFC4271]. The validation step is stated as follows: > =20 > When comparing a pair of routes for a BGP destination, the route > with the lowest "validation state" value is preferred. > =20 > In all other respects, the decision process remains unchanged. > =20 > The draft is at: > =20 > = http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-04 > =20 > John and I would like to hear your comments regarding the RFC 4271 = revision. Please send comments that include =93support=94 or =93no = support=94. > =20 > Sue and John > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ Idr mailing list = Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_EF07511B-8CA4-4C61-8C3B-113058338A72 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTmdxEAAoJEHplpQeet0IZDVsQAI+ZEfTT9Kd5myhAUyMCCy0O f4avJ8K06dymviBIslFL3UJXulEdlSpW6R0ci4Rio71wSj87YEapADChq0P+aKxy mCPdYqXd1F8rGlnhDfhGVxHuZfObx5ZLDYzwq+wkQ/4OPfN0XVxjSL0Dp6cbDlrS 1Wg2HtCEAzaGCew3CFLzxgA7YQkifVfOPnNxI7kILI0HQ73aIlQ66z3YNJAYWQGR 9zvGeO4XLlBu0Sr1YYmNu6aY3Oy2TYVW2CAIDm3STs01OaiQ2WGVNj+yry5FU+0H T/NiVy8VEHCO94n36z2Kls6L/AB7BGxo1e52nMom2LsjGAQLtfdZCUkhcpqALU30 4/qbZryA9r3rw2JKctmcTSCdlrwEACygTGRs3DCprUu+EWn0RL8n2FRmMl7H1vvN iq4y8NdKSe+Uz3a5En1u9f4qZBOjS6tWXyrdBFlyaI4794Oq2z8SQMaZ5qQloM9W 5t3JfQvAoG+wrq3ey0u8NtEM2ZrosFxX4y/GhYVLSnG1iz5Q6zkpx5seCoURtnhW W4kDdhcPU0r7QHnnhTTsjS1x6Q8sZvwFgvosGMGR68Rr63rsRIvCUQ8GbRu6CRqU GiZ38KDb8RKxG1K1ZBim0MrrBZJquAvOqhq3jIN2yg3Hf5jzYx+ohXg+lMx5BxiS ZZ84t40tDCxDWLJxI+z/ =Ief7 -----END PGP SIGNATURE----- --Apple-Mail=_EF07511B-8CA4-4C61-8C3B-113058338A72-- From nobody Fri Jun 13 02:07:23 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3951A030E; Fri, 13 Jun 2014 02:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 S2Fd7JkWBBaZ; Fri, 13 Jun 2014 02:07:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E601A03DB; Fri, 13 Jun 2014 02:07:17 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 97B1FC0D66; Fri, 13 Jun 2014 11:07:13 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 5D202C8058; Fri, 13 Jun 2014 11:07:13 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 13 Jun 2014 11:07:12 +0200 From: To: Randy Bush , "Keyur Patel (keyupate)" Thread-Topic: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Thread-Index: AQHPhl6iB/uGL+YYM0KA0B8arly+15tuK7eAgACUJYA= Date: Fri, 13 Jun 2014 09:07:11 +0000 Message-ID: <17550_1402650433_539ABF41_17550_17892_1_53C29892C857584299CBF5D05346208A0716299F@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <29140_1402414807_539726D7_29140_10276_1_53C29892C857584299CBF5D05346208A0716175D@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.13.41819 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/WwpHvkIZOcrwUxaxsOdpFqyqzV8 Cc: idr wg , "sidr@ietf.org list" Subject: Re: [sidr] [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 09:07:22 -0000 > From: Randy Bush [mailto:randy@psg.com] > Sent: Friday, June 13, 2014 4:1= 3 AM >=20 > > #Keyur: Ideally, the usage of this community should NOT be encouraged > > #across inter-as boundaries. We can add necessary text to reflect > > #that part. >=20 > from rfc 7115, end of sec 5 >=20 > Validity state signaling SHOULD NOT be accepted from a neighbor AS. > The validity state of a received announcement has only local scope > due to issues such as scope of trust, RPKI synchrony, and management > of local trust anchors [LTA-USE]. Fine. If this is the choosen way, draft-ietf-sidr-origin-validation-signaling sho= uld also say that: - ASBR should remove such community from routes received over eBGP sessions= (possibly modulo confederation, 2 AS from the same organization/trusted...) - this community must not be used in the AS until all ASBR are upgraded to = support draft-ietf-sidr-origin-validation-signaling >=20 > randy ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Jun 13 02:18:32 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64281A03DB; Fri, 13 Jun 2014 02:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 AeVbpG2n_vS5; Fri, 13 Jun 2014 02:18:26 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6E231A030E; Fri, 13 Jun 2014 02:18:25 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id EA1A03B40EF; Fri, 13 Jun 2014 11:18:23 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id C273AC804B; Fri, 13 Jun 2014 11:18:23 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 13 Jun 2014 11:18:23 +0200 From: To: "Keyur Patel (keyupate)" , Susan Hares Thread-Topic: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Thread-Index: AQHPhl6iB/uGL+YYM0KA0B8arly+15tuwSEA Date: Fri, 13 Jun 2014 09:18:22 +0000 Message-ID: <17550_1402651103_539AC1DF_17550_18651_1_53C29892C857584299CBF5D05346208A071629B9@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <29140_1402414807_539726D7_29140_10276_1_53C29892C857584299CBF5D05346208A0716175D@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A071629B9PEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.13.41819 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/VqL1yfenAoxeFd7kEwiqOQX7J3o Cc: idr wg , "Murphy, Sandra" , "sidr@ietf.org list" Subject: Re: [sidr] [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 09:18:29 -0000 --_000_53C29892C857584299CBF5D05346208A071629B9PEXCVZYM11corpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Keyur, Many thanks for the answers. Comments inline #Bruno Adding sidr in copy From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Thursday, June 12, 2014 6:52 PM To: DECRAENE Bruno IMT/OLN; Susan Hares; idr wg Cc: 'John G. Scudder'; Murphy, Sandra Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-s= ignaling-04 - RFC4271 changes Hi Bruno, Thanks for the draft review. Comments inlined #Keyur From: > Date: Tue, 10 Jun 2014 15:40:05 +0000 To: Susan Hares >, idr wg > Cc: "'John G. Scudder'" >, "Murphy, Sandra" <= Sandra.Murphy@parsons.com> Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-s= ignaling-04 - RFC4271 changes Hi, Thanks for the cross WG review. Please find below some proposed comments. 1) For people not following SIDR, could you please elaborate on why ht= tp://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 has not been use= d? (via the registration of a new Point of Insertion specific to origin val= idation) (as I though draft-ietf-idr-custom-decision was intended to be the= last time BGP decision process would be modified) #Keyur: The draft don't suggest modifications to the BGP best path algorith= m. Infact the next rev of the draft should fix and remove section 3 as well= . The extended community used in draft is use to signal BGP best path vali= dation state within an IBGP network. #Bruno: current version (04) of the draft do change the BGP decision proce= ss. cf section 3. If you remove section 3 in the next revision, this is indeed a different st= ory. 2) Could the document specify the action to be taken when multiple "Or= igin validation state extended" community are present with different valida= tion state? And how are handled validation state value > 2. (from current t= ext, it would not be considered an error, just lower priority. But I would = prefer an explicit statement to avoid surprising error handling behavior) #Keyur: There SHOULD not be multiple such extended communities for a given = BGP path. We can add the necessary text. #Bruno: I agree on the goal. The question is how do you handle the case/err= or when there is more than one. I guess that this is less important if you remove section 3 and this commun= ity is purely informative with no impact on BGP decision process. 3) Rfc 6811 is referenced twice in important sections. What about movi= ng it to "normative reference"? #Keyur: Sure. 4) Following discussion triggered by http://tools.ietf.org/html/draft-= decraene-idr-rfc4360-clarification-00 I understood that the IDR conclusion = was that a non-transitive community may be attached on the outbound policy = of an eBGP session; hence may received over an eBGP session. Given this, IM= O the security consideration needs more text. (assuming that the ability fo= r a neighboring AS to influence/force the origin validation state is consid= ered acceptable, which would probably need to be discussed in SIDR) #Keyur: Ideally, the usage of this community should NOT be encouraged acro= ss inter-as boundaries. We can add necessary text to reflect that part. #Bruno: I agree on the goal. The question is how do you handle the case (er= ror/attack) where your untrusted neighbor sends you this community over an = eBGP session. Regards, Keyur Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, June 10, 2014 4:32 PM To: idr wg Cc: Murphy, Sandra; 'John G. Scudder' Subject: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signa= ling-04 - RFC4271 changes IDR: The SIDR WG has asked for cross review of the draft-ietf-sidr-origin-valida= tion-signaling-04. This draft changes the RFC 4271 decision process in the= following manner: If a BGP router supports prefix origin validation and is configured for the= extensions defined in this document, the validation step SHOULD be perform= ed prior to any of the steps defined in the decision process of [RFC4271]. The validation step is stated as follo= ws: When comparing a pair of routes for a BGP destination, the route with the lowest "validation state" value is preferred. In all other respects, the decision process remains unchanged. The draft is at: http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-04 John and I would like to hear your comments regarding the RFC 4271 revision= . Please send comments that include "support" or "no support". Sue and John ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.o= rg https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A071629B9PEXCVZYM11corpo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Keyur,

 

Many th= anks for the answers. Comments inline #Bruno

Adding = sidr in copy

&n= bsp;

From: Keyur Pa= tel (keyupate) [mailto:keyupate@cisco.com]
Sent: Thursday, June 12, 2014 6:52 PM
To: DECRAENE Bruno IMT/OLN; Susan Hares; idr wg
Cc: 'John G. Scudder'; Murphy, Sandra
Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-valid= ation-signaling-04 - RFC4271 changes

 

Hi Brun= o,

&n= bsp;

Thanks = for the draft review. Comments inlined #Keyur

&n= bsp;

From: <br= uno.decraene@orange.com>
Date: Tue, 10 Jun 2014 15:40:05 +0000
To: Susan Hares <shares@ndzh.c= om>, idr wg <idr@ietf.org>=
Cc: "'John G. Scudder'" <= jgs@bgp.nu>, "Murphy, Sandra" <Sandra.Murphy@parsons.com>
Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-valid= ation-signaling-04 - RFC4271 changes

&n= bsp;

Hi,

 <= /span>

Thanks = for the cross WG review. Please find below some proposed comments.

 <= /span>

1)&nb= sp;     For people not following SIDR, could you please elaborate on why ht= tp://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 has not been= used? (via the registration of a new Point of Insertion specific to origin= validation) (as I though draft-ietf-idr-custom-decision was intended to be the last time BGP decision process would be modified)

 <= /span>

#Keyur:= The draft don't suggest modifications to the BGP best path algorithm. Infa= ct the next rev of the draft should fix and remove section 3 as well.  = ;The extended community used in draft is use to signal BGP best path validation state within an IBGP network.<= /o:p>

#Bruno:= current version (04) of the  draft do change the BGP decision process= . cf section 3.

If you = remove section 3 in the next revision, this is indeed a different story.

 

2)&nb= sp;     Could the document specify the action to be taken when multiple “Ori= gin validation state extended” community are present with different v= alidation state? And how are handled validation state value > 2. (from current text, it would not be considered an erro= r, just lower priority. But I would prefer an explicit statement to avoid s= urprising error handling behavior)<= /o:p>

&n= bsp;

#Keyur:= There SHOULD not be multiple such extended communities for a given BGP pat= h. We can add the necessary text.

#Bruno:= I agree on the goal. The question is how do you handle the case/error when= there is more than one.

I guess= that this is less important if you remove section 3 and this community is = purely informative with no impact on BGP decision process.

=  <= /p>

3)&nb= sp;     Rfc 6811 is referenced twice in important sections. What about moving it t= o “normative reference”?

=  

#Keyur:= Sure.

&n= bsp;

4)&nb= sp;     Following discussion triggered by http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00 = I understood that the IDR conclusion was that a non-transitive community ma= y be attached on the outbound policy of an eBGP session; hence may received= over an eBGP session. Given this, IMO the security consideration needs more text. (assuming that the ability= for a neighboring AS to influence/force the origin validation state is con= sidered acceptable, which would probably need to be discussed in SIDR)

#Keyur:=  Ideally, the usage of this community should NOT be encouraged across= inter-as boundaries.  We can add necessary text to reflect that part.=  

#Bruno:= I agree on the goal. The question is how do you handle the case (error/att= ack) where your untrusted neighbor sends you this community over an eBGP se= ssion.

=  <= /p>

 

Regards= ,

Keyur

&n= bsp;

Thanks,=

Regards= ,

Bruno

 <= /span>

 <= /span>

From: Idr [mailto:idr-bou= nces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, June 10, 2014 4:32 PM
To: idr wg
Cc: Murphy, Sandra; 'John G. Scudder'
Subject: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validatio= n-signaling-04 - RFC4271 changes

 =

IDR:

 

The SIDR WG has asked for cross review of the dr= aft-ietf-sidr-origin-validation-signaling-04.  This draft changes the = RFC 4271 decision process in the following manner:

 

 
If a BGP router supports prefix origin validation and is configured=
 for the extensions defined in this document, the validation step SHOULD be=
 performed prior to any of the steps defined in the decision process of [RFC4271].  The validation step is stat=
ed as follows:
 
      When comparing a pair of routes for =
a BGP destination, the route<=
/span>
      with the lowest "validation sta=
te" value is preferred.<=
/span>
 
In all other respects, the decision process remains unchanged.

 

The draft is at:

 

http://tools.ietf.or= g/html/draft-ietf-sidr-origin-validation-signaling-04

 

John and I would like to hear y= our comments regarding the RFC 4271 revision.  Please send comments th= at include “support”  or “no support”.

 

Sue and John 

__________________________________________=
___________________________________________________________________________=
____
 
Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies san=
s autorisation. Si vous avez recu ce message par erreur, veuillez le signal=
er
a l'expediteur et le detruire ainsi que le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may conta=
in confidential or privileged information that may be protected by law;
they should not be distributed, used or co=
pied without authorisation.
If you have received this email in error, =
please notify the sender and delete this message and its attachments.<=
/o:p>
As emails may be altered, Orange is not li=
able for messages that have been modified, changed or falsified.=

Thank you.

_______= ________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A071629B9PEXCVZYM11corpo_-- From nobody Fri Jun 13 02:26:17 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D6F1A038C; Fri, 13 Jun 2014 02:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ZxLY-ddMa_sm; Fri, 13 Jun 2014 02:26:15 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A05FC1A030E; Fri, 13 Jun 2014 02:26:14 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3D9EE22C58B; Fri, 13 Jun 2014 11:26:13 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1CF5035C048; Fri, 13 Jun 2014 11:26:13 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 13 Jun 2014 11:26:12 +0200 From: To: Randy Bush , "Keyur Patel (keyupate)" Thread-Topic: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Thread-Index: AQHPhl6iB/uGL+YYM0KA0B8arly+15tuK7eAgACUJYCAAASGsA== Date: Fri, 13 Jun 2014 09:26:12 +0000 Message-ID: <7461_1402651573_539AC3B5_7461_10885_1_53C29892C857584299CBF5D05346208A071629D1@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <29140_1402414807_539726D7_29140_10276_1_53C29892C857584299CBF5D05346208A0716175D@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.13.61820 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/nKqY82m_Vud8nlenmeicT05TCDM Cc: idr wg , "sidr@ietf.org list" Subject: Re: [sidr] [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 09:26:16 -0000 Randy, > From: DECRAENE Bruno IMT/OLN > Sent: Friday, June 13, 2014 11:07 AM >=20 >=20 >=20 > > From: Randy Bush [mailto:randy@psg.com] > Sent: Friday, June 13, 2014 > > 4:13 AM > > > > > #Keyur: Ideally, the usage of this community should NOT be > > > encouraged #across inter-as boundaries. We can add necessary text > > > to reflect #that part. > > > > from rfc 7115, end of sec 5 > > > > Validity state signaling SHOULD NOT be accepted from a neighbor AS. > > The validity state of a received announcement has only local scope > > due to issues such as scope of trust, RPKI synchrony, and management > > of local trust anchors [LTA-USE]. >=20 > Fine. > If this is the choosen way, draft-ietf-sidr-origin-validation-signaling s= hould > also say that: > - ASBR should remove such community from routes received over eBGP > sessions (possibly modulo confederation, 2 AS from the same > organization/trusted...) > - this community must not be used in the AS until all ASBR are upgraded to > support draft-ietf-sidr-origin-validation-signaling Just to clarify, my goal was to clarify that "non-transitive" community are= accepted over eBGP and hence is not a guaranty that this information was o= riginated by the local AS hence assumed to be trusted. I don't feel this is self-obvious from the name, hence my comment for infor= mation. Regards, Bruno =20 >=20 > > > > randy ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Jun 13 08:25:14 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1C41A0350; Fri, 13 Jun 2014 08:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.416 X-Spam-Level: X-Spam-Status: No, score=-0.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.651, 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 4WUsBGTTQFYU; Fri, 13 Jun 2014 08:25:12 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 045411A0108; Fri, 13 Jun 2014 08:25:11 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.01,471,1400040000"; d="scan'208";a="353372938" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 13 Jun 2014 11:24:36 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Fri, 13 Jun 2014 11:25:11 -0400 From: "George, Wes" To: "bruno.decraene@orange.com" , Randy Bush , "Keyur Patel (keyupate)" Date: Fri, 13 Jun 2014 11:25:10 -0400 Thread-Topic: [sidr] [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Thread-Index: Ac+HG6pDtvEjjq37RwqeY6hgqzpWPg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/0U3N1uc_idGvkr9AkuZJFTDqwvY Cc: idr wg , "sidr@ietf.org list" Subject: Re: [sidr] [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 15:25:12 -0000 DQpPbiA2LzEzLzE0LCA1OjA3IEFNLCAiYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSINCjxicnVu by5kZWNyYWVuZUBvcmFuZ2UuY29tPiB3cm90ZToNCg0KPklmIHRoaXMgaXMgdGhlIGNob29zZW4g d2F5LCBkcmFmdC1pZXRmLXNpZHItb3JpZ2luLXZhbGlkYXRpb24tc2lnbmFsaW5nDQo+c2hvdWxk IGFsc28gc2F5IHRoYXQ6DQo+LSBBU0JSIHNob3VsZCByZW1vdmUgc3VjaCBjb21tdW5pdHkgZnJv bSByb3V0ZXMgcmVjZWl2ZWQgb3ZlciBlQkdQDQo+c2Vzc2lvbnMgKHBvc3NpYmx5IG1vZHVsbyBj b25mZWRlcmF0aW9uLCAyIEFTIGZyb20gdGhlIHNhbWUNCj5vcmdhbml6YXRpb24vdHJ1c3RlZC4u LikNCj4tIHRoaXMgY29tbXVuaXR5IG11c3Qgbm90IGJlIHVzZWQgaW4gdGhlIEFTIHVudGlsIGFs bCBBU0JSIGFyZSB1cGdyYWRlZA0KPnRvIHN1cHBvcnQgZHJhZnQtaWV0Zi1zaWRyLW9yaWdpbi12 YWxpZGF0aW9uLXNpZ25hbGluZw0KDQpKdXN0IHdhbnRlZCB0byBub3RlIHRoYXQgYXMgYW4gb3Bl cmF0b3Igb2YgYSBuZXR3b3JrIHdoZXJlIG15IEF1dG9ub21vdXMNClN5c3RlbSAoaS5lLiBUaGUg c3BhbiBvZiB0aGUgbmV0d29yayB1bmRlciBjb21tb24gY29udHJvbCkgc3BhbnMgbXVsdGlwbGUN CkF1dG9ub21vdXMgU3lzdGVtIE5VTUJFUlMsIHRoZXNlIGNhcnZlLW91dHMgdG8gaGFuZGxlIGNv bmZlZHMgYW5kIG11bHRpcGxlDQpBU05zIGZyb20gc2FtZSBvcmcgYXJlIHByZXR0eSBpbXBvcnRh bnQgaWYgSSBhbSB0byBpbXBsZW1lbnQgT3JpZ2luDQpWYWxpZGF0aW9uLiBCZWluZyBhYmxlIHRv IHZhbGlkYXRlIGF0IGV4dGVybmFsIEFTQlJzIGFuZCBrZWVwIHRoYXQgaW5mbw0KYWNyb3NzIHRo ZSBpbnRlcm5hbCBBU04gYm91bmRhcmllcyB3b3VsZCBtYWtlIGEgZGVwbG95bWVudCBpbiBuZXR3 b3Jrcw0KbGlrZSBtaW5lIG11Y2ggc2ltcGxlciB0aGFuIGlmIHdlIGhhdmUgdG8gcmV2YWxpZGF0 ZSBhdCB0aGUgaW50ZXJuYWwgQVNCUnMuDQoNClRoYW5rcw0KV2VzIEdlb3JnZQ0KDQoNClRoaXMg RS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVy IENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25m aWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5l ciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVy ZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWlu Zywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0 YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJl IHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUg dGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0 Lg0K From nobody Fri Jun 13 13:14:19 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B571B2A29 for ; Fri, 13 Jun 2014 13:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 3y6JXZiMG9MS for ; Fri, 13 Jun 2014 13:14:16 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4101B27E0 for ; Fri, 13 Jun 2014 13:14:16 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 35A2F28B0040 for ; Fri, 13 Jun 2014 16:14:14 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 2B4CF1F8032; Fri, 13 Jun 2014 16:14:14 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_ED98CF2E-1528-4E7B-B57C-556E13086A11"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <00542DC9-C187-49B9-A32D-ABF62AECE339@tislabs.com> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Fri, 13 Jun 2014 16:14:13 -0400 References: <20140613161232.7221.35693.idtracker@ietfa.amsl.com> To: "sidr@ietf.org list" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/TM1LAKRyrSVQ1rLUi9EQEP9hGVI Cc: Sandra Murphy Subject: [sidr] Fwd: third call: NomCom 2014-2015 Call for Volunteers X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 20:14:18 -0000 --Apple-Mail=_ED98CF2E-1528-4E7B-B57C-556E13086A11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The NomCom request for volunteers is below. Please do consider = volunteering for this important part of the IETF process. --Sandy Begin forwarded message: > From: NomCom Chair 2014 > Subject: third call: NomCom 2014-2015 Call for Volunteers > Date: June 13, 2014 12:12:32 PM EDT > To: IETF Announcement List > Reply-To: ietf@ietf.org, nomcom-chair-2014@ietf.org >=20 > This is the third call for volunteers. > VOLUNTEER NOW: we need to make 200. > The DEADLINE is June 26 to volunteer. >=20 > The IETF nomcom appoints folks to fill the open slots on the IAOC, the = IAB, > and the IESG (including IETF Chair). >=20 > If your name is on the below, then you have volunteered and are = qualified. > In addition to those who volunteered by email, it also includes those = who > indicated their willingness to serve on the IETF90 registration form, = and > whose eligibility has been confirmed. 54 people were confirmed to be > eligible, and 70 people were not confirmed based upon the email they = have > used to register. Those 124 people have been contacted directly. >=20 > If you have heard from me, but are not on the list, then there is some > problem, and you should have gotten a query from me to determine your > eligibility. >=20 > If you have volunteered and not heard from him, then please resend; > it got lost. >=20 > Ten voting members for the nomcom are selected in a verifiably random > way from a pool of volunteers. The more volunteers, the better chance = we have > of choosing a random yet representative cross section of the IETF = population. >=20 > Let's break the 200 volunteer mark again this year! > We are at 123 volunteers so far, and WE NEED TO HAVE 200!!! >=20 > The details of the operation of the nomcom can be found in RFC 3777, > and BCP10/RFC3797 details the selection algorithm. >=20 > Volunteers must have attended 3 of the past 5 IETF meetings. As = specified in > RFC 3777, that means three out of the five past meetings up to the = time this > email announcement goes out to start the solicitation of volunteers. > The five meetings out of which you must have attended *three* > are IETF 85(Atlanta), \ > 86(Orlando), \ > 87(Berlin), *** ANY THREE! > 88(Vancouver), / > 89(London) / >=20 > If you qualify, please volunteer. However, much as we want this, = before you > decide to volunteer, please be sure you are willing to forgo = appointment > to any of the positions for which this nomcom is responsible. >=20 > The list of people and posts whose terms end with the March 2015 IETF > meeting, and thus the positions for which this nomcom is responsible, = are >=20 > IAOC: > To be confirmed >=20 > IAB: > Joel Halpern > Russ Housley > Eliot Lear > Xing Li > Andrew Sullivan > Dave Thaler >=20 > IESG: > Pete Resnick (Applications) > Ted Lemon (Internet) > Joel Jaeggli (Operations and Management) > Richard Barnes (RAI) > Adrian Farrel* (Routing) > Stephen Farrell (Security) > Spencer Dawkins (Transport) > Jari Arkko (Gen) >=20 > (names with * have publically indicated they will not serve another = term) >=20 > The primary activity for this nomcom will begin in July 2014 and = should be > completed in January 2015. The nomcom will have regularly scheduled > conference calls to ensure progress. (We might dogfood WebRTC) > There will be activities to collect requirements from the community, = review > candidate questionnaires, review feedback from community members about > candidates, and talk to candidates. >=20 > Thus, being a nomcom member does require some time commitment; but it = is also > a very rewarding experience. >=20 > It is very important that you be able to attend IETF91 to conduct = interviews. > Being at IETF90 is useful for training. Being at IETF92 is not = essential. >=20 > Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 = hours) > June 22, 2013, as follows: >=20 > To: nomcom-chair-2014@ietf.org > Subject: Nomcom 2014-15 Volunteer >=20 > Please include the following information in the email body: >=20 > Your Full Name: __________-- > Current Primary Affiliation: > // Typically what goes in the Company field > // in the IETF Registration Form > Emails: _______________ > [] > > Telephone: _______________________ > // For confirmation if selected >=20 > You should expect an email response from me within 3 business days = stating > whether or not you are qualified. If you don't receive this response, > please re-send your email with the tag "RESEND"" added to the subject = line. >=20 > If you are not yet sure if you would like to volunteer, please = consider > that nomcom members play a very important role in shaping the = leadership > of the IETF. Questions by email or voice are welcome. > Volunteering for the nomcom is a great way to contribute to the IETF! >=20 > You can find a detailed timeline on the nomcom web site at: > https://datatracker.ietf.org/nomcom/2014/ >=20 > I will be publishing a more detailed target timetable, as well as = details > of the randomness seeds to be used for the RFC 3797 selection process, > within the next couple weeks. >=20 > Thank you! > Michael Richardson > mcr+nomcom@sandelman.ca > nomcom-chair-2014@ietf.org >=20 > =3D=3D=3D=3D=3D qualified volunteers so far, in alphabetical order by = first name > ANM Zaheduzzaman Sarker > Adam Montville > Ari Ker?nen > Benson Schliesser > Bhumip Khasnabish > Bill VerSteeg > Carl Williams > Carlos Martinez > Charles Eckel > Charles Perkins > Christer Holmberg > Craig White > DHRUV DHODY > Dacheng Zhang > Damien Saucez > Dapeng Liu > Dean Bogdanovic > Dimitri Papadimitriou > Donald Eastlake > Edward Crabbe > Emil Ivov > Eric Rescorla > Eric VYNCKE > Fangwei Hu > Fatai Zhang > Fernando Gont > Fred Baker > Giles Heron > Gonzalo Salgueiro > Gregory Mirsky > Hannes Gredler > Hongyu Li > Hosnieh Rafiee > Hugo Salgado > Hui Deng > Iuniana Oprescu > Jeff Tantsura > John Drake > John Jason Brzozowski > John Levine > John Scudder > Jon Hudson > Jon Mitchell > Karen O'Donoghue > Karen Seo > Kaveh Ranjbar > Klaas Wierenga > Larry Masinter > Lars Eggert > Lee Howard > Lei Zhu > Li Xue > Linda Dunbar > Lingli Deng > Louis (Lou) Berger > Luca Martini > Lucy Lynch > Lucy Yong > Luigi Iannone > Mach Chen > Marcelo Bagnulo > Mark Townsley > Matt Lepinski > Matthew Bocci > Mehmet Ersue > Melinda Shore > Michael Jones > Min Ye > Mingui Zhang > Ning Zong > Ole Troan > Pascal Thubert > Paul Hoffman > Peter Lothberg > Peter Yee > QIN WU > Ralph Droms > Ron Bonica > Ross Callon > Ross Finlayson > Russ White > Sam K. Aldrin > Samuel Weiler > Sandeep Kumar > Sanjay Mishra > Scott Mansfield > Sheng JIANG > Shucheng Liu > Simon Pietro Romano > Stan Ratliff > Stephan Friedl > Stephan Wenger > Stephen Kent > Stewart Bryant > Stig Venaas > Suhas Nandakumar > Suresh Krishnan > Susan Hares > Thomas Walsh > Tim Wicinski > Tissa Senevirathne > Toerless Eckert > Tony Hansen > Ulrich Herberg > Varun Singh > Wassim Haddad > Xiaohu XU > Yi Zhao > Yizhou Li > Yong Cui > Yuanlong Jiang > Yunfei Zhang > Zhaohui Zhang > Zhen Cao > iuniana oprescu --Apple-Mail=_ED98CF2E-1528-4E7B-B57C-556E13086A11 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTm1uVAAoJEHplpQeet0IZA7QP/iCI8ACow3sOr54lUOKnzV2b YRmeURGBrWh/uU7zm6h9iVbS9yETZVi+izXT00zD8eGOX7UgcXW8mISo6k/4FjAe 0QuJN0PtiA7XOuj1VG8mtwvmGqpvkwbd5L8gtsZoVRcoCdI5wtRe1BdvK3CtVW0i omS7IhHhHdCmrkmMY289G/oiyGaY+KLt4Co8TKKXDrcyvrKLbUKHs8Xmg3yCVAcn TLKVNIlKSV12Ft728w/QLj7MQsbmzh7CarOjVxR5u7GZzNZ5SRko1F9LHDPl2Un3 W32gXdkPw0mzTupGBK6XOjGFAgyeO7zojf8SQMyQ9CwRurUxp9Yr3iCA3BL5EvZ/ eLDoaWj98yXCTcce/hDa/JWVMyxQNvjw3N5/pRXhtS4RDMJ7axcs9qFZD15+Pg5S J6dIRJMQ+HDg9icJNuwfhLHKXRLZYeTNUtc6b386AhDFOF5TahTAVXXUFnmO1/qS KNOj6K6DSQAdJOPhUZk1tGvHbRvrR6laJoPYj+TC+stFMjQ2cg7s1sWdH0r22oOK q+JjruXCfxxwJu3a6i6xJie91eKXhN1pM5XFVn6e/gLbj6yVxqoK/2MXCSYcRVjA 18crK6w/bXetFXKNLEnBvaE1paDENzGpkyUaArhs71D6m6Z7+Hudx7WIKVvMgdue opjoPR8w94v/bsdwVDEN =Tu5O -----END PGP SIGNATURE----- --Apple-Mail=_ED98CF2E-1528-4E7B-B57C-556E13086A11-- From nobody Sat Jun 14 09:57:27 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B663A1A0522; Sat, 14 Jun 2014 09:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 nrCruisPeUja; Sat, 14 Jun 2014 09:57:12 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D081B2884; Sat, 14 Jun 2014 09:57:11 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 4B3BC2AC5E7; Sat, 14 Jun 2014 18:57:09 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 282CD15804E; Sat, 14 Jun 2014 18:57:09 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Sat, 14 Jun 2014 18:57:08 +0200 From: To: "Keyur Patel (keyupate)" Thread-Topic: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Thread-Index: AQHPh58/B/uGL+YYM0KA0B8arly+15tw0zlw Date: Sat, 14 Jun 2014 16:57:08 +0000 Message-ID: <30320_1402765029_539C7EE5_30320_2004_1_53C29892C857584299CBF5D05346208A07162EB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <11288_1402650149_539ABE25_11288_1186_5_53C29892C857584299CBF5D05346208A07162986@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.4.22118 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/KGLVQr2DaWVikv9-FKYD8KDt8-0 Cc: idr wg , "sidr@ietf.org list" Subject: Re: [sidr] [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 16:57:15 -0000 Hi Keyur, > From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] > Sent: Saturday= , June 14, 2014 9:07 AM >=20 > Hi Bruno, >=20 >=20 > On 6/13/14 2:02 AM, "bruno.decraene@orange.com" > wrote: >=20 > >> > Validity state signaling SHOULD NOT be accepted from a neighbor AS. > >> > >> I would agree > > > >I agree on the goal. > >Now the question is how do you protect from this, if you're unstrusted > >neighbor AS send this community over eBGP session. >=20 >=20 > I suggest we log an error and drop the community. Looks good. Could you please add this in the draft? Thanks. Bruno >=20 > Regards, > Keyur >=20 > > > >> + also add that setting this extended community by manual > >> EBGP policy should NOT be supported. > > > >IMO adding the text "The sender should not do that" is not a very > >strong protection. Otherwise, we would not need any crypto signature. > >(e.g. you should not originate a BGP route if you are not the true > originator). > >You can add the check on the receiver side, but this would now require > >that all ASBR be upgraded to support this new community, before it > >could be used. If this is the chosen path, it should be written in the > >draft in the deployment consideration section > > > >> The above along with the fact that this is already non-transitive in > >>the AS scope should solve that worry completely. > > > >Not yet. > > > >> r. > >> > >> On Fri, Jun 13, 2014 at 4:12 AM, Randy Bush wrote: > >> >> #Keyur: Ideally, the usage of this community should NOT be > >> >> encouraged #across inter-as boundaries. We can add necessary text > >> >> to reflect #that part. > >> > > >> > from rfc 7115, end of sec 5 > >> > > >> > Validity state signaling SHOULD NOT be accepted from a neighbor A= S. > >> > The validity state of a received announcement has only local scope > >> > due to issues such as scope of trust, RPKI synchrony, and > >>management > >> > of local trust anchors [LTA-USE]. > >> > > >> > randy > >> > > >> > _______________________________________________ > >> > Idr mailing list > >> > Idr@ietf.org > >> > https://www.ietf.org/mailman/listinfo/idr > >_________________________________________________________ > ______________ > >___ _______________________________________________ > > > >Ce message et ses pieces jointes peuvent contenir des informations > >confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > >exploites ou copies sans autorisation. Si vous avez recu ce message par > >erreur, veuillez le signaler a l'expediteur et le detruire ainsi que > >les pieces jointes. Les messages electroniques etant susceptibles > >d'alteration, Orange decline toute responsabilite si ce message a ete > >altere, deforme ou falsifie. Merci. > > > >This message and its attachments may contain confidential or privileged > >information that may be protected by law; they should not be > >distributed, used or copied without authorisation. > >If you have received this email in error, please notify the sender and > >delete this message and its attachments. > >As emails may be altered, Orange is not liable for messages that have > >been modified, changed or falsified. > >Thank you. > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Sat Jun 14 18:00:46 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A891B2A52; Sat, 14 Jun 2014 18:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 Ew878Y2rAtP0; Sat, 14 Jun 2014 18:00:35 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BBE31B2A4A; Sat, 14 Jun 2014 18:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4576; q=dns/txt; s=iport; t=1402794035; x=1404003635; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=cWVcOSV6yIT4ewHREEWYuIyNUB/R6jVGN2UUvwGZ0o8=; b=HyJd1zrUGGaoc8EdmvbvvPrLbhM0270BJGrQxCLKFTuMfF1tzKG+Q9pf i+HWVU+gSptJiNZfjii1bLOLxi3CL9vKeyaX08UP3ku1uC13yupTFMQ/Q RaHf9IkP9EWVCQ+kL2W9DnW13nQxBpnzC2uZ0jR6zDcOHxXgjLYsR+EZE M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FABXwnFOtJA2M/2dsb2JhbABagw1SWqlnAQEBAQEHkWeHPQGBAxZ1hAMBAQEEAQEBGh00CxIBCBUBAh4JLgsUEQIEDgUUiC4NzzATBIVjhXSCPREBDkIHhEMEmkOTWIF+gUKBcAcXBhw X-IronPort-AV: E=Sophos;i="5.01,479,1400025600"; d="scan'208";a="330068751" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP; 15 Jun 2014 01:00:17 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s5F10HAU022664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 15 Jun 2014 01:00:17 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.78]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Sat, 14 Jun 2014 20:00:17 -0500 From: "Keyur Patel (keyupate)" To: "bruno.decraene@orange.com" Thread-Topic: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Thread-Index: AQHPh58/B/uGL+YYM0KA0B8arly+15tw0zlwgABpi4A= Date: Sun, 15 Jun 2014 01:00:16 +0000 Message-ID: In-Reply-To: <30320_1402765029_539C7EE5_30320_2004_1_53C29892C857584299CBF5D05346208A07162EB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.89.142] Content-Type: text/plain; charset="us-ascii" Content-ID: <95BA9A48EF52184ABAD4F8028BB174BB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/G8t-MXQdLRW1DJN5GTen0YILaxU Cc: idr wg , "sidr@ietf.org list" Subject: Re: [sidr] [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 01:00:37 -0000 Hi Bruno, On 6/14/14 9:57 AM, "bruno.decraene@orange.com" wrote: >Hi Keyur, > >> From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] > Sent: >>Saturday, June 14, 2014 9:07 AM >>=20 >> Hi Bruno, >>=20 >>=20 >> On 6/13/14 2:02 AM, "bruno.decraene@orange.com" >> wrote: >>=20 >> >> > Validity state signaling SHOULD NOT be accepted from a neighbor AS. >> >> >> >> I would agree >> > >> >I agree on the goal. >> >Now the question is how do you protect from this, if you're unstrusted >> >neighbor AS send this community over eBGP session. >>=20 >>=20 >> I suggest we log an error and drop the community. > >Looks good. Could you please add this in the draft? Sure. Regards, Keyur > >Thanks. >Bruno > >>=20 >> Regards, >> Keyur >>=20 >> > >> >> + also add that setting this extended community by manual >> >> EBGP policy should NOT be supported. >> > >> >IMO adding the text "The sender should not do that" is not a very >> >strong protection. Otherwise, we would not need any crypto signature. >> >(e.g. you should not originate a BGP route if you are not the true >> originator). >> >You can add the check on the receiver side, but this would now require >> >that all ASBR be upgraded to support this new community, before it >> >could be used. If this is the chosen path, it should be written in the >> >draft in the deployment consideration section >> > >> >> The above along with the fact that this is already non-transitive in >> >>the AS scope should solve that worry completely. >> > >> >Not yet. >> > >> >> r. >> >> >> >> On Fri, Jun 13, 2014 at 4:12 AM, Randy Bush wrote: >> >> >> #Keyur: Ideally, the usage of this community should NOT be >> >> >> encouraged #across inter-as boundaries. We can add necessary text >> >> >> to reflect #that part. >> >> > >> >> > from rfc 7115, end of sec 5 >> >> > >> >> > Validity state signaling SHOULD NOT be accepted from a neighbor >>AS. >> >> > The validity state of a received announcement has only local >>scope >> >> > due to issues such as scope of trust, RPKI synchrony, and >> >>management >> >> > of local trust anchors [LTA-USE]. >> >> > >> >> > randy >> >> > >> >> > _______________________________________________ >> >> > Idr mailing list >> >> > Idr@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/idr >> >_________________________________________________________ >> ______________ >> >___ _______________________________________________ >> > >> >Ce message et ses pieces jointes peuvent contenir des informations >> >confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> >exploites ou copies sans autorisation. Si vous avez recu ce message par >> >erreur, veuillez le signaler a l'expediteur et le detruire ainsi que >> >les pieces jointes. Les messages electroniques etant susceptibles >> >d'alteration, Orange decline toute responsabilite si ce message a ete >> >altere, deforme ou falsifie. Merci. >> > >> >This message and its attachments may contain confidential or privileged >> >information that may be protected by law; they should not be >> >distributed, used or copied without authorisation. >> >If you have received this email in error, please notify the sender and >> >delete this message and its attachments. >> >As emails may be altered, Orange is not liable for messages that have >> >been modified, changed or falsified. >> >Thank you. >> > > > >__________________________________________________________________________ >_______________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >recu ce message par erreur, veuillez le signaler >a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >Orange decline toute responsabilite si ce message a ete altere, deforme >ou falsifie. Merci. > >This message and its attachments may contain confidential or privileged >information that may be protected by law; >they should not be distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete this message and its attachments. >As emails may be altered, Orange is not liable for messages that have >been modified, changed or falsified. >Thank you. > From nobody Thu Jun 19 14:01:59 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090461A031C for ; Thu, 19 Jun 2014 14:01:59 -0700 (PDT) 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 eqUlin08uhui for ; Thu, 19 Jun 2014 14:01:58 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002: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 963261A03E6 for ; Thu, 19 Jun 2014 14:01:57 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id b6so2166367yha.26 for ; Thu, 19 Jun 2014 14:01:57 -0700 (PDT) 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=hFNSv4CLRuhJW09ZYwpBy6kxCdgFCwqzdTaILCg2TS4=; b=BpRlutCBCN85FBq09yd39vY6gUwOln4BhcELfipXF82zfGaaoUAJWeRe6W+XjWLjFi EtwMulSbQ6DknBeupoQ5bh9jvvfojL06Ic9vWltvXLc9n6JubywiGyDc2+jyHmat1OUI zICxdWlJvli6FXAMD7CX4MzTXV7e3pEKOIlPVy9pvGUpISzYTift32b1sA2YYaSVdRdn G7Em+H1whP+uvErKlh+FNBfJN/mhXfoV86ZRFf8drw1ZhlhJAheEZGWw1lWQ3AudDnoG +cVooIfIKuGOgERx42s31cIkM4O340MeZOy6/23ppixxBIeNrbAtrLXQRg0MfgEQ+oEv mZeA== MIME-Version: 1.0 X-Received: by 10.236.103.135 with SMTP id f7mr11663152yhg.102.1403211716963; Thu, 19 Jun 2014 14:01:56 -0700 (PDT) Received: by 10.170.58.10 with HTTP; Thu, 19 Jun 2014 14:01:56 -0700 (PDT) Date: Thu, 19 Jun 2014 17:01:56 -0400 Message-ID: From: Alia Atlas To: sidr@ietf.org, "sidr-chairs@tools.ietf.org" , draft-ietf-sidr-cps@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11332a2eef362604fc36af6e Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/qE0n6EAgyeh3v6OQAImkz8TlaPw Subject: [sidr] AD Review of: draft-ietf-sidr-cps-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 21:01:59 -0000 --001a11332a2eef362604fc36af6e Content-Type: text/plain; charset=UTF-8 I do an AD review of drafts submitted for publication as part of my routine processing. I have done so on draft-ietf-sidr-cps-04 and do not have specific comments. I have requested a routing-directorate review, since I'm still coming up to speed on SIDR technology. The draft should shortly enter IETF Last Call and is scheduled for the IESG telechat on July 10. This is a very short window between the end of IETF Last Call and the telechat, so the authors will need to be very responsive to any comments if we want to get the draft approved before the July IETF. Thanks for the good work! Alia --001a11332a2eef362604fc36af6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I do an AD review of drafts submitted for publication as p= art of my routine processing.
I have done so on draft-ietf-sidr-cps-04 = and do not have specific comments. =C2=A0I have requested a
routi= ng-directorate review, since I'm still coming up to speed on SIDR techn= ology.

The draft should shortly enter IETF Last Call and is sc= heduled for the IESG telechat
on July 10. =C2=A0This is a very sh= ort window between the end of IETF Last Call and the telechat, so the autho= rs will need to be very responsive to any comments if we want to get the dr= aft approved before the July IETF.

Thanks for the good work!
Alia
--001a11332a2eef362604fc36af6e-- From nobody Thu Jun 19 14:03:02 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9D71A031C for ; Thu, 19 Jun 2014 14:03:00 -0700 (PDT) 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 EeciwF2mQ3QR for ; Thu, 19 Jun 2014 14:02:56 -0700 (PDT) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4D91A030C for ; Thu, 19 Jun 2014 14:02:56 -0700 (PDT) Received: by mail-yh0-f48.google.com with SMTP id b6so2173251yha.35 for ; Thu, 19 Jun 2014 14:02:55 -0700 (PDT) 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=SqnEWbctQ0yfUlVZ2S2JqE9UowHyr1QGjFEnrAP4E/s=; b=j8GdqKeb6oH/HZ0vC0pRy08xmlps1LqXfzCYvl7GwIjYByrj0tP6raQTrDP18Pki3l QB23lVI+IFmqERQzQ3PPu+fFrMfyUXFu9jTwMaAkmthdidHce36aNvGDFX7L1qqUaZfG owjlyRSA9D6Wdo45pZfnyOYAGFlM4dYr1/90oq3/bOSaXrEHjri1sQ1h0NhF31XhXWAC emQnMgt01OX4nM43mMDOlJWa5iQfZZPMSzoOp6fvzR6SomC1wIZ1WBEXgTbUa8ZCV0ac MSlFTivtjRc3vI/mrCI9kj4QY8YB1QYR0meXJiW22lyty66Fstd/HHhnQuRWD/h69IaG OpEw== MIME-Version: 1.0 X-Received: by 10.236.135.228 with SMTP id u64mr11708270yhi.18.1403211775753; Thu, 19 Jun 2014 14:02:55 -0700 (PDT) Received: by 10.170.58.10 with HTTP; Thu, 19 Jun 2014 14:02:55 -0700 (PDT) Date: Thu, 19 Jun 2014 17:02:55 -0400 Message-ID: From: Alia Atlas To: sidr@ietf.org, "sidr-chairs@tools.ietf.org" , draft-ietf-sidr-bgpsec-reqs@tools.ietf.org Content-Type: multipart/alternative; boundary=20cf301af3f570433704fc36b3d7 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/orfLnQY05Hz9TveHlMA1Nw1Ulu0 Subject: [sidr] AD review of draft-ietf-sidr-bgpsec-reqs-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 21:03:01 -0000 --20cf301af3f570433704fc36b3d7 Content-Type: text/plain; charset=UTF-8 I do an AD review of drafts submitted for publication as part of my routine processing. I have done so on draft-ietf-sidr-bgpsec-reqs-11 and do not have specific comments. I have requested a routing-directorate review, since I'm still coming up to speed on SIDR technology. The draft should shortly enter IETF Last Call and is scheduled for the IESG telechat on July 10. This is a very short window between the end of IETF Last Call and the telechat, so the authors will need to be very responsive to any comments if we want to get the draft approved before the July IETF. Thanks for the good work! Alia --20cf301af3f570433704fc36b3d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I do an AD review of drafts submitted for publication as p= art of my routine processing.
I have done so on=C2=A0draft-ietf-sidr-bg= psec-reqs-11=C2=A0and do not have specific comments. =C2=A0I have requested= a routing-directorate review, since I'm still coming up to speed on SI= DR technology.

The draft should shortly enter IETF Last Call and is sc= heduled for the IESG telechat
on July 10. =C2=A0This is a very sh= ort window between the end of IETF Last Call and the telechat, so the autho= rs will need to be very responsive to any comments if we want to get the dr= aft approved before the July IETF.

Thanks for the good work!
Alia
--20cf301af3f570433704fc36b3d7-- From nobody Thu Jun 19 14:38:27 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245721A0451; Thu, 19 Jun 2014 14:38:25 -0700 (PDT) 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 dteBPhXiTqAY; Thu, 19 Jun 2014 14:38:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D51A51A044F; Thu, 19 Jun 2014 14:38:22 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140619213822.1669.79423.idtracker@ietfa.amsl.com> Date: Thu, 19 Jun 2014 14:38:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/xvmA--thd82ZpTa1mJjzzlb8wDE Cc: sidr@ietf.org Subject: [sidr] Last Call: (Security Requirements for BGP Path Validation) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 21:38:25 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Security Requirements for BGP Path Validation' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-07-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin AS had the right to announce the prefix and to provide assurance of the AS Path of the announcement. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-reqs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-reqs/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jun 19 14:39:30 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12CAE1A04BA; Thu, 19 Jun 2014 14:39:28 -0700 (PDT) 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 VwJDDUJCmQog; Thu, 19 Jun 2014 14:39:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B07291A046A; Thu, 19 Jun 2014 14:39:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140619213921.1631.42210.idtracker@ietfa.amsl.com> Date: Thu, 19 Jun 2014 14:39:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/NKRz8USKi4sLv2rV_5DL-_B93Ug Cc: sidr@ietf.org Subject: [sidr] Last Call: (Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 21:39:28 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-07-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document contains a template to be used for creating a Certification Practice Statement (CPS) for an Organization that is part of the Resource Public Key Infrastructure (RPKI), e.g., a resource allocation registry or an ISP. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-cps/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-cps/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Jun 25 15:06:13 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC96B1B27D7 for ; Wed, 25 Jun 2014 15:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 YUoK_b6IhBLm for ; Wed, 25 Jun 2014 15:05:55 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 90EDE1B27B5 for ; Wed, 25 Jun 2014 15:05:55 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 4912E28B0040 for ; Wed, 25 Jun 2014 18:05:55 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 402C91F8032; Wed, 25 Jun 2014 18:05:55 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_3BA6A2A5-6609-4880-B6FA-E0FB8F16A537"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <0A00F163-8041-4192-999F-659995231E2F@tislabs.com> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Wed, 25 Jun 2014 18:05:54 -0400 References: <035e01cf8fe4$f36212c0$da263840$@olddog.co.uk> To: "sidr@ietf.org list" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/bxzyj-BcrIMU3TEco27Q0zywxow Cc: Sandra Murphy Subject: [sidr] Fwd: Heads up interesting IRTF talk X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 22:06:00 -0000 --Apple-Mail=_3BA6A2A5-6609-4880-B6FA-E0FB8F16A537 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The wg could be interested in the following talk.=20 The prize mentioned is the IETF Applied Networking Research Prize = https://irtf.org/anrp.=20 (sidr omitted from original recipient list in error.) --Sandy Begin forwarded message: > From: "Adrian Farrel" > Subject: Heads up interesting IRTF talk > Date: June 24, 2014 3:46:08 PM EDT > To: , > Cc: "Eggert, Lars" , routing-discussion@ietf.org > Reply-To: adrian@olddog.co.uk >=20 > There will be a talk describing a prize-winning piece of research in = the IRTF > Open Meeting in Toronto at 1420-1620 on Tuesday. >=20 >> *** Robert Lychev *** for studying the security benefits provided > by partially-deployed S*BGP: >>=20 >> Robert Lychev, Sharon Goldberg and Michael Schapira. BGP >> Security in Partial Deployment. Proc.ACM SIGCOMM, Hong Kong, >> China, August 2013. >=20 > Adrian >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion --Apple-Mail=_3BA6A2A5-6609-4880-B6FA-E0FB8F16A537 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTq0fCAAoJEHplpQeet0IZeTQQAJaeQKoxC3msnJCrBp6OJFLX gEO2hPKM9LldAOBsaH91XTkwBxkVs/W2PwvX0/NtkRVDp6PdQfxcvYvNpEtxJgZ1 fKrI7K/fvVTt0mXdFpgFc+9Ryc4LUGEitEE6zjy09TvxGoNJWqGucwpDphBt2fdf nghV/lgZh4UrlOZKjVSp3+LcYfsDgwnyzfzQpmIgJ4x9giac9AWpivV25rVaZEhh PNtyfro4tLslBnyNhfBqOvZXQ+wE5/ApBnOqshpsKSGzUdUeN4NXnXDgWLo2tssG Y9sv6CKOROWWS6mN3pxPfUM/ZUTvCApwhnKUT8rbZR+Y7YIptS8i0RZ2heAdTyTb yvNToNSdchOvYqp7Z1dks7v7/BZ/RCsdtpTjXOF2S5+cv7HJYEFRnkX4jNolSelt PlLZiPFxCTeTQjyrgppWGJIdf5ez5GsUj1bn0Hxv85JniaN9371Uf77px2V/9f3R GjMS/5nW4Ibtpyiiefri4P1Qc1MQ/k2ZQSWHtN4nM+mf5t0sKvybWFeEI0Aiq/Jb GhObcL/Fs+W9saMKx2+kkebJm5MBalWMovv5L1SEHyjKVNmmhnH+/HVRmDGwwZPn 7KjEddrmhyElLq45NUw9hEfZngMKHzcc3/E8pbTDuaVj/GYUxCpye3d8Qe1SbtgV iJV+j//lOIaZ7fOambL6 =FH6r -----END PGP SIGNATURE----- --Apple-Mail=_3BA6A2A5-6609-4880-B6FA-E0FB8F16A537-- From nobody Fri Jun 27 13:50:16 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FB91A0135 for ; Fri, 27 Jun 2014 13:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 cWXUdzDiZjuj for ; Fri, 27 Jun 2014 13:50:13 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id B3C511A0118 for ; Fri, 27 Jun 2014 13:50:13 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 4D78028B0017 for ; Fri, 27 Jun 2014 16:50:13 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 4380B1F8032; Fri, 27 Jun 2014 16:50:13 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_C2223E34-7F46-4572-88F9-41FBEA5F00B6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 27 Jun 2014 16:50:12 -0400 Message-Id: <75C51A68-FEC3-40B0-BC6C-A8A2471FF4CD@tislabs.com> To: "sidr@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/NHIHlJbXfL1Pv8lWK6yXwaRkCsM Cc: Sandra Murphy Subject: [sidr] about the thread "Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487" X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 20:50:15 -0000 --Apple-Mail=_C2223E34-7F46-4572-88F9-41FBEA5F00B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As we read the thread, there were two conclusions. RFC6487 6.1.1 (how to send a cert request in PKCS) says Subject This field MAY be omitted. If present, the value of this field SHOULD be empty (i.e., NULL), in which case the CA MUST generate a subject name that is unique in the context of certificates issued by this CA. a) "This field MAY be omitted." is wrong. PKCS#10 does not say that = the subject field is optional. So an implementation that did omit this = field might not work with a CA's implementation. b) "If present, the value of this field SHOULD be empty" means that the = rtr-keying draft was (at the time) non-compliant - rtr-keying said to = put the "router number" in the subject field of a PKCS#10 cert request. =20= The bgpsec-pki-profile draft says that the subject of a router cert has = the router ID in it. The subsequent revisions of the rtr-keying draft no longer put the = subject name in the PKCS#10 request, in response to b). =20 But that leaves us with no way to get the router ID communicated to the = CA to put into the router cert. 1 We could presume the CA just "knows". 2 We could invent some other way to communicate (and secure) the router = ID bundled with the PKCS#10 request. 3 We could remove the meaningful subject name in the router cert. 4 We could change the "the value of this field SHOULD be empty" text in = RFC6487 to add an exception for router certs. That would allow the = PKCS#10 subject name to be non-empty so it could carry the router ID in = the subject name.=20 (Steve Kent doubted the need for using PKCS#10 to request a cert in the = first place, so some other cert request mechanism is yet another option, = though more work.) Whichever we choose, some draft has to change or be written. So speak up! --Sandy, speaking for the wg co-chairs --Apple-Mail=_C2223E34-7F46-4572-88F9-41FBEA5F00B6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTrdkEAAoJEHplpQeet0IZHxUP/Ap2ngEGJrDSHexovXl0NmDy apqWwOgun7gyn88x3AtbC8thEO4dBpL6Q+Wm/HsC9Q1/TvHfJ6WyxuE1CxfuZQnL u+VlpzDXXcQX0uF6LMEWn9n4FHNk2UQr+Yso7VXRg6FSyFaouvVmgVKWnIn8JtK5 CGHqeElwNcaXP1mRx+3K1d165RHG9Y2ebYnzZ3aaWZ+hfogWKptE7YAz8iM6zXTO 0Kfddzkgw7nnS3xu7jIZDkiM5OiW+C9Fm+0AzS7QXodykVWkAYQDl2ye6NSr94Ue Kn4KCDtP2j6ajO17fakDkBklFqREuJharLo+WtAGmNSBr8bYpghJIemdAOEPs7Tb 0PMgrlcjBR+OA0W/bvddKrLBX4Yf9yMRqm94tJB8g5pSu4Xpz9s08i9bWf8zMCRy 2mGOM369kgP3C9oFUY3TnBIhhzGLhRjDCxgXJqna7I38WFeNPFVC195krH1TUOG7 hlbZ/LUp5JSdJaARzNxt6kTvohL3We87yl30dm3/Ev+zeDEcMsYS7gOKREecnq9N OK77svsSHDcbLst+pkbZtHDplVvPBmayIvoGZ3DXqgHhHetyRfxJnFGbyV+mNFyF bLNmLR/oTdpppgcb5H+kUSLdvAoUJKu3PTEBlJDZG7C7eAgDBkPL1UHpQuLd94AA y6fI4mfcSF8mdmrWEJu7 =cZGX -----END PGP SIGNATURE----- --Apple-Mail=_C2223E34-7F46-4572-88F9-41FBEA5F00B6-- From nobody Fri Jun 27 14:10:12 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583351A016E for ; Fri, 27 Jun 2014 14:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 WdLXUWevmcXf for ; Fri, 27 Jun 2014 14:10:05 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3771A016D for ; Fri, 27 Jun 2014 14:10:05 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 2A77028B0017 for ; Fri, 27 Jun 2014 17:10:05 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 1CA5F1F8032; Fri, 27 Jun 2014 17:10:05 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_B31D4598-4459-47C2-9EC4-ED1BAAA9879E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <75C51A68-FEC3-40B0-BC6C-A8A2471FF4CD@tislabs.com> Date: Fri, 27 Jun 2014 17:10:04 -0400 Message-Id: <1050B91E-6E5F-4120-9E46-CE2156F2FD39@tislabs.com> References: <75C51A68-FEC3-40B0-BC6C-A8A2471FF4CD@tislabs.com> To: "sidr@ietf.org list" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/nHHhQbZ3ywVPcoYwjkWNLhrsiQA Cc: Sandra Murphy Subject: Re: [sidr] about the thread "Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487" X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 21:10:08 -0000 --Apple-Mail=_B31D4598-4459-47C2-9EC4-ED1BAAA9879E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Speaking only as regular ol' member. On Jun 27, 2014, at 4:50 PM, Sandra Murphy wrote: >=20 > 1 We could presume the CA just "knows". > 2 We could invent some other way to communicate (and secure) the = router ID bundled with the PKCS#10 request. > 3 We could remove the meaningful subject name in the router cert. > 4 We could change the "the value of this field SHOULD be empty" text = in RFC6487 to add an exception for router certs. That would allow the = PKCS#10 subject name to be non-empty so it could carry the router ID in = the subject name.=20 >=20 >=20 I like 4. bgpsec-pki-profiles is already updating RFC6487 - we could just include = this in the update. And it could take care of the errata issue also. --Sandy, speaking as regular ol' member --Apple-Mail=_B31D4598-4459-47C2-9EC4-ED1BAAA9879E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTrd2sAAoJEHplpQeet0IZ/ZMP/i6ZTY7Nf4amOZYiARjczecG bZQ4MBd+22G91udOdjgTAnaAY4Oe/6KbaStn07YdxPPGrlvU51KewwX+IVU6f6bv wTFF6KRecS5pC/NRoTwZjvERnbYAnxDQ3KKdZuGHeLRykcEFNva9o35b/cU1JE+m mG0gvA37Btdz69NV4FzBXA0r60wd8d6RDslTedsvy14NjNBN/kMcBW3wmiwy8Icq AYP/48QF6OcB7IeRUXZZ16keEupOxshzAKI36yXX/73+URqYc6xNZnySOAWe1CsV UsHWcXX2BzOzhlbVEqCRW+NGlGpGo5cBIOQnmPkUovE6pPebiUb3QlvaOKsTcywZ njIgIs+I+odABMGnLJwBopk9KHvLvxn/rL0L9NvdPH7pdZONTaDoWFMT4Fi50LME CnxFA0nBrFTEoHXpZEVYRB3U3e4EGjrLWHLUDzyZxxUBVJa+4VdQMBEb80ds0gXm SRqnPn4YoXLzhCEA1q0qP6NixMbMEZoVhRQALQ/7TaAyvbTFDfEt8zqQuK7oY9Fd XHgGOG/M+Mh/b0wRe4dwXqGWTOO1z7HTVc9U0vRKtqxFmCB5N+AjLTqq5qpZUAxk u0eX5FZx60iz9KUv1YPCdRV0MlBxoNwlnONLipDsB8g/kG9uF9bl7ukWw5E87GJT 5fafqjwr9Bh8iFA6ljh0 =Ucuf -----END PGP SIGNATURE----- --Apple-Mail=_B31D4598-4459-47C2-9EC4-ED1BAAA9879E-- From nobody Sat Jun 28 07:54:49 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BF91A0353 for ; Sat, 28 Jun 2014 07:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 Q-dDlDexb4Pi for ; Sat, 28 Jun 2014 07:54:37 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0FB1A0356 for ; Sat, 28 Jun 2014 07:53:59 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1X0gtp-00071w-Np; Sat, 28 Jun 2014 00:53:50 +0000 Date: Sat, 28 Jun 2014 09:53:49 +0900 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: <75C51A68-FEC3-40B0-BC6C-A8A2471FF4CD@tislabs.com> References: <75C51A68-FEC3-40B0-BC6C-A8A2471FF4CD@tislabs.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Q40E1JXwgYxETINvcLHtpCEY2pk Cc: sidr wg list Subject: Re: [sidr] about the thread "Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487" X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 14:54:39 -0000 imagine i go to my router cloud, a small one, say 42 routers, and tell them to each gen a key, pkcs#10 it, and hand me the pkcs#10. i take the small bag of pkcs#10s and tell the ca to bulk sign please. the ca needs three router-specific bits of info a - AS (remember i could be running a confed or other aliasing hack) r - RouterID k - keying glorp signed by router [ you omitted the as number in your discussion, but ca needs a so it knows which AS signs. luckily bgpsec-pki-profiles does have it in the pkcs#10 subject ] note that all sort of folk will need the a and r in the resulting pkcs#7 in order to select which key to use. my scripts will need a and r to do give the pkcs#7 to the management station(s) or the routers. more significantly, each router's peers will need to know which router cert to grab from the rpki to validate the signature. > 1 We could presume the ca just "knows". i go to the ca and one by one, type a and r in for each request, and hand it the k. this scales really well, errors will never happen, and cash will fall from the sky > 2 We could invent some other way to communicate (and secure) the > router ID bundled with the PKCS#10 request. so a, r, and k go inside some sort of wrapper to code driving the ca. i suspect i would like the wrapper signed by g's corresponding private key. we could call this wrapped package pkcs#100 > 3 We could remove the meaningful subject name in the router cert. which still leaves me needing to communicate a and r to the ca. seems like your choice 1 to me. > 4 We could change the "the value of this field SHOULD be empty" text > in RFC6487 to add an exception for router certs. That would allow the > PKCS#10 subject name to be non-empty so it could carry the router ID > in the subject name. that's a, b, and k. the ca has all it needs. yummy. so, imiho, 1 and 3 are not viable. 2 and 4 are viable, but 4 requires less work and invention than 2. randy From nobody Sat Jun 28 15:48:12 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085A51A00FF; Sat, 28 Jun 2014 15:48:09 -0700 (PDT) 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 Vq_hXAnSQldf; Sat, 28 Jun 2014 15:48:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2521A0163; Sat, 28 Jun 2014 15:48:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140628224804.16663.1049.idtracker@ietfa.amsl.com> Date: Sat, 28 Jun 2014 15:48:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/p51IcjwohmgUz4hDrK2LahgpyF8 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-lta-use-cases-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 22:48:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : RPKI Local Trust Anchor Use Cases Author : Randy Bush Filename : draft-ietf-sidr-lta-use-cases-01.txt Pages : 5 Date : 2014-06-28 Abstract: There are a number of critical circumstances where a localized routing domain needs to augment or modify its view of the Global RPKI. This document attempts to outline a few of them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-lta-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-lta-use-cases-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-lta-use-cases-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 30 08:27:11 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF381A0378 for ; Mon, 30 Jun 2014 08:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 sCkPDpZzxZkN for ; Mon, 30 Jun 2014 08:27:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154201A035C for ; Mon, 30 Jun 2014 08:27:06 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58663 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X1dU1-000C10-6n for sidr@ietf.org; Mon, 30 Jun 2014 11:27:05 -0400 Message-ID: <53B181C7.4000701@bbn.com> Date: Mon, 30 Jun 2014 11:27:03 -0400 From: Stephen Kent 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: sidr@ietf.org References: <75C51A68-FEC3-40B0-BC6C-A8A2471FF4CD@tislabs.com> In-Reply-To: <75C51A68-FEC3-40B0-BC6C-A8A2471FF4CD@tislabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/B1pbfWyToWwPd9Yet1Gkw8YYdio Subject: Re: [sidr] about the thread "Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487" X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 15:27:09 -0000 Sandy, Thanks for continuing to pursue this issue. If we go with #4 below, I think your proposed revision makes sense. I've seen Randy's comments on the other 3 options, so #4 seems to be at the top of that list, now. I did suggest we might use other cert request mechanisms. EST is the obvious, current, standards-based option for this, if folks want to consider alternatives to PKCS#10. Since it was authored by a Cisco guy, there is some chance it might become available in their routers. I would suggest this path only for router certs, not for the RPKI certs. That might make it unpalatable, as a CA operated by an ISP would have to deal with two cert request formats: PKCS#1- for child CA certs (if the ISP is not a stub in the RPKI tree) and EST for router certs. I'm just pointing out options. Steve From nobody Mon Jun 30 13:35:10 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7CF1A0A97 for ; Mon, 30 Jun 2014 13:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 8GzAvLyit004 for ; Mon, 30 Jun 2014 13:35:07 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id B54411A07AB for ; Mon, 30 Jun 2014 13:35:05 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 3FA7C28B003D for ; Mon, 30 Jun 2014 16:35:05 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 393C61F8032; Mon, 30 Jun 2014 16:35:05 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_6B92C252-B079-4D34-9863-442F192136E4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 30 Jun 2014 16:35:04 -0400 Message-Id: To: "sidr@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/kbzu23Xl4n_dCgsEn_YFtkfH7Kc Cc: Sandra Murphy Subject: [sidr] agenda items for IETF90 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 20:35:09 -0000 --Apple-Mail=_6B92C252-B079-4D34-9863-442F192136E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Anyone who has a topic they would like to discuss at the upcoming IETF, = please send a message to the chairs and/or the list. --Sandy, speaking as wg co-chair. --Apple-Mail=_6B92C252-B079-4D34-9863-442F192136E4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTscn4AAoJEHplpQeet0IZXmUP/3qPfKKNwNDYO+rJPETdKVL8 i69Ir5j2LjMdc2i6brkxvRIWzzpXNQFeIqReranLVGlVEdDdMtETjtGahANQmWKM bT3sATdxfxF8Z2rRXolLrm53yyIwhLD1tLfiYxG9ka0PCABMvy/nJLNcNREeUFBv ngvBawvRee+jf3bSJeNH+nhNjL+0uiiN6rjQOA7aVa/D45CzdMXt5QiOyTWfxrGx J9omA/Us8XjXw1MZd1YaKZ6xRUpC9KEb9UsSD+tn29XYvRUOb/1bHihlwoPODznX hs6fFkPyu5GSVCoHrBZkN5v40CtdnfymwhBjQkflsUjJ2xjEG8N+SL7VuyCy+i7w Ong3gznzkpUCNc9DgWjvRToBYfvPaJbML+7jbeW9ZzCfK8GHS2vAPgUWcywGm94I RrmvUtcIAjuKRSatzqn8yWUBhZkuWXWI9YO4zFc9/tL1wxHXhwGel0kZznfO3Doj rb9hNAV4KbC2PFCCuZ18RRurYk3XBM0UMCNfmIed7oCmIo4243gKglW/pv2MljDr fnClVphgHOXJTT+tuOoVzMl0DOKGxFLUzzF1Eo07TwiH4G0CY4NNiT3sHVSvKMot WjiRZ7XbnQ7fJaon3PYFSaDHv81qzudWninD042gw6p44DuPjzPzRd1R3wUw0cWg 3/OpUtf90FfHGT9VFnrt =E+Ey -----END PGP SIGNATURE----- --Apple-Mail=_6B92C252-B079-4D34-9863-442F192136E4-- From nobody Mon Jun 30 13:39:57 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FEE1A0648 for ; Mon, 30 Jun 2014 13:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 H2f0wcp80eW8 for ; Mon, 30 Jun 2014 13:39:55 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 217B71A0300 for ; Mon, 30 Jun 2014 13:39:55 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id D10B028B003D for ; Mon, 30 Jun 2014 16:39:54 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id CAD3B1F8032; Mon, 30 Jun 2014 16:39:54 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_05122EEA-CF12-4DDE-8773-F18772CB36B5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 30 Jun 2014 16:39:53 -0400 Message-Id: <7DC16A13-2B3D-4B69-A22D-54ABF54E85AA@tislabs.com> To: "sidr@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/f0SSV1vSt8d5jBFhdzazv07RHa4 Cc: Sandra Murphy Subject: [sidr] upcoming dates for IETF90 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 20:39:56 -0000 --Apple-Mail=_05122EEA-CF12-4DDE-8773-F18772CB36B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The deadline for internet drafts is this coming Friday: =95 2014-07-04 (Friday): Internet Draft submission cut-off (for = all drafts, including -00) by UTC 23:59, upload using IETF ID Submission = Tool. Friday is a holiday in the US. UTC 23:59 is about 8pm US east coast = time, a prime time for some of the typical holiday activities. =20 If you have any plans that would need chair support, it would be good to = contact the chairs before Friday 4 July. The chairs are not aware of = anyone who is working on a initial version (-00) of a working group = draft (e.g., draft-ietf-sidr-fooandbar-00.txt). If you are, please = contact the chairs ASAP. =20 (Note that individual drafts, i.e., draft-mynamehere-etc-etc, need no = chair approval.) --Sandy --Apple-Mail=_05122EEA-CF12-4DDE-8773-F18772CB36B5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTscsZAAoJEHplpQeet0IZPqcP/2Jp+mPvLqH3+lZ8uNjSXyUa Rqx3lOWKdmo+9f08DxitSsaw9Da1RdiWEnhdMMfNKs0PwV1dDNq3jEwBElb/OBVj 6A58GygN7+nir81rCR6bNsYG9O6By/b2rOsrRbeoc1YEED3MabrjNei6hIYiytZD MCjI5OS681md0J2bdpRAzxZLrWka/QD3FLmee1oBRftYEnwQNUSSawJFs6PZmS+h LkdTGNs1giPm9wU+q0e6MADGk+4IL69D2baiOcISpvs2YwDMu4Rsgm3HI+B/dTpx tzWVTii0roALaM+XJ92qYNDnnaGsLf4YhWpBr3R+h6THB1UbcTHHUzmumZ0F1V3O YPRqlWgSbEoXXI3eoJMZvILNBK/OJot0fIH4kvdwhCX1jlwLBebrM80q6eKdkFab A3lGjctLbs36Bgts9K6+g5pNKffn5he2Q8itJ8g0pn0gAWH9I3U1occ33S3uEcVt oPfn0wHeBf5C2HsPZJrZweehHXm1roEugeOGf89kfw5wPIowEqTHkpuyx39jfh4+ /YisJlgErTSBwkoNkd3Ye1FvsAgCuIcPPyrOke2HW3n+B05AWzSpj8pXQPvRoG42 ZAxIiTykzDKv2kBpmSIwXCvkcKtYJPkLXPQcFt9Po7L4C25eJZbgtMFtfRKkB77/ y0k6vxmQ9deXi08ahWAk =xlk6 -----END PGP SIGNATURE----- --Apple-Mail=_05122EEA-CF12-4DDE-8773-F18772CB36B5-- From nobody Mon Jun 30 15:09:55 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946F31A0AFB for ; Mon, 30 Jun 2014 15:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 CcSPFV7HTpnb for ; Mon, 30 Jun 2014 15:09:53 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBE31A0AF4 for ; Mon, 30 Jun 2014 15:09:53 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id C483E28B0017; Mon, 30 Jun 2014 18:09:52 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id B6E3E1F8032; Mon, 30 Jun 2014 18:09:52 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_338AF89C-D2B1-4887-A8A2-2233E4159873"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Mon, 30 Jun 2014 18:09:52 -0400 Message-Id: References: <75C51A68-FEC3-40B0-BC6C-A8A2471FF4CD@tislabs.com> To: Randy Bush X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/mONnJ8Rx15COW4mzljKi4H-XUis Cc: sidr wg list , Sandra Murphy Subject: Re: [sidr] about the thread "Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487" X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 22:09:54 -0000 --Apple-Mail=_338AF89C-D2B1-4887-A8A2-2233E4159873 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 27, 2014, at 8:53 PM, Randy Bush wrote: >=20 > [ you omitted the as number in your discussion, but ca needs a so it > knows which AS signs. luckily bgpsec-pki-profiles does have it in = the > pkcs#10 subject ] That's a good point. Actually, bgpsec-pki-profiles does NOT have it in the PKCS#10 subject. bgpsec-pki-profiles gives a list of exceptions to the PKCS#10 defined in = RFC6487, but the exceptions do not include the AS number.=20 I had forgotten (if I ever noted) that the PKCS#10 profile in RFC6487 = does not include the number resources. So we need to come up with a way to get the AS number to the CA, also. >=20 >> 4 We could change the "the value of this field SHOULD be empty" text >> in RFC6487 to add an exception for router certs. That would allow = the >> PKCS#10 subject name to be non-empty so it could carry the router ID >> in the subject name. >=20 > that's a, b, and k. the ca has all it needs. yummy. We don't yet have the "a" part of this. Work to be done. >=20 > so, imiho, 1 and 3 are not viable. 2 and 4 are viable, but 4 requires > less work and invention than 2. >=20 Except for the point you made about the AS number. --Sandy, speaking as regular ol' member --Apple-Mail=_338AF89C-D2B1-4887-A8A2-2233E4159873 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTseAwAAoJEHplpQeet0IZhJYP/1tdgq6n6ch9Gi+I+4Nc+kmW s54s6fVch2O5ZEEselSCZS2iNU5hnoizgENhlP+Q3SIRjcrCBa1cL1FzfMfudWwk 08duT9TDL69eMRzemTqKVvZCCzpQB1gTXGh1yEWAxXsx8pm0tQ7GkJyb6ua8nQ6a JYCbfpqR0PXgRXdimW3tmimzpRahocbNAgdSCh6EbTwah1oD5pDHHaeqHL4EsYOG 6TDAcPb/hhSMMhBx4f3lzETxMDnROnxOcwAuZmvqMDkAsCs8DL5TkZUIAheD2gyI b02VXjH6hn+PLq7xlijyIOvoea0otUQcf+z4K0HmMy5MHl+FEgx17DSxxPGZimHI K8uRDPsVWpmMFbq0NrhERytDJ+YWZmX3gN4FDTu7LzZb2zAyWkB5uU8WodsER0RN SF3TGmKAVuJ3sRpL1z0qrTXjUMQ+esxyQi5Qcpt1w9JtWbwpxDQDyAUejnHfLSwr mfeYmcY7pcFksEXBeEwQBhOYZ8neLgR8sNI1lv++4c+nplrNNFz7WHbC9ocO/qS/ abQilEhChEwFPU0Zwzew5QQBQFQvKYUDk9Fu01o60IbFg4QhHJYmVTkvs/6Uu7qK apTfaBMBeK7EoHpnhErEtbAs9+/Q9oBQ2jGI8cI0iXgTdn7tYta3MbrnujhBMSQn DOpyvvkwDHNNhYn3xQtz =mfO/ -----END PGP SIGNATURE----- --Apple-Mail=_338AF89C-D2B1-4887-A8A2-2233E4159873--