Stewart Bryant | 6 May 2013 14:30
Picon
Favicon

Fwd: [Errata Rejected] RFC6487 (3168)


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: Date: From: To: CC:
[Errata Rejected] RFC6487 (3168)
Mon, 6 May 2013 05:24:39 -0700
RFC Errata System <rfc-editor <at> rfc-editor.org>
<dmandelb <at> bbn.com>, <gih <at> apnic.net>, <ggm <at> apnic.net>, <robertl <at> apnic.net>
<stbryant <at> cisco.com>, <iesg <at> ietf.org>, <rfc-editor <at> rfc-editor.org>


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&eid=3168 -------------------------------------- Status: Rejected Type: Technical Reported by: David Mandelberg <dmandelb <at> bbn.com> Date Reported: 2012-03-26 Rejected by: Stewart Bryant (IESG) Section: 4.8 Original Text ------------- or non-critical. A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize; however, a non-critical extension MAY be ignored if it is not recognized [RFC5280]. Corrected Text -------------- or non-critical. A certificate-using system MUST reject the certificate if it encounters an extension not explicitly mentioned in this document. This is in contrast to RFC 5280 which allows non-critical extensions to be ignored. Notes ----- Other sections of the same document contradict the original section 4.8: Section 1: Any extensions not explicitly mentioned MUST be absent. The same applies to the CRLs used in the RPKI, that are also profiled in this document. Section 8: Certificate Extensions: This profile does not permit the use of any other critical or non-critical extensions. --VERIFIER NOTES-- This is a technical change to the RFC and needs to be addressed though the IETF consensus process and rather than via the errata process. -------------------------------------- RFC6487 (draft-ietf-sidr-res-certs-22) -------------------------------------- Title : A Profile for X.509 PKIX Resource Certificates Publication Date : February 2012 Author(s) : G. Huston, G. Michaelson, R. Loomans Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG .

<div>
    <br>Whilst this change was supported by one author and one of the
      chairs,<br>
      it is a technical change and thus outside the scope of change<br>
      permitted in an errata.<br><br>
      The correct approach is for a member of the WG to produce a <br>
      short update draft and test that this has WG and IETF consensus.<br><br>
      Please can the chairs drive this process.<br><br>
      - Stewart<br>
    <div class="moz-forward-container">
<br><br>
      -------- Original Message --------
      <table class="moz-email-headers-table" border="0" cellpadding="0" cellspacing="0">
<tr>Subject:

            <td>[Errata Rejected] RFC6487 (3168)</td>
          </tr>
<tr>Date: 
            <td>Mon, 6 May 2013 05:24:39 -0700</td>
          </tr>
<tr>From: 
            <td>RFC Errata System <a class="moz-txt-link-rfc2396E" href="mailto:rfc-editor <at> rfc-editor.org">&lt;rfc-editor <at> rfc-editor.org&gt;</a>
</td>
          </tr>
<tr>To: 
            <td>
<a class="moz-txt-link-rfc2396E" href="mailto:dmandelb <at> bbn.com">&lt;dmandelb <at> bbn.com&gt;</a>, <a class="moz-txt-link-rfc2396E" href="mailto:gih <at> apnic.net">&lt;gih <at> apnic.net&gt;</a>,
              <a class="moz-txt-link-rfc2396E" href="mailto:ggm <at> apnic.net">&lt;ggm <at> apnic.net&gt;</a>, <a class="moz-txt-link-rfc2396E" href="mailto:robertl <at> apnic.net">&lt;robertl <at> apnic.net&gt;</a>
</td>
          </tr>
<tr>CC: 
            <td>
<a class="moz-txt-link-rfc2396E" href="mailto:stbryant <at> cisco.com">&lt;stbryant <at> cisco.com&gt;</a>, <a class="moz-txt-link-rfc2396E" href="mailto:iesg <at> ietf.org">&lt;iesg <at> ietf.org&gt;</a>,
              <a class="moz-txt-link-rfc2396E" href="mailto:rfc-editor <at> rfc-editor.org">&lt;rfc-editor <at> rfc-editor.org&gt;</a>
</td>
          </tr>
</table>
<br><br>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:
<a class="moz-txt-link-freetext" href="http://www.rfc-editor.org/errata_search.php?rfc=6487&amp;eid=3168">http://www.rfc-editor.org/errata_search.php?rfc=6487&amp;eid=3168</a>

--------------------------------------
Status: Rejected
Type: Technical

