http://permalink.gmane.org/gmane.ietf.sidr hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.sidr/5843 <pre>That is indeed the key question. Errata (only) document obvious mistakes in the original text, and are rarely read by implementers since few know of there existence. By contrast an update will be flagged to them in the metadata. In this case my assessment was that the matter was technical and outside the scope of an errata a view I confirmed with others on the IESG. The update does not need to be a big document, but it will (if published) have WG and IETF consensus for the change it makes. - Stewart </pre> Stewart Bryant 2013-05-13T14:48:30 http://permalink.gmane.org/gmane.ietf.sidr/5842 <pre> On May 6, 2013, at 11:02 AM, Andrew Chi wrote: Andrew, Would an implementer need to know the difference when writing code based on the current standards track RFC, or would they need to read the erratum? -danny </pre> Danny McPherson 2013-05-12T02:33:59 http://permalink.gmane.org/gmane.ietf.sidr/5839 <pre>Is this really a technical change? The document has two places that state X, and one place (citing 5280) that states Y. This erratum replaces the Y statement with X. All implementers have already implemented X since it's the stricter form of Y. X = no other extensions are allowed Y = non-critical extensions MAY be ignored If this truly is a technical change, then we should have an update doc. But I'm just trying to minimize needless words. Andrew On 5/6/2013 8:30 AM, Stewart Bryant wrote: </pre> Andrew Chi 2013-05-06T15:02:59 http://permalink.gmane.org/gmane.ietf.sidr/5838 <pre> As far as I can see the thread died at this point. I have rejected the errata. I see two ways forward, either submit a new errata that describes the correction in a way that has consensus, or roll the change into the update required to address the issue raised in errata 3168. - Stewart </pre> Stewart Bryant 2013-05-06T13:16:15 http://permalink.gmane.org/gmane.ietf.sidr/5837 <pre> Whilst this change was supported by one author and one of the chairs, it is a technical change and thus outside the scope of change permitted in an errata. The correct approach is for a member of the WG to produce a short update draft and test that this has WG and IETF consensus. Please can the chairs drive this process. - Stewart -------- Original Message -------- Subject: [Errata Rejected] RFC6487 (3168) Date: Mon, 6 May 2013 05:24:39 -0700 From: RFC Errata System &lt;rfc-editor&lt; at &gt;rfc-editor.org&gt; To: &lt;dmandelb&lt; at &gt;bbn.com&gt;, &lt;gih&lt; at &gt;apnic.net&gt;, &lt;ggm&lt; at &gt;apnic.net&gt;, &lt;robertl&lt; at &gt;apnic.net&gt; CC: &lt;stbryant&lt; at &gt;cisco.com&gt;, &lt;iesg&lt; at &gt;ietf.org&gt;, &lt;rfc-editor&lt; at &gt;rfc-editor.org&gt; The following errata report has been rejected for RFC6487, "A Profile for X.509 PKIX Resource Certificates". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6487&amp;eid=3168 -------------------------------------- Status: Rejected Type: Technical Reported by: David Mandelberg &lt;dman</pre> Stewart Bryant 2013-05-06T12:30:32 http://permalink.gmane.org/gmane.ietf.sidr/5836 <pre>Multiple people voiced their support for adopting the document as the starting point for the discussion. Nobody voiced their opposition to adopting the document. WG participants have spoken, so the document is now adopted by the WG. Best Regards, Alexey, on behalf of SIDR WG chairs. </pre> Alexey Melnikov 2013-05-03T14:14:55 http://permalink.gmane.org/gmane.ietf.sidr/5835 <pre>We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit t</pre> hammondjohnson< at >hushmail.com 2013-04-27T18:01:12 http://permalink.gmane.org/gmane.ietf.sidr/5834 <pre>Multiple people voiced their support for adopting the document, a couple of people provided specific comments. Nobody voiced their opposition to adopting the document. WG participants have spoken, so the document is now adopted by the WG. Best Regards, Alexey, as a co-chair. </pre> Alexey Melnikov 2013-04-23T15:00:29 http://permalink.gmane.org/gmane.ietf.sidr/5833 <pre>This is just a keep alive version. Date changes only. spt On 4/17/13 9:31 PM, internet-drafts&lt; at &gt;ietf.org wrote: </pre> Sean Turner 2013-04-18T12:32:33 http://permalink.gmane.org/gmane.ietf.sidr/5832 <pre> 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 : A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests Author(s) : Mark Reynolds Sean Turner Steve Kent Filename : draft-ietf-sidr-bgpsec-pki-profiles-05.txt Pages : 11 Date : 2013-04-17 Abstract: This document defines a standard profile for X.509 certificates for the purposes of supporting validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPSEC. BGP is a critical component for the proper operation of the Internet as a whole. The BGPSEC protocol is under development as a component to address the requirement to provide security for the BGP protocol. The goal of BGPSEC is to design a </pre> internet-drafts< at >ietf.org 2013-04-18T01:31:27 http://permalink.gmane.org/gmane.ietf.sidr/5831 <pre>Hi all, We've been working on BGPSEC implementation based on the BIRD software package. It's currently in an alpha state but supports most of the BGPSEC protocol (no confederation or algorithm rollover). If anyone would like to play with it, I would appreciate any feedback. Below is a link to README and patch against v1.3.9 of BIRD. http://bgpsec.tislabs.com/ Thanks, -Mike </pre> Michael Baer 2013-04-16T23:19:29 http://permalink.gmane.org/gmane.ietf.sidr/5830 <pre> 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 : BGPSEC router key rollover as an alternative to beaconing Author(s) : Roque Gagliano Keyur Patel Brian Weis Filename : draft-ietf-sidr-bgpsec-rollover-02.txt Pages : 9 Date : 2013-04-15 Abstract: BGPSEC will need to address the impact from regular and emergency rollover processes for the BGPSEC End-Entity (EE) certificates that will be performed by Certificate Authorities (CAs) participating at the Resource Public Key Infrastructure (RPKI). This document provides general recommendations for that process and specifies how this process is used to control BGPSEC's window of exposure to replay attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-roll</pre> internet-drafts< at >ietf.org 2013-04-15T21:34:54 http://permalink.gmane.org/gmane.ietf.sidr/5829 <pre> Correction (clever spelling of name) + additional response (required for context of later minutes): --------- Eric Osterwilde: These numbers look close to independently arrived numbers. SK: They came from you. --- should be ---- Eric Osterweil: These numbers look close to independently arrived numbers. SK: They came from you. EO: No they didn't, as evidenced by the lack of citation and small (but measurable) differences in the numbers --------- Eric On Apr 13, 2013, at 7:15 AM, "Murphy, Sandra" &lt;Sandra.Murphy&lt; at &gt;sparta.com&gt; wrote: </pre> Osterweil, Eric 2013-04-15T19:15:54 http://permalink.gmane.org/gmane.ietf.sidr/5828 <pre>The draft minutes were posted yesterday. You can find them at http://www.ietf.org/proceedings/86/minutes/minutes-86-sidr. Many thanks to our minutes takers, Jeff and Sriram, who had to keep up with some very energetic discussions during the meeting! It is very much appreciated. Please do review the minutes. Send any corrections or additions to the list. Any changes must be made before 1 May 2013, when the proceedings will be declared final. --Sandy, speaking as wg co-chair </pre> Murphy, Sandra 2013-04-13T11:15:57 http://permalink.gmane.org/gmane.ietf.sidr/5827 <pre> 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 : Security Requirements for BGP Path Validation Author(s) : Steven M. Bellovin Randy Bush David Ward Filename : draft-ietf-sidr-bgpsec-reqs-07.txt Pages : 9 Date : 2013-04-12 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-reqs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bg</pre> internet-drafts< at >ietf.org 2013-04-12T11:13:33 http://permalink.gmane.org/gmane.ietf.sidr/5825 <pre>Hi all, We just released version 0.7 of our relying party software, rpstir. This version is primarily a bugfix release with fixes for bugs we found at the relying party testing session at IETF 86. Download: https://sourceforge.net/projects/rpstir/ Contact: rpstir-support&lt; at &gt;bbn.com </pre> David Mandelberg 2013-04-10T17:39:40 http://permalink.gmane.org/gmane.ietf.sidr/5823 <pre>chairs, could you please turn the crank to move this through wg adoption? thanks fwiw, i doubt it will move through to wglc/rfc, but rather a 6810bis may be the better path. randy From: internet-drafts&lt; at &gt;ietf.org To: randy&lt; at &gt;psg.com Cc: keyupate&lt; at &gt;cisco.com, turners&lt; at &gt;ieca.com Subject: New Version Notification for draft-ymbk-rpki-rtr-keys-01.txt Message-ID: &lt;20130409005340.26017.92925.idtracker&lt; at &gt;ietfa.amsl.com&gt; Date: Mon, 08 Apr 2013 17:53:40 -0700 A new version of I-D, draft-ymbk-rpki-rtr-keys-01.txt has been successfully submitted by Randy Bush and posted to the IETF repository. Filename: draft-ymbk-rpki-rtr-keys Revision: 01 Title: Router Key PDU for RPKI-Router Protocol Creation date: 2013-04-09 Group: Individual Submission Number of pages: 5 URL: http://www.ietf.org/internet-drafts/draft-ymbk-rpki-rtr-ke= ys-01.txt Status: http://datatracker.ietf.org/doc/draft-ymbk-rpki-rtr-keys Htmlized: http://tools.ietf.org/html/draft-ymbk-rpki-rtr-keys-01 Diff: http://www</pre> Randy Bush 2013-04-09T00:57:53 http://permalink.gmane.org/gmane.ietf.sidr/5822 <pre>This is to announce the BGP Secure Router Extension (BGP-SRx) Version 0.3 Prototype Implementation. This release includes extensive performance and robustness improvements, multi router support, re-design/re-write of the Quagga integration, and many bug fixes. BGP-SRx is an open source reference implementation and research platform for investigating emerging BGP security extensions and supporting protocols. The BGP-SRx suite consists of three parts: (1) SRx Server, (2) SRx API, and (3) Quagga-SRx (which integrates the SRx API into the Quagga router). The focus is on origin validation, although it is designed to be extended to path validation. Stub functionality for path validation is included in this version. Additionally, this release contains an SRx client/server test harnesses and a simple RPKI validation cache simulator (VCS). The VCS allows to manually feed ROA information into BGP-SRx server using the RPKI to Router protocol (rfc6810) as well as WireShark modules for debugging. For more information </pre> Borchert, Oliver 2013-04-08T20:28:06 http://permalink.gmane.org/gmane.ietf.sidr/5820 <pre>Shane, Fair question. In the case of RIPE, where there was a LEO action that was somewhat analogous to ROA whacking, RIPE fought the action (in court). Only time will tell if other RIRs adopt a similar approach. I think that's a fair characterization of an example that I gave. When a targeted entity detects that it's ROA has been whacked, it can try to notify RPs (via out of band means). The easiest action for RPs to take if they choose to not act on the whacking is to retain the old data that they have cached. So, the time it would take to deal the whacking is determined by the time it takes to get the word out to RPs (after detection of the whacking. yes, it does. I think this is a very, very unlikely failure case. I just mentioned it because others have cited this as a concern. Steve </pre> Stephen Kent 2013-04-03T15:06:35 http://permalink.gmane.org/gmane.ietf.sidr/5819 <pre> so.. a few times now we've cycled around the time to get objects splayed out across the rpki/cache/router system. I think we agreed ~3months ago (?perhaps longer, someone can search the mail archive if interested) that timelines for publication -&gt; all RP's have data was expected to be on the order of 10 minutes. I think danny handwaved that 5-10 minutes would be acceptable in his world. I also think that today (and for the next while) this timeline isn't important because folk mostly will be monitoring/marking and not dropping 'invalid' or 'unknown' routes. we could cycle around a few more times if it's of interest, but it seems to me... this is already solved, no? </pre> Christopher Morrow 2013-04-03T02:31:28 http://permalink.gmane.org/gmane.ietf.sidr/5818 <pre>Steve, Thanks for your response. Please see below. On Apr 2, 2013, at 12:08 PM, Stephen Kent &lt;kent&lt; at &gt;bbn.com&gt; wrote: That is true. However, I feel the need to point a subtle, yet important difference from today's environment. First, today, the ISP has direct knowledge prior to this 'event' occurring and given the direct contractual relationship they have with the customer the ISP would (IMO) be more likely to have a significant business interest (i.e.: get paid) to ensure the order was valid, applicable, etc. /before/ it was carried out. IOW, if the ISP is not providing service to the customer, then the ISP may be unable to bill for all or part of that service provided, (one, simple example: usage-based billing). OTOH, if a third-party (RIR?) higher up the allocation hierarchy were to "whack" a cert, thus making a cert for a resource invalid can the same be said? Second, consider the 'scope' of where such a change will be propagated and a time-to-restore back to "normalcy" after the matter is rectifie</pre> Shane Amante 2013-04-03T02:25:36 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.sidr