Reported by: David Mandelberg <a class="moz-txt-link-rfc2396E" href="mailto:dmandelb <at> bbn.com">&lt;dmandelb <at> bbn.com&gt;</a>
Date Reported: 2012-03-26
Rejected by: Stewart Bryant (IESG)

Section: 4.8

Original Text
-------------
   or non-critical.  A certificate-using system MUST reject the

   certificate if it encounters a critical extension it does not

   recognize; however, a non-critical extension MAY be ignored if it is

   not recognized [RFC5280].

Corrected Text
--------------
   or non-critical.  A certificate-using system MUST reject the

   certificate if it encounters an extension not explicitly mentioned

   in this document.  This is in contrast to RFC 5280 which allows

   non-critical extensions to be ignored.

Notes
-----
Other sections of the same document contradict the original section 4.8:

Section 1:

   Any extensions not explicitly mentioned MUST be absent.  The same

   applies to the CRLs used in the RPKI, that are also profiled in this

   document.

Section 8:

   Certificate Extensions:

         This profile does not permit the use of any other critical or

         non-critical extensions.
 --VERIFIER NOTES-- 
   This is a technical change to the RFC and needs to be addressed though the IETF consensus process and rather than via the errata process.

--------------------------------------
RFC6487 (draft-ietf-sidr-res-certs-22)
--------------------------------------
Title               : A Profile for X.509 PKIX Resource Certificates
Publication Date    : February 2012
Author(s)           : G. Huston, G. Michaelson, R. Loomans
Category            : PROPOSED STANDARD
Source              : Secure Inter-Domain Routing
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

.

      <br>
</div>
    <br>
</div>
hammondjohnson | 27 Apr 2013 20:01
Favicon

Biggest Fake Conference in Computer Science

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 the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 

We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See 
http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the 
conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of
http://sites.google.com/site/dumpconf for comments from well-known researchers 
about WORLDCOMP. 

The status of your WORLDCOMP papers can be changed from scientific
to other (i.e., junk or non-technical) at any time. Better not to have a paper than 
having it in WORLDCOMP and spoil the resume and peace of mind forever!

Our study revealed that WORLDCOMP is a money making business, 
using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing 
out a small chunk of that money (around 20 dollars per paper published 
in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) 
who publicizes WORLDCOMP and also defends it at various forums, using 
fake/anonymous names. The puppet uses fake names and defames other conferences
to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to 
threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). 
That is, the puppet does all his best to get a maximum number of papers published 
at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. 

Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has 
refused to provide the venue for WORLDCOMP’13 because of the fears of their image 
being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 
is taking place at a different resort. WORLDCOMP will not be held after 2013. 

The draft paper submission deadline is over but still there are no committee 
members, no reviewers, and there is no conference Chairman. The only contact 
details available on WORLDCOMP’s website is just an email address! 

Let us make a direct request to Prof. Hamid arabnia: publish all reviews for 
all the papers (after blocking identifiable details) since 2000 conference. Reveal 
the names and affiliations of all the reviewers (for each year) and how many 
papers each reviewer had reviewed on average. We also request him to look at 
the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 

Sorry for posting to multiple lists. Spreading the word is the only way to stop 
this bogus conference. Please forward this message to other mailing lists and people. 

We are shocked with Prof. Hamid Arabnia and his puppet’s activities 
http://worldcomp-fake-bogus.blogspot.com   Search Google using the 
keyword worldcomp fake for additional links.

_______________________________________________
sidr mailing list
sidr <at> ietf.org
https://www.ietf.org/mailman/listinfo/sidr
Alexey Melnikov | 23 Apr 2013 17:00
Favicon

Results of the acceptance call for draft-newton-sidr-policy-qualifiers-01

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.

internet-drafts | 18 Apr 2013 03:31
Picon
Favicon

I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-05.txt


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
   protocol for full AS path validation based on the use of strong
   cryptographic primitives.  The end-entity (EE) certificates specified
   by this profile are issued under Resource Public Key Infrastructure
   (RPKI) Certification Authority (CA) certificates, containing the AS
   Identifier Delegation extension, to routers within the Autonomous
   System (AS).  The certificate asserts that the router(s) holding the
   private key are authorized to send out secure route advertisements on
   behalf of the specified AS.  This document also profiles the
   Certificate Revocation List (CRL), profiles the format of
   certification requests, and specifies Relying Party certificate path
   validation procedures.  The document extends the RPKI; therefore,
   this documents updates the RPKI Resource Certificates Profile (RFC
   6487).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Michael Baer | 17 Apr 2013 01:19
X-Face

Announce a BGPSEC implementation

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

--

-- 
Michael Baer
PARSONS
baerm <at> tislabs.com
internet-drafts | 15 Apr 2013 23:34
Picon
Favicon

I-D Action: draft-ietf-sidr-bgpsec-rollover-02.txt


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-rollover

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-rollover-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Murphy, Sandra | 13 Apr 2013 13:15

minutes were posted

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
internet-drafts | 12 Apr 2013 13:13
Picon
Favicon

I-D Action: draft-ietf-sidr-bgpsec-reqs-07.txt


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-bgpsec-reqs-07

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

David Mandelberg | 10 Apr 2013 19:39
Picon

rpstir-0.7 released

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 <at> bbn.com

Randy Bush | 9 Apr 2013 02:57

draft-ymbk-rpki-rtr-keys-01.txt

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 <at> ietf.org
To: randy <at> psg.com
Cc: keyupate <at> cisco.com, turners <at> ieca.com
Subject: New Version Notification for draft-ymbk-rpki-rtr-keys-01.txt
Message-ID: <20130409005340.26017.92925.idtracker <at> ietfa.amsl.com>
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.ietf.org/rfcdiff?url2=3Ddraft-ymbk-rpki-rtr-key=
s-01

Abstract:
   The RPKI/Router Protocol v0 is specified to carry the PDUs necessary
   for RPKI-based Origin Validation.  For BGPsec Path Validation, the
   routers also need data extracted from BGPsec Router Certificates.
   This document adds a PDU to the RPKI/Router Protocol to carry those
   data.

The IETF Secretariat

Borchert, Oliver | 8 Apr 2013 22:28
Favicon

Announcing BGP-SRx 0.3.0 service release

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 on BGP-SRx, and to download the prototype and tools, see:

http://www-x.antd.nist.gov/bgpsrx/

 

Comments and feedback about BGP-SRx are welcome. See the project page for details.

 

Thanks,

Oliver Borchert

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

Oliver Borchert, Computer Scientist

National Institute of Standards and Technology

(Phone) 301.975.4856 , (Fax) 301.975.6238

 

<div><div class="WordSection1">
<p class="MsoNormal"><span>This is to announce the BGP Secure Router Extension (BGP-SRx) Version 0.3 Prototype Implementation. <p></p></span></p>
<p class="MsoNormal"><span>This release includes extensive performance and robustness improvements, <p></p></span></p>
<p class="MsoNormal"><span>multi router support, re-design/re-write of the Quagga integration, <p></p></span></p>
<p class="MsoNormal"><span>and many bug fixes. <p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>BGP-SRx is an open source reference implementation and research platform <p></p></span></p>
<p class="MsoNormal"><span>for investigating emerging BGP security extensions and supporting protocols. <p></p></span></p>
<p class="MsoNormal"><span>The BGP-SRx suite consists of three parts: <br>(1) SRx Server, (2) SRx API, and (3) Quagga-SRx (which integrates the SRx API <p></p></span></p>
<p class="MsoNormal"><span>into the Quagga router). <p></p></span></p>
<p class="MsoNormal"><span>The focus is on origin validation, although it is designed to be extended to <p></p></span></p>
<p class="MsoNormal"><span>path validation. Stub functionality for path validation is included in this<p></p></span></p>
<p class="MsoNormal"><span>version.<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>Additionally, this release contains an SRx client/server test harnesses and a<p></p></span></p>
<p class="MsoNormal"><span>simple RPKI validation cache simulator (VCS). The VCS allows to manually <p></p></span></p>
<p class="MsoNormal"><span>feed ROA information into BGP-SRx server using the RPKI to Router protocol (rfc6810) <p></p></span></p>
<p class="MsoNormal"><span>as well as WireShark modules for debugging.<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>For more information on BGP-SRx, and to download the prototype and tools, see:<p></p></span></p>
<p class="MsoNormal"><span><a href="http://www-x.antd.nist.gov/bgpsrx/">http://www-x.antd.nist.gov/bgpsrx/</a><p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>Comments and feedback about BGP-SRx are welcome. See the project page for details.<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>Thanks,<p></p></span></p>
<p class="MsoNormal"><span>Oliver Borchert<p></p></span></p>
<p class="MsoNormal">-------------------------------------------------------------<p></p></p>
<p class="MsoNormal">Oliver Borchert, Computer Scientist<p></p></p>
<p class="MsoNormal">National Institute of Standards and Technology<p></p></p>
<p class="MsoNormal">(Phone) 301.975.4856 , (Fax) 301.975.6238<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
</div></div>

Gmane