= Sounds good R= 11; I look forward to seeing the revised draft.

<= o:p>

Thanks,
--David

From: Stephen Kent [mailto:kent@b= bn.com]
Sent: Wednesday, October 02, 2013 11:04 AM
To:= Black, David
Cc: achi@cs.unc.edu; General Area Review Team (gen-= art@ietf.org); stbryant@cisco.com; ietf@ietf.org; sidr@ietf.org
Subje= ct: Re: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06<= /span>

David,

Steve,

I think the modified introduction te= xt suffices to connect the PATHSEC and BGPsec terms, but I don’t thin= k that referring to the SIDR WG charter for the PATHSEC goals is reasonable= – an RFC is an archive document, whereas a WG charter is not.=

The revised intro text now paraphrases = the text from the SIDR charter that
describes the path security goals.
Steve

= --_000_8D3D17ACE214DC429325B2B98F3AE712025DCE1A00MX15Acorpemcc_-- From internet-drafts@ietf.org Mon Oct 7 04:13:29 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85EA21F9DD0; Mon, 7 Oct 2013 04:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xze-Tguh6qSp; Mon, 7 Oct 2013 04:13:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F4121F9FED; Mon, 7 Oct 2013 04:13:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131007111327.16131.47667.idtracker@ietfa.amsl.com> Date: Mon, 07 Oct 2013 04:13:27 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-origin-ops-22.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 11:13:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : RPKI-Based Origin Validation Operation Author(s) : Randy Bush Filename : draft-ietf-sidr-origin-ops-22.txt Pages : 11 Date : 2013-10-07 Abstract: Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present those which are most critical. It is expected to evolve as RPKI-based origin validation continues to be deployed and the dynamics are better understood. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-ops There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-22 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-origin-ops-22 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 kent@bbn.com Mon Oct 7 08:44:11 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B5721E80AD for ; Mon, 7 Oct 2013 08:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.369 X-Spam-Level: X-Spam-Status: No, score=-105.369 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCgBrbAbuOO0 for ; Mon, 7 Oct 2013 08:44:05 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B6B7321E80A1 for ; Mon, 7 Oct 2013 08:44:04 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:42047 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VTCyY-000I7F-Kf; Mon, 07 Oct 2013 11:44:03 -0400 Message-ID: <5252D6C1.4090909@bbn.com> Date: Mon, 07 Oct 2013 11:44:01 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sidr@ietf.org, "Murphy, Sandra" References: <24B20D14B2CD29478C8D5D6E9CBB29F6749E8EEB@CVA-MB002.centreville.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F674A5C902@CVA-MB001.centreville.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F674A5C902@CVA-MB001.centreville.ads.sparta.com> Content-Type: multipart/alternative; boundary="------------010302000905080504080107" Subject: Re: [sidr] some comments on draft-ietf-sidr-cps-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 15:44:12 -0000 This is a multi-part message in MIME format. --------------010302000905080504080107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sandy, We have updated the CPS to address your comments. Karen will post a revised version soon. Responses to the questions you posed appear below. Steve ------ Terry asked why 5.7 (key rollover and disaster recovery) was "[OMITTED]".Steve suggested a small paragraph. *5.7 is Key changeover (not disaster recovery) is present and it contains appropriate text. As noted below, disaster recovery was inadvertently omitted in the CP, and will be added there. It will say "The CPS for each CA MUST specify procedures it will followin the event of compromise, and its disaster recovery plans."* David noted that sections 5.7 and 5.8 don't match 6484.Steve said that 6484 was in error.If I understand correctly, 6484 was supposed to omit section 5.7, and the section numbering was supposed to be maintained from 3647, so 6484's 5.7 should be numbered 5.8. *Yes, that's correct.* Q: The CPS is an instantiation of 3647, not a re-instantiation of 6484's instantiation of 3647, so it is OK if the CPS has sections from 3647 that are not present in 6484.Correct? *Yes, the CP and CPS are both supposed to be based on 3647, so we need to issue an erratum for the CP (6484) to fix the numbering error. * I agree with Steve that the change to 6484 should just be an errata (section numbering typo, not a substantive change) rather than an update. *Thanks.* I found a couple other things, while I was trying to figure that out. Sections 9.1.2 and 9.1.3 match the section titles of 3647's 9.1.4 and 9.1.5.I presume the CPS intended to omit 9.1.2 and 9.1.3 from 3647 and the sequential numbering in the draft is incorrect. *Yes, that is correct. We'll fix the numbering. I put OMITTED for 9.1.2 and 9.1.3 because RPKI CAs make certificates and CRLs available for free.* I am not clear why sections 5.4.6, 5.4.7, and 5.5, which are present in 3647 but omitted in 6484, are present here.They are tagged as OMITTED and have no text.Why not just leave them out as you did for other sections?Not a biggie, but I'm curious. *I'm in favor of leaving them out here, to better match 6484, but I think Karen encountered a formatting problem that made it hard. So we may have to leave them in, marked as omitted. * RFC3647 is mentioned but not referenced. *Fixed.* There are some "should" uses that might be supposed to be "SHOULD". In particular I note that the text about policy qualifiers ("It should be the same URI") looks like it is supposed to be 2119 language. And is that a SHOULD not a MUST? Out of curiosity: any concerns if a CA publishes a CPS somewhere other than i the URI of the policy qualifier and the two CPSs are different? Confusion to the user is the only drawback I can see. *Changed to SHOULD for PQ, but kept "should" when used with "commensurate with" and "consistent with" phrases. Changed should to MUST when referring to PoP and a few other significant security references.* I am not sure why the preface's suggestions for editing of the draft text to produce a CPS document includes deleting the normative references. The CPS text that would be retained includes references to 6484, 6485 and 6487, and there is use of 2119 language. Those are all in the normative references section and would be deleted. *Changed to say that only 2119 is to be omitted.* Another of those suggested edits is to delete the Disclaimer of Validity section. But there is no section by that name. It also suggests deleting the section Intellectual Property Statement. There is no section of that exact name, but there is a section titled "9.5. Intellectual property rights" but I do not believe that you mean for the user to delete that section. *The offending text has been removed.* 2.1 says at . The "SIDR" part is not a permanent reference, so likely to produce comment. "IETF-designated"?? *Changed "SIDR" to "IETF."* I noticed that section 4.4.3 was added between -01 and -02. I figure that's (partly) because it is a MUST in 6484. That got me to looking at the MUSTs/SHOULDs of 6484. *yeah, it's a security doc, so we're pretty judgmental!* 2.3 says you still need to provide this information for relying parties. This should include the period of time within which a certificate will be published after the CA issues the certificate, and the period of time within which a CA will publish a CRL with an entry for a revoked certificate, after the CA revokes that certificate.> 2.3 of 6484 says the CA "MUST" specify these timeframes in the CPS. *I changed this to a MUST when I checked all the SHOULDs.* 3.1.2 of 6484 says that the CA SHOULD NOT use meaningful names, which leaves the CA some leeway. 3.1.2 in the CPS draft says "The name of the subscriber will not be "meaningful" ", which is less flexible. OK, so this is a template that the CAs can modify, and that language is helpful to the desired outcome that the subject names are meaningless. *I've changed it to more closely match 6484.* 3.1.3 says "Although Subject names in certificates issued by this Organization need not be meaningful," which is inconsistent with 3.1.2. And 3.1.5 says "Because the Subject names are not intended to be meaningful". So is it "will not be meaningful" or "need not be meaningful"? *changed to "SHOULD NOT be meaningful." Could make this an erratum for 6484 if we want.* 4.7.1 of 6484 says Note that if a certificate is revoked to replace the RFC 3779 extensions, the replacement certificate MUST incorporate the same public key rather than a new key. 4.7.1 of the CPS draft add's a "unless" clause: If a certificate is revoked to replace the RFC 3779 extensions, the replacement certificate will incorporate the same public key, not a new key, unless the subscriber requests a re-key at the same time. Does the "unless" clause make the CPS in violation of 6484? *I think we didn't anticipate the possibility of a rekey occurring at the same time as a 3779 extension change, when we wrote 6484, but we thought about it while revising the CPS. I've removed the clause, ignoring the possible conflation of two actions in the CPS, to maintain consistency with the CP.* 6.3.2 of 6484 says case, the validity period for certificates MUST be chosen by the issuing CA and described in its CPS. 6.3.2 of the CPS draft says The CA's key pair will have a validity interval of . which sounds like it does not describe the validity period of the certs it issues, but rather its own cert (which according to 6484 is under the control of the CA's parent) *To clarify this text I added the following, inside the angle brackets:* * Note that the CA's key lifetime is under the control of it's issuer,* * so the CPS MUST reflect the key lifetime imposed by the issuer.* 9 of the CPS drafts says Sandy,

We have updated the CPS to address your comments. Karen will post a revised version soon.

Responses to the questions you posed appear below.

Steve
------

Terry asked why 5.7 (key rollover and disaster recovery) was "[OMITTED]". Steve suggested a small paragraph.

5.7 is Key changeover (not disaster recovery) is present and it contains appropriate text. As noted below, disaster recovery was inadvertently omitted in the CP, and will be added there. It will say “The CPS for each CA MUST specify procedures it will follow in the event of compromise, and its disaster recovery plans.”

David noted that sections 5.7 and 5.8 don't match 6484. Steve said that 6484 was in error. If I understand correctly, 6484 was supposed to omit section 5.7, and the section numbering was supposed
to be maintained from 3647, so 6484's 5.7 should be numbered 5.8.

Yes, that’s correct.

Q: The CPS is an instantiation of 3647, not a re-instantiation of 6484's instantiation of 3647, so it
is OK if the CPS has sections from 3647 that are not present in 6484. Correct?

Yes, the CP and CPS are both supposed to be based on 3647, so we need to issue an erratum for the CP (6484) to fix the numbering error.

I agree with Steve that the change to 6484 should just be an errata (section numbering typo, not a substantive change) rather than an update.

Thanks.

I found a couple other things, while I was trying to figure that out.

Sections 9.1.2 and 9.1.3 match the section titles of 3647's 9.1.4 and 9.1.5. I presume the CPS intended to omit 9.1.2 and 9.1.3 from 3647 and the sequential numbering in the draft is incorrect.

Yes, that is correct. We’ll fix the numbering. I put OMITTED for 9.1.2 and 9.1.3 because RPKI CAs make certificates and CRLs available for free.

I am not clear why sections 5.4.6, 5.4.7, and 5.5, which are present in 3647 but omitted in 6484, are present here. They are tagged as OMITTED and have no text. Why not just leave them out as you did for other sections? Not a biggie, but I'm curious.

I’m in favor of leaving them out here, to better match 6484, but I think Karen encountered a formatting problem that made it hard. So we may have to leave them in, marked as omitted.

RFC3647 is mentioned but not referenced.

Fixed.

There are some "should" uses that might be supposed to be "SHOULD".  In particular I note that the text 
about policy qualifiers ("It should be the same URI") looks like it is supposed to be 2119 language.  And is 
that a SHOULD not a MUST?  Out of curiosity: any concerns if a CA publishes a CPS somewhere other than i
the URI of the policy qualifier and the two CPSs are different?  Confusion to the user is the only drawback 
I can see.

Changed to SHOULD for PQ, but kept “should” when used with “commensurate with” and “consistent with” phrases.
Changed should to MUST when referring to PoP and a few other significant security references.

I am not sure why the preface's suggestions for editing of the draft text to produce a CPS document includes 
deleting the normative references.   The CPS text that would be retained includes references to 6484, 6485 and 
6487, and there is use of 2119 language.  Those are all in the normative references section and would be deleted.

Changed to say that only 2119 is to be omitted.

Another of those suggested edits is to delete the Disclaimer of Validity section.  But there is no section 
by that name.  It also suggests deleting the section Intellectual Property Statement.  There is no section 
of that exact name, but there is a section titled "9.5. Intellectual property rights" but I do not believe 
that you mean for the user to delete that section.

The offending text has been removed.

2.1 says

        <Insert SIDR-designated protocol name here> at <insert URL here>. The "SIDR" part is not a 
        permanent reference, so likely to produce comment.  "IETF-designated"??

Changed “SIDR” to “IETF.”

I noticed that section 4.4.3 was added between -01 and -02.  I figure that's (partly) because it is a MUST in 6484.  
That got me to looking at the MUSTs/SHOULDs of 6484. <note: I did check all the SHOULDs in 6484, but I haven't 
checked all the MUSTs.  There are more than 100!>

yeah, it's a security doc, so we’re pretty judgmental!

2.3 says

        you still need to provide this information for relying parties. This should include the period 
        of time within which a certificate will be published after the CA issues the certificate, 
        and the period of time within which a CA will publish a CRL with an entry for a revoked    
        certificate, after the CA revokes that certificate.>

2.3 of 6484 says the CA "MUST" specify these timeframes in the CPS.

I changed this to a MUST when I checked all the SHOULDs.

3.1.2 of 6484 says that the CA SHOULD NOT use meaningful names, which leaves the CA some leeway.  
3.1.2 in the CPS draft says "The name of the subscriber will not be "meaningful" ", which is less flexible.  
OK, so this is a template that the CAs can modify, and that language is helpful to the desired outcome that 
the subject names are meaningless.

I’ve changed it to more closely match 6484.

3.1.3 says

        "Although Subject names in certificates issued by this Organization need not be meaningful," 
which is inconsistent with 3.1.2.  And 3.1.5 says "Because the Subject names are not intended to be meaningful".  
So is it "will not be meaningful" or "need not be meaningful"?

changed to “SHOULD NOT be meaningful.” Could make this an erratum for 6484 if we want.

 4.7.1 of 6484 says

        Note that if a certificate is revoked to replace the RFC 3779 extensions, the replacement 
        certificate MUST incorporate the same public key rather than a new key.

4.7.1 of the CPS draft add's a "unless" clause:

        If a certificate is revoked to replace the RFC 3779 extensions, the replacement certificate 
        will incorporate the same public key, not a  new key, unless the subscriber requests a re-key 
        at the same time.

Does the "unless" clause make the CPS in violation of 6484?

 I think we didn’t anticipate the possibility of a rekey occurring at the same time as a 3779 extension change, 
when we wrote 6484, but we thought about it while revising the CPS. I’ve removed the clause, ignoring the 
possible conflation of two actions in the CPS, to maintain consistency with the CP.

6.3.2 of 6484 says

        case, the validity period for certificates MUST be chosen by the issuing CA and described in its CPS.

6.3.2 of the CPS draft says

        The <Name of Organization> CA's key pair will have a validity interval of <insert number of years>. 
        <These key pairs and certificates should have reasonably long validity intervals, e.g., 10  years, 
        to minimize the disruption caused by key changeover.>

which sounds like it does not describe the validity period of the certs it issues, but rather 
its own cert (which according to 6484 is under the control of the CA's parent)

To clarify this text I added the following, inside the angle brackets:

        Note that the CA’s key lifetime is under the control of it’s issuer,

        so the CPS MUST reflect the key lifetime imposed by the issuer.

9 of the CPS drafts says

        <The sections below are optional. Fill them in as appropriate for your organization. 

The CP says that CAs should cover 9.1 to 9.11 and 9.13 to 9.17 although not every CA will choose to do so.
but there's no 9.17 in the outline that follows.  Oversight?  Dear God, Sandy, just how anal can you be?

Changed the text to say 9.16.

--------------010302000905080504080107-- From internet-drafts@ietf.org Tue Oct 8 10:25:40 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6BE21E8253; Tue, 8 Oct 2013 10:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im5DK9oPSguC; Tue, 8 Oct 2013 10:25:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F293C11E8137; Tue, 8 Oct 2013 10:25:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131008172537.25649.24994.idtracker@ietfa.amsl.com> Date: Tue, 08 Oct 2013 10:25:37 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-cps-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 17:25:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : Template for a Certification Practice Statement (CPS) fo= r the Resource PKI (RPKI) Author(s) : BBN Technologies Filename : draft-ietf-sidr-cps-03.txt Pages : 44 Date : 2013-10-08 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-cps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-cps-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-cps-03 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 internet-drafts@ietf.org Tue Oct 8 13:41:31 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D6D21F9FC7; Tue, 8 Oct 2013 13:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtOMLMyBJCVj; Tue, 8 Oct 2013 13:41:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC9321F9FD6; Tue, 8 Oct 2013 13:41:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131008204114.28645.53351.idtracker@ietfa.amsl.com> Date: Tue, 08 Oct 2013 13:41:14 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 20:41:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : Threat Model for BGP Path Security Author(s) : Stephen Kent Andrew Chi Filename : draft-ietf-sidr-bgpsec-threats-07.txt Pages : 19 Date : 2013-10-08 Abstract: This document describes a threat model for the context in which (E)BGP path security mechanisms will be developed. The threat model includes an analysis of the RPKI, and focuses on the ability of an AS to verify the authenticity of the AS path info received in a BGP update. We use the term PATHSEC to refer to any BGP path security technology that makes use of the RPKI. PATHSEC will secure BGP [RFC4271], consistent with the inter-AS security focus of the RPKI [RFC6480]. The document characterizes classes of potential adversaries that are considered to be threats, and examines classes of attacks that might be launched against PATHSEC. It does not revisit attacks against unprotected BGP, as that topic has already been addressed in [RFC4271]. It concludes with brief discussion of residual vulnerabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-threats-07 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 internet-drafts@ietf.org Tue Oct 8 21:09:40 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D365921F9CA1; Tue, 8 Oct 2013 21:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5UKJf1dZ2uA; Tue, 8 Oct 2013 21:09:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E784821F93F8; Tue, 8 Oct 2013 21:09:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131009040939.28645.5262.idtracker@ietfa.amsl.com> Date: Tue, 08 Oct 2013 21:09:39 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-reqs-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 04:09:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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-08.txt Pages : 9 Date : 2013-10-08 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-reqs-08 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 wesley.george@twcable.com Wed Oct 9 05:48:58 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C235311E818B for ; Wed, 9 Oct 2013 05:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.713 X-Spam-Level: X-Spam-Status: No, score=-0.713 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLvEnz+q8UrY for ; Wed, 9 Oct 2013 05:48:54 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 38E4311E8184 for ; Wed, 9 Oct 2013 05:48:51 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.90,1063,1371096000"; d="scan'208";a="141414984" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 09 Oct 2013 08:47:54 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 9 Oct 2013 08:48:50 -0400 From: "George, Wes" To: "sidr@ietf.org" Date: Wed, 9 Oct 2013 08:48:49 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-07.txt Thread-Index: Ac7EZuDlAqgborrLQ22maojv3orRFAAhqYfg Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923043C7556E1@PRVPEXVS15.corp.twcable.com> References: <20131008204114.28645.53351.idtracker@ietfa.amsl.com> In-Reply-To: <20131008204114.28645.53351.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 12:48:58 -0000 This update does not address any of my comments from my review (message sen= t on 9/12). Thanks, Wes > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Tuesday, October 08, 2013 4:41 PM > To: i-d-announce@ietf.org > Cc: sidr@ietf.org > Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-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 : Threat Model for BGP Path Security > Author(s) : Stephen Kent > Andrew Chi > Filename : draft-ietf-sidr-bgpsec-threats-07.txt > Pages : 19 > Date : 2013-10-08 > > Abstract: > This document describes a threat model for the context in which > (E)BGP path security mechanisms will be developed. The threat model > includes an analysis of the RPKI, and focuses on the ability of an AS > to verify the authenticity of the AS path info received in a BGP > update. We use the term PATHSEC to refer to any BGP path security > technology that makes use of the RPKI. PATHSEC will secure BGP > [RFC4271], consistent with the inter-AS security focus of the RPKI > [RFC6480]. > > The document characterizes classes of potential adversaries that are > considered to be threats, and examines classes of attacks that might > be launched against PATHSEC. It does not revisit attacks against > unprotected BGP, as that topic has already been addressed in > [RFC4271]. It concludes with brief discussion of residual > vulnerabilities. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-threats-07 > > > 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/ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From kent@bbn.com Wed Oct 9 08:13:21 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E7321E809F for ; Wed, 9 Oct 2013 08:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.966 X-Spam-Level: X-Spam-Status: No, score=-105.966 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gui95aUVsuxe for ; Wed, 9 Oct 2013 08:13:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6A87321E811A for ; Wed, 9 Oct 2013 08:13:12 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49391) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VTvRn-0007W9-BQ; Wed, 09 Oct 2013 11:13:11 -0400 Message-ID: <52557287.8010205@bbn.com> Date: Wed, 09 Oct 2013 11:13:11 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "George, Wes" References: <20131008204114.28645.53351.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043C7556E1@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923043C7556E1@PRVPEXVS15.corp.twcable.com> Content-Type: multipart/alternative; boundary="------------070307010501060905010403" Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 15:13:21 -0000 This is a multi-part message in MIME format. --------------070307010501060905010403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Wes, Sorry. I was on vacation when your message was sent, and I did not see it when I processed all of the messages upon return, two weeks later. I did locate it in the archive today, after seeing your message. I'll treat your comments as IETF last call comments since, as you note, they were posted long after WGLC. Your comments were: Maybe I'm hypersensitive to such in light of recent accusations of national actors subverting supposedly secure infrastructure to behave badly, but I find it odd that this threats document doesn't discuss the interaction between a national actor and the machinery provided by draft-ietf-sidr-ltamgmt. i.e. a national actor imposes upon SPs that operate inside their borders to use their own Local (and compromised) Trust Anchor to subvert the protections provided by RPKI. While this is primarily a concern for origin validation, I view it as distinct from the existing discussion of attacks on a CA covered in 4.5, and there is no equivalent Origin Validation threats document. It may be that the right path is to augment the discussion of this issue in the LTA management draft, and simply reference it from this draft, but I don't think that this is discussed suitably in the security considerations of either draft. The increased sensitivity to nation-level threats is understandable.The threats doc lists nations as a category of adversary in Section 3; we have not ignored them. (Can you name any other IETF threat analysis that has done so?) The doc does not discuss attacks by nations against LTAM. The RPKI, as specified in RFCs 6480-91, is addressed for completeness, and because the SIDR charter mandates use of the RPKI. LTAM is still an I-D; it is not part of the RPKI standards. As such, I don't consider it to be in scope for this doc. More to the point, as lead author of the LTAM doc, I anticipate reducing its scope in a way that may remove the concern you raised. However, our new I-D, "Suspenders" may raise similar concerns. I think it appropriate to discuss them if and when the WG elects to adopt that doc as a work item. Section 4.2 is missing any discussion regarding manipulation of other route attributes that may be used to affect a BGP route's selection, such as MED, Local Pref. It's covered in section 5, but since this occurred to me whilst reading section 4.2, perhaps some mention in 4.2 would be useful, I don't know. As you noted, Section 5 discusses other attributes that are not considered in this doc, and explains why. Unless Stewart directs us to add a forward pointer in 4.2, I don't plan to do so. That said, I also think that the discussion of this topic at the end of session 5 is inadequate for a document in IETF LC. The SIDR WG made a conscious decision to secure *only* the AS_Path attribute, and leave other attributes insecure, but there is no summary of the underlying rationale supporting this choice. Pointing to a WG charter as the sole explanation, and noting that this document should be changed if the charter is updated is unacceptable, as it provides no context to a reader that was not privy to the discussion leading to that charter/scope decision. No one (other than you) suggested that we include a discussion of the history of the charter/scope discussion here. I do not recall seeing such a discussion in any other threat analysis doc. I don't plan to add such a discussion here. It also makes reference to something fairly ephemeral (a WG and charter) in a permanent document. Fine for a draft in WG discussion to have that sort of placeholder, but not anymore. The latest version (-07) of the threats document added a paraphrase of the relevant charter text to address the concern about referencing a charter, an issue raised by David Black in his GENART review. There is a brief (and IMO incomplete) discussion of this matter to be found in section 2.3 of draft-sriram-bgpsec-design-choices that could be referenced, but since that document's future is unclear, some standalone discussion within this document might be more appropriate. At a minimum, a threats document should discuss why these threats are not considered high enough risk to justify the added complexity of securing them using the RPKI. A threat analysis, in principle, identifies adversaries, their motivations for carrying out classes of attacks, and their capabilities to do so. It need not establish requirements for acceptable designs, or propose countermeasures to address classes of attacks. In this doc we went beyond those essential threat analysis elements, because there was no RPKI threat doc (and because the charter calls for use of the RPKI as a basis for BGPSEC). A requirements doc is a place where one defines what needs to be done by a solution, to address the threats previously described. Steve --------------070307010501060905010403 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Wes,

Sorry. I was on vacation when your message was sent, and I did not see it when I processed all
of the messages upon return, two weeks later. I did locate it in the archive today, after
seeing your message. I'll treat your comments as IETF last call comments since, as you note,
they were posted long after WGLC.

Your comments were:

Maybe I'm hypersensitive to such in light of recent accusations of national actors subverting supposedly secure infrastructure to behave badly, but I find it odd that this threats document doesn't discuss the interaction between a national actor and the machinery provided by draft-ietf-sidr-ltamgmt. i.e. a national actor imposes upon SPs that operate inside their borders to use their own Local (and compromised) Trust Anchor to subvert the protections provided by RPKI. While this is primarily a concern for origin validation, I view it as distinct from the existing discussion of attacks on a CA covered in 4.5, and there is no equivalent Origin Validation threats document. It may be that the right path is to augment the discussion of this issue in the LTA management draft, and simply reference it from this draft, but I don't think that this is discussed suitably in the security considerations of either draft.

The increased sensitivity to nation-level threats is understandable.The threats doc lists nations as a category of adversary in Section 3; we have not ignored them. (Can you name any other IETF threat analysis that has done so?) The doc does not discuss attacks by nations against LTAM. The RPKI, as specified in RFCs 6480-91, is addressed for completeness, and because the SIDR charter mandates use of the RPKI. LTAM is still an I-D; it is not part of the RPKI standards. As such, I don't consider it to be in scope for this doc.

More to the point, as lead author of the LTAM doc, I anticipate reducing its scope in a way that
may remove the concern you raised. However, our new I-D, "Suspenders" may raise similar
concerns. I think it appropriate to discuss them if and when the WG elects to adopt that doc
as a work item.

Section 4.2 is missing any discussion regarding manipulation of other route attributes that may be used to affect a BGP route's selection, such as MED, Local Pref. It's covered in section 5, but since this occurred to me whilst reading section 4.2, perhaps some mention in 4.2 would be useful, I don't know.

As you noted, Section 5 discusses other attributes that are not considered in this doc, and explains
why. Unless Stewart directs us to add a forward pointer in 4.2, I don't plan to do so.

That said, I also think that the discussion of this topic at the end of session 5 is inadequate for a document in IETF LC. The SIDR WG made a conscious decision to secure *only* the AS_Path attribute, and leave other attributes insecure, but there is no summary of the underlying rationale supporting this choice. Pointing to a WG charter as the sole explanation, and noting that this document should be changed if the charter is updated is unacceptable, as it provides no context to a reader that was not privy to the discussion leading to that charter/scope decision.

No one (other than you) suggested that we include a discussion of the history of the charter/scope discussion here. I do not recall seeing such a discussion in any other threat analysis doc. I don't
plan to add such a discussion here.

It also makes reference to something fairly ephemeral (a WG and charter) in a permanent document. Fine for a draft in WG discussion to have that sort of placeholder, but not anymore.

The latest version (-07) of the threats document added a paraphrase of the relevant charter text to address the concern about referencing a charter, an issue raised by David Black in his GENART review.

There is a brief (and IMO incomplete) discussion of this matter to be found in section 2.3 of draft-sriram-bgpsec-design-choices that could be referenced, but since that document's future is unclear, some standalone discussion within this document might be more appropriate. At a minimum, a threats document should discuss why these threats are not considered high enough risk to justify the added complexity of securing them using the RPKI.

A threat analysis, in principle, identifies adversaries, their motivations for carrying out classes of attacks, and their capabilities to do so. It need not establish requirements for acceptable designs, or propose countermeasures to address classes of attacks. In this doc we went beyond those essential threat analysis elements, because there was no RPKI threat doc (and because the charter calls for use of the RPKI as a basis for BGPSEC). A requirements doc is a place where one defines what needs to be done by a solution, to address the threats previously described.

Steve
--------------070307010501060905010403-- From david.black@emc.com Wed Oct 9 09:30:45 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C1F21F99F0; Wed, 9 Oct 2013 09:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qSQ5CTFo2c1; Wed, 9 Oct 2013 09:30:40 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id E744421F880F; Wed, 9 Oct 2013 09:28:27 -0700 (PDT) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r99GRsQn003031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Oct 2013 12:27:55 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com r99GRsQn003031 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1381336075; bh=GKyJC2XbFKRMKdRcyRsXRTllMz8=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=JNPjmDwK8flzFwELo6wTtVT2xPYUONpTNQO3teab5MSVZN+TrdOeoiL9QeVApPrNx 0Pgs4k1S0tEycCSmVYQTDnSrbVsjUoSZM0JJxnVcMFLKT47+d+3bnuelYaIhwmfUCn olRyNfJDjjAR9hCoo1Is988mz265/aT1CipCIKXc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com r99GRsQn003031 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd02.lss.emc.com (RSA Interceptor); Wed, 9 Oct 2013 12:27:46 -0400 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r99GRjwl030080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 12:27:46 -0400 Received: from mx15a.corp.emc.com ([169.254.1.46]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Wed, 9 Oct 2013 12:27:46 -0400 From: "Black, David" To: "kent@bbn.com" , "achi@cs.unc.edu" , "General Area Review Team (gen-art@ietf.org)" Date: Wed, 9 Oct 2013 12:27:44 -0400 Thread-Topic: Gen-ART review of draft-ietf-sidr-bgpsec-threats-07 Thread-Index: Ac7FDHoXTpnzCWzcRRiztQCbALnpTw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712025DCE24E0@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-EMM-GWVC: 1 X-EMM-McAfeeVC: 1 X-RSA-Classifications: public Cc: "sidr@ietf.org" , "ietf@ietf.org" Subject: [sidr] Gen-ART review of draft-ietf-sidr-bgpsec-threats-07 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 16:30:45 -0000 After discussion with the authors, the -07 version of this draft resolves the two issues in the Gen-ART review of the -06 version. In summary: - Text has been added to explain the relationship of the PATHSEC and BGPsec= terms. - Citations have been added to the RFCs that explain the RPKI RP caching requirements. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Monday, September 23, 2013 8:25 PM > To: kent@bbn.com; achi@cs.unc.edu; General Area Review Team (gen-art@ietf= .org) > Cc: Black, David; stbryant@cisco.com; ietf@ietf.org; sidr@ietf.org > Subject: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06 >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >=20 > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. >=20 > Document: draft-ietf-sidr-bgpsec-threats-06 > Reviewer: David L. Black > Review Date: September 23, 2012 > IETF LC End Date: September 23, 2012 >=20 > Summary: This draft is on the right track, but has open issues > described in the review. >=20 > This draft describes the threat model for BGP Path Security. The > draft generally reads well, but does contain quite a bit of serious > security analysis of an important routing protocol and hence requires > both security and routing expertise to fully understand. >=20 > Major issue: >=20 > This draft contains more than just a threat model. It also contains > a high level security analysis of the security architecture/approach > that applies the RPKI to secure use of BGP. That analysis appears to > be good, but it's somehow disconnected from the rest of the sidr WG's > work, by what I hope is simply a terminology problem: > - This draft refers to the security architecture/approach for > BGP as PATHSEC. > - Many of the other sidr WG draft refer to that security as > BGPsec > In effect, the PATHSEC security architecture/approach appears to be > implicit in this draft. >=20 > Something's missing - if those two terms were meant to be the same, > BGPsec should probably be used in this draft, otherwise, the relationship > should be described. I've tagged this as a major issue, as it makes > text like the following in Section 4.2 rather unclear: >=20 > Stale Path Announcement: If PATHSEC-secured announcements can > expire, such an announcement may be propagated with PATHSEC data > that is "expired". This behavior would violate the PATHSEC goals > and is considered a type of replay attack. >=20 > What is "PATHSEC data"? What are "the PATHSEC goals"? The statement > in the abstract that " We use the term PATHSEC to refer to any BGP > path security technology that makes use of the RPKI" doesn't seem to > answer these questions. >=20 > Minor Issue: >=20 > Section 4.4 seems somewhat loose on caching by RPs, considering the > importance of that caching in countering a number of the attacks describe= d > in that section - in multiple cases, RP detection of an attack relies > upon the RP noticing that something has changed at the publication point > wrt the RP's cached copy in a fashion that should not have happened. >=20 > Statements such as "the RPKI calls for RPs to cache" and "RPs are > expected to make use of local caches" strike me as a weak foundation > for the level of security dependence on that caching. A pointer to a > SHOULD or MUST requirement for caching by RPKI RPs in another document > would alleviate this concern; surely that language exists somewhere. >=20 > Nits/editorial comments: >=20 > Also in Section 4.4: >=20 > (The RP would be very unhappy if > there is no CRL for the CA instance anyway.) >=20 > Please rewrite to describe how the RP reacts to failure to find a CRL > - the RP surely does something in addition to becoming "very unhappy" ;-)= . > Some of that may already be in the sentence immediately following the > "very unhappy" text. >=20 > idnits 2.12.17 complains about a missing reference: >=20 > =3D=3D Missing Reference: 'TCPMD5' is mentioned on line 114, but not de= fined >=20 > That citation is embedded in a quote from RFC 4272, nonetheless, [TCPMD5] > should be informatively referenced here - it was RFC 2385, which has been > obsoleted by RFC 5925, which is referenced here. The fact that RFC 2385 > is obsolete will generate a different idnits warning, which is ok to igno= re. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 From alexey.melnikov@isode.com Wed Oct 9 13:20:34 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C369021E8099 for ; Wed, 9 Oct 2013 13:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.732 X-Spam-Level: X-Spam-Status: No, score=-104.732 tagged_above=-999 required=5 tests=[AWL=-2.734, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrRnVMHTfpLO for ; Wed, 9 Oct 2013 13:20:33 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6623211E80FC for ; Wed, 9 Oct 2013 13:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1381350031; d=isode.com; s=selector; i=@isode.com; bh=hPaX4r1yS/9egK9hd1VAxBGG+oAC6g2/0iOPs3OxYvI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=UNVffi/LUN7C/eDjoHCEdUpsoUYp3avfFX9arqZU14EikBqA/P9ShAMfDKT1OrSh95XKef fkOq+m9pIR4gbM+u1jp9vflkYfeXckMogQvEimoOFgWOwjiLsnSqbkpfmiZiH6gdNf8WEm 7JHy6+JLfLyf8Sq97REShaxDIDLgMT8=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginmedia.com [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 9 Oct 2013 21:20:28 +0100 Message-ID: <5255BA8E.4070500@isode.com> Date: Wed, 09 Oct 2013 21:20:30 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: Stephen Kent References: <24B20D14B2CD29478C8D5D6E9CBB29F6749E8EEB@CVA-MB002.centreville.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F674A5C902@CVA-MB001.centreville.ads.sparta.com> <5252D6C1.4090909@bbn.com> In-Reply-To: <5252D6C1.4090909@bbn.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020005060406080604040107" Cc: "Murphy, Sandra" , sidr@ietf.org Subject: Re: [sidr] some comments on draft-ietf-sidr-cps-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 20:20:35 -0000 This is a multi-part message in MIME format. --------------020005060406080604040107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Stephen, On 07/10/2013 16:44, Stephen Kent wrote: > 3.1.2 of 6484 says that the CA SHOULD NOT use meaningful names, which > leaves the CA some leeway.3.1.2 in the CPS draft says "The name of the > subscriber will not be "meaningful" ", which is less flexible.OK, so > this is a template that the CAs can modify, and that language is > helpful to the desired outcome that the subject names are meaningless. > *I've changed it to more closely match 6484.* > > 3.1.3 says > "Although Subject names in certificates issued by this Organization need not be meaningful," > which is inconsistent with 3.1.2. And 3.1.5 says "Because the Subject names are not intended to be meaningful". > So is it "will not be meaningful" or "need not be meaningful"? > *changed to "SHOULD NOT be meaningful." Could make this an erratum for 6484 if we want.* I don't think there is any compliance statement here (how are you going to test for compliance?). So I think you should use "is not meaningful" instead. --------------020005060406080604040107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi Stephen,

On 07/10/2013 16:44, Stephen Kent wrote:

3.1.2 of 6484 says that the CA SHOULD NOT use meaningful names, which leaves the CA some leeway. 3.1.2 in the CPS draft says "The name of the subscriber will not be "meaningful" ", which is less flexible. OK, so this is a template that the CAs can modify, and that language is helpful to the desired outcome that the subject names are meaningless.
I’ve changed it to more closely match 6484.
 
3.1.3 says 
        "Although Subject names in certificates issued by this Organization need not be meaningful," 
which is inconsistent with 3.1.2.  And 3.1.5 says "Because the Subject names are not intended to be meaningful".  
So is it "will not be meaningful" or "need not be meaningful"?
changed to “SHOULD NOT be meaningful.” Could make this an erratum for 6484 if we want.

I don't think there is any compliance statement here (how are you going to test for compliance?). So I think you should use "is not meaningful" instead.

--------------020005060406080604040107-- From wesley.george@twcable.com Wed Oct 9 13:29:48 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5B821E81C2 for ; Wed, 9 Oct 2013 13:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63DikxePYg3m for ; Wed, 9 Oct 2013 13:29:43 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id A626321E81B9 for ; Wed, 9 Oct 2013 13:29:42 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.90,1066,1371096000"; d="scan'208,217";a="147059003" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 09 Oct 2013 16:28:49 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Wed, 9 Oct 2013 16:29:41 -0400 From: "George, Wes" To: Stephen Kent Date: Wed, 9 Oct 2013 16:29:39 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-07.txt Thread-Index: Ac7FAlfB/V9t5ADZTDK5XXz7LOkNCwABze1w Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923043C7FED59@PRVPEXVS15.corp.twcable.com> References: <20131008204114.28645.53351.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043C7556E1@PRVPEXVS15.corp.twcable.com> <52557287.8010205@bbn.com> In-Reply-To: <52557287.8010205@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2671C6CDFBB59E47B64C10B3E0BD5923043C7FED59PRVPEXVS15cor_" MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 20:29:48 -0000 --_000_2671C6CDFBB59E47B64C10B3E0BD5923043C7FED59PRVPEXVS15cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In order to make this thread a bit more readable, I've added [Wes] to my or= iginal comments if I kept them, [SK] to yours, and my new replies are [WEG] From: Stephen Kent [mailto:kent@bbn.com] [SK]The increased sensitivity to nation-level threats is understandable.The= threats doc lists nations as a category of adversary in Section 3; we have= not ignored them. (Can you name any other IETF threat analysis that has do= ne so?) The doc does not discuss attacks by nations against LTAM. The RPKI= , as specified in RFCs 6480-91, is addressed for completeness, and because = the SIDR charter mandates use of the RPKI. LTAM is still an I-D; it is not = part of the RPKI standards. As such, I don't consider it to be in scope for= this doc. More to the point, as lead author of the LTAM doc, I anticipate reducing it= s scope in a way that may remove the concern you raised. However, our new I-D, "Suspenders" may r= aise similar concerns. I think it appropriate to discuss them if and when the WG elects = to adopt that doc as a work item. [WEG] That's a reasonable distinction (discuss only the standards not draft= s) and an acceptable way forward. [Wes]That said, I also think that the discussion of this topic at the end o= f session 5 is inadequate for a document in IETF LC. The SIDR WG made a con= scious decision to secure *only* the AS_Path attribute, and leave other att= ributes insecure, but there is no summary of the underlying rationale suppo= rting this choice. Pointing to a WG charter as the sole explanation, and no= ting that this document should be changed if the charter is updated is unac= ceptable, as it provides no context to a reader that was not privy to the d= iscussion leading to that charter/scope decision. [SK]No one (other than you) suggested that we include a discussion of the h= istory of the charter/scope discussion here. I do not recall seeing such a = discussion in any other threat analysis doc. I don't plan to add such a dis= cussion here. [WEG] I think I was unclear in the way that I raised the concern, and your = response (below) helped me see that, so I'll try to clarify. I don't care w= hether it's a charter/scope issue, and I'm not asking for the summary for t= hat reason. I care about it from the perspective of its relative risk as a = threat, and I made reference to the scope/WG/charter/design discussion beca= use I thought that would inform the discussion of the level of risk (i.e. w= e decided that the risk was not high enough to justify changes to the desig= n to secure additional attributes). [Wes]It also makes reference to something fairly ephemeral (a WG and charte= r) in a permanent document. Fine for a draft in WG discussion to have that = sort of placeholder, but not anymore. [SK]The latest version (-07) of the threats document added a paraphrase of = the relevant charter text to address the concern about referencing a charte= r, an issue raised by David Black in his GENART review. [WEG] I've seen the addition. It's not adequate to address my concern, beca= use the text in section 5 was not changed at all to remove the reference to= charter and "changes to this document at a later time" for both route leak= s and secondary attributes. [Wes]There is a brief (and IMO incomplete) discussion of this matter to be = found in section 2.3 of draft-sriram-bgpsec-design-choices that could be re= ferenced, but since that document's future is unclear, some standalone disc= ussion within this document might be more appropriate. At a minimum, a thre= ats document should discuss why these threats are not considered high enoug= h risk to justify the added complexity of securing them using the RPKI. [SK]A threat analysis, in principle, identifies adversaries, their motivati= ons for carrying out classes of attacks, and their capabilities to do so. I= t need not establish requirements for acceptable designs, or propose counte= rmeasures to address classes of attacks. In this doc we went beyond those e= ssential threat analysis elements, because there was no RPKI threat doc (an= d because the charter calls for use of the RPKI as a basis for BGPSEC). A r= equirements doc is a place where one defines what needs to be done by a sol= ution, to address the threats previously described. [WEG] I'm no connoisseur of threat analyses, so I don't have a large basis = of comparison, but I do think that a threats document should not identify a= residual threat and then hand-wave it away as "out of scope" instead of ex= plaining the relative risk that it might be exploited. It might even perhap= s draw the conclusion that the risk is negligible, but based on your explan= ation, WG charter and scope shouldn't figure into the discussion. Worse yet, as this section is currently written, it's circular logic: paths= ec doesn't protect non-AS_Path attributes, so there's a risk of those attri= butes being manipulated without pathsec detecting it, but that's ok because= pathsec isn't required to protect against those things. Why isn't pathsec = required to protect against those things? Because the charter says it isn't= . Why does the charter say that? Because...reasons? >From a threat analysis perspective, either the ability to manipulate unprot= ected attributes is a threat (a capability for an adversary to carry out an= attack) to BGP Path security, or it's not. I believe the fact that you/the= WG included it in the discussion means that you/the WG believe that it's a= threat. I could infer based on the fact that SIDR chose not to design prot= ections against that exploit that it's a real threat but very low risk, or = extremely difficult to exploit, or whatever, but the document doesn't curre= ntly say anything about the relative level of risk for the threat being ide= ntified. You're right in that the design/requirements decisions that SIDR W= G made about whether to address that threat are mostly irrelevant, but the = fact that you discuss it in terms of design scope makes that confusing if o= ne is to evaluate this text as purely a threats analysis. It goes back to a= recurring issue that has happened with the order of these documents, where= we're writing a threats doc and a requirements doc based on an existing de= sign rather than the other around, and are tailoring these documents based = on the current design to the exclusion of things deemed out of scope instea= d of documenting everything and then deciding some of the specific scope it= ems in the requirements/design phase. Hopefully this clarifies my concern Wes ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_2671C6CDFBB59E47B64C10B3E0BD5923043C7FED59PRVPEXVS15cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In order to make this thread a bit more readable, I’ve added [= Wes] to my original comments if I kept them, [SK] to yours, and my new replies are [WEG]

From: Stephen Kent [mailto:kent@bbn.com]

[SK]The increased sensitivity to nation-level threats is un= derstandable.The threats doc lists nations as a category of adversary in Se= ction 3; we have not ignored them. (Can you name any other IETF threat analysis that has done so?) The doc d= oes not discuss attacks by nations against LTAM. The RPKI, as specified in = RFCs 6480-91, is addressed for completeness, and because the SIDR charter m= andates use of the RPKI. LTAM is still an I-D; it is not part of the RPKI standards. As such, I don't consider it= to be in scope for this doc.

More to the point, as lead author of the LTAM doc, I anticipate reducing it= s scope in a way that
may remove the concern you raised. However, our new I-D, "Suspenders&q= uot; may raise similar
concerns. I think it appropriate to discuss them if and when the WG elects = to adopt that doc
as a work item.

[WEG] That’s a reasonable distinc= tion (discuss only the standards not drafts) and an acceptable way forward.=

[Wes]That said,= I also think that the discussion of this topic at the end of session 5 is = inadequate for a document in IETF LC. The SIDR WG made a conscious decision= to secure *only* the AS_Path attribute, and leave other attributes insecure, but there is no summary of the underl= ying rationale supporting this choice. Pointing to a WG charter as the sole= explanation, and noting that this document should be changed if the charte= r is updated is unacceptable, as it provides no context to a reader that was not privy to the discussion le= ading to that charter/scope decision.

[SK]No one (oth= er than you) suggested that we include a discussion of the history of the c= harter/scope discussion here. I do not recall seeing such a discussion in a= ny other threat analysis doc. I don't plan to add such a discussion here.

[WEG] I think I was unclear in the way that I raised the concern, and =
your response (below) helped me see that, so I’ll try to clarify. I d=
on’t care whether it’s a charter/scope issue, and I’m not=
 asking for the summary for that reason. I care about it from the perspecti=
ve of its relative risk as a threat, and I made reference to the scope/WG/c=
harter/design discussion because I thought that would inform the discussion=
 of the level of risk (i.e. we decided that the risk was not high enough to=
 justify changes to the design to secure additional attributes).

<= /p>

[Wes]It also makes reference to something fairly ephemeral = (a WG and charter) in a permanent document. Fine for a draft in WG discussi= on to have that sort of placeholder, but not anymore.

[SK]The latest = version (-07) of the threats document added a paraphrase of the relevant ch= arter text to address the concern about referencing a charter, an issue rai= sed by David Black in his GENART review.

[WEG] I’ve seen the addition. It&= #8217;s not adequate to address my concern, because the text in section 5 w= as not changed at all to remove the reference to charter and “changes to this document at a later time” for both route leaks and secondary= attributes.

<= /p>

[Wes]There is a= brief (and IMO incomplete) discussion of this matter to be found in sectio= n 2.3 of draft-sriram-bgpsec-design-choices that could be referenced, but s= ince that document's future is unclear, some standalone discussion within this document might be more appropriate.= At a minimum, a threats document should discuss why these threats are not = considered high enough risk to justify the added complexity of securing the= m using the RPKI.

[SK]A threat an= alysis, in principle, identifies adversaries, their motivations for carryin= g out classes of attacks, and their capabilities to do so. It need not esta= blish requirements for acceptable designs, or propose countermeasures to address classes of attacks. In this doc we w= ent beyond those essential threat analysis elements, because there was no R= PKI threat doc (and because the charter calls for use of the RPKI as a basi= s for BGPSEC). A requirements doc is a place where one defines what needs to be done by a solution, to addre= ss the threats previously described.

[WEG] I’m no connoisseur of th=
reat analyses, so I don’t have a large basis of comparison, but I do =
think that a threats document should not identify a residual threat and the=
n hand-wave it away as “out of scope” instead of explaining the=
 relative risk that it might be exploited. It might even perhaps draw the c=
onclusion that the risk is negligible, but based on your explanation, WG ch=
arter and scope shouldn’t figure into the discussion.

Worse yet, as this section is currently wri=
tten, it’s circular logic: pathsec doesn’t protect non-AS_Path =
attributes, so there’s a risk of those attributes being manipulated w=
ithout pathsec detecting it, but that’s ok because pathsec isn’=
t required to protect against those things. Why isn’t pathsec require=
d to protect against those things? Because the charter says it isn’t.=
 Why does the charter say that? Because…reasons?

From a threat analysis perspective, either =
the ability to manipulate unprotected attributes is a threat (a capability =
for an adversary to carry out an attack) to BGP Path security, or it’=
s not. I believe the fact that you/the WG included it in the discussion mea=
ns that you/the WG believe that it’s a threat. I could infer based on=
 the fact that SIDR chose not to design protections against that exploit th=
at it’s a real threat but very low risk, or extremely difficult to ex=
ploit, or whatever, but the document doesn’t currently say anything a=
bout the relative level of risk for the threat being identified. You’=
re right in that the design/requirements decisions that SIDR WG made about =
whether to address that threat are mostly irrelevant, but the fact that you=
 discuss it in terms of design scope makes that confusing if one is to eval=
uate this text as purely a threats analysis. It goes back to a recurring is=
sue that has happened with the order of these documents, where we’re =
writing a threats doc and a requirements doc based on an existing design ra=
ther than the other around, and are tailoring these documents based on the =
current design to the exclusion of things deemed out of scope instead of do=
cumenting everything and then deciding some of the specific scope items in =
the requirements/design phase.

Hopefully this clarifies my concern

Wes=

This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
--_000_2671C6CDFBB59E47B64C10B3E0BD5923043C7FED59PRVPEXVS15cor_-- From kent@bbn.com Wed Oct 9 13:39:21 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4DD21F9B0E for ; Wed, 9 Oct 2013 13:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.017 X-Spam-Level: X-Spam-Status: No, score=-106.017 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glVgpS5lqcDB for ; Wed, 9 Oct 2013 13:39:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7117621F99E8 for ; Wed, 9 Oct 2013 13:39:15 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:51968) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VU0XJ-000DJW-6K; Wed, 09 Oct 2013 16:39:13 -0400 Message-ID: <5255BEF1.4080605@bbn.com> Date: Wed, 09 Oct 2013 16:39:13 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Alexey Melnikov References: <24B20D14B2CD29478C8D5D6E9CBB29F6749E8EEB@CVA-MB002.centreville.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F674A5C902@CVA-MB001.centreville.ads.sparta.com> <5252D6C1.4090909@bbn.com> <5255BA8E.4070500@isode.com> In-Reply-To: <5255BA8E.4070500@isode.com> Content-Type: multipart/alternative; boundary="------------080105020301010406060803" Cc: "Murphy, Sandra" , sidr@ietf.org Subject: Re: [sidr] some comments on draft-ietf-sidr-cps-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 20:39:21 -0000 This is a multi-part message in MIME format. --------------080105020301010406060803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Alexey, > Hi Stephen, > > On 07/10/2013 16:44, Stephen Kent wrote: >> 3.1.2 of 6484 says that the CA SHOULD NOT use meaningful names, which >> leaves the CA some leeway.3.1.2 in the CPS draft says "The name of >> the subscriber will not be "meaningful" ", which is less flexible.OK, >> so this is a template that the CAs can modify, and that language is >> helpful to the desired outcome that the subject names are meaningless. >> *I've changed it to more closely match 6484.* >> >> 3.1.3 says >> "Although Subject names in certificates issued by this Organization need not be meaningful," >> which is inconsistent with 3.1.2. And 3.1.5 says "Because the Subject names are not intended to be meaningful". >> So is it "will not be meaningful" or "need not be meaningful"? >> *changed to "SHOULD NOT be meaningful." Could make this an erratum for 6484 if we want.* > I don't think there is any compliance statement here (how are you > going to test for compliance?). So I think you should use "is not > meaningful" instead. > Good point. It would be easy to find examples that clearly violated this direction, but there could be a lot of "gray" area cases! Steve --------------080105020301010406060803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Alexey,

Hi Stephen,

On 07/10/2013 16:44, Stephen Kent wrote:
3.1.2 of 6484 says that the CA SHOULD NOT use meaningful names, which leaves the CA some leeway. 3.1.2 in the CPS draft says "The name of the subscriber will not be "meaningful" ", which is less flexible. OK, so this is a template that the CAs can modify, and that language is helpful to the desired outcome that the subject names are meaningless.
I’ve changed it to more closely match 6484.
 
3.1.3 says 
        "Although Subject names in certificates issued by this Organization need not be meaningful," 
which is inconsistent with 3.1.2.  And 3.1.5 says "Because the Subject names are not intended to be meaningful".  
So is it "will not be meaningful" or "need not be meaningful"?
changed to “SHOULD NOT be meaningful.” Could make this an erratum for 6484 if we want.
I don't think there is any compliance statement here (how are you going to test for compliance?). So I think you should use "is not meaningful" instead.

Good point. It would be easy to find examples that clearly violated this direction, but there
could be a lot of "gray" area cases!

Steve
--------------080105020301010406060803-- From kent@bbn.com Thu Oct 10 07:49:27 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67AA21E808E for ; Thu, 10 Oct 2013 07:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.315 X-Spam-Level: X-Spam-Status: No, score=-106.315 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWouyE-kMisY for ; Thu, 10 Oct 2013 07:49:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 390A421E805D for ; Thu, 10 Oct 2013 07:49:21 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:52053) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VUHYG-000Ot2-Bx for sidr@ietf.org; Thu, 10 Oct 2013 10:49:20 -0400 Message-ID: <5256BE70.1030204@bbn.com> Date: Thu, 10 Oct 2013 10:49:20 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sidr References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/mixed; boundary="------------020509040403000508040006" Subject: [sidr] FYI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 14:49:27 -0000 This is a multi-part message in MIME format. --------------020509040403000508040006 Content-Type: multipart/alternative; boundary="------------020609070603080508010006" --------------020609070603080508010006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: [ISA] [ncc-announce] [news] Expansion of eligible address space for Resource Certification (RPKI) Date: Thu, 10 Oct 2013 14:35:13 +0200 From: Alex Band To: ncc-announce@ripe.net Dear colleagues, When the Resource Certification (RPKI) service was launched in 2011, only address space allocated to the RIPE NCC directly by IANA was eligible for certification. Today, we are happy to announce that all address space that was historically transferred to the RIPE NCC from other Regional Internet Registries (RIRs) is also eligible. These ranges are so called "minority" address space, meaning that the full /8 block is managed by one of the four other RIRs, but a subset is managed by the RIPE NCC. LIRs who hold address space in these minority ranges will automatically have those resources added to their certificate, if they already have one. Starting today, they can create Route Origin Authorisations (ROAs) for the BGP announcements that they make with these prefixes. Resource Certification (RPKI) is a free service offered by all RIRs to offer BGP Origin Validation. It allows operators to request a digital certificate containing their Internet number resources and make cryptographically verifiable statements about their intended BGP announcements. These ROAs allow other network operators to make reliable routing decisions. In the RIPE NCC service region, more than 1,600 LIRs have requested a resource certificate and created ROAs for over six /8s worth of address space. To read more about this service, please visit: http://ripe.net/certification If you have any questions, please do not hesitate to contact us at > Kind regards, Alex Band Product Manager RIPE NCC --------------020609070603080508010006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

-------- Original Message --------

Subject:	[ISA] [ncc-announce] [news] Expansion of eligible address space for Resource Certification (RPKI)
Date:	Thu, 10 Oct 2013 14:35:13 +0200
From:	Alex Band <alexb@ripe.net>
To:	ncc-announce@ripe.net <ncc-announce@ripe.net>

Dear colleagues,

When the Resource Certification (RPKI) service was launched in 2011, only address space allocated to the RIPE NCC directly by IANA was eligible for certification. Today, we are happy to announce that all address space that was historically transferred to the RIPE NCC from other Regional Internet Registries (RIRs) is also eligible.

These ranges are so called "minority" address space, meaning that the full /8 block is managed by one of the four other RIRs, but a subset is managed by the RIPE NCC. LIRs who hold address space in these minority ranges will automatically have those resources added to their certificate, if they already have one. Starting today, they can create Route Origin Authorisations (ROAs) for the BGP announcements that they make with these prefixes.

Resource Certification (RPKI) is a free service offered by all RIRs to offer BGP Origin Validation. It allows operators to request a digital certificate containing their Internet number resources and make cryptographically verifiable statements about their intended BGP announcements. These ROAs allow other network operators to make reliable routing decisions. In the RIPE NCC service region, more than 1,600 LIRs have requested a resource certificate and created ROAs for over six /8s worth of address space.

To read more about this service, please visit:
http://ripe.net/certification

If you have any questions, please do not hesitate to contact us at <certification@ripe.net>

Kind regards,

Alex Band

Product Manager

RIPE NCC

--------------020609070603080508010006-- --------------020509040403000508040006 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ ISA mailing list ISA@bbn.com http://lists.bbn.com/mailman/listinfo/isa --------------020509040403000508040006-- From kent@bbn.com Thu Oct 10 08:33:31 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1332811E819F for ; Thu, 10 Oct 2013 08:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.341 X-Spam-Level: X-Spam-Status: No, score=-106.341 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aTAvPxj7xJu for ; Thu, 10 Oct 2013 08:33:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id AACF521F9C05 for ; Thu, 10 Oct 2013 08:33:24 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:52061) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VUIEs-000Ip6-Tf; Thu, 10 Oct 2013 11:33:23 -0400 Message-ID: <5256C8C2.60902@bbn.com> Date: Thu, 10 Oct 2013 11:33:22 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "George, Wes" , sidr References: <20131008204114.28645.53351.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043C7556E1@PRVPEXVS15.corp.twcable.com> <52557287.8010205@bbn.com> <2671C6CDFBB59E47B64C10B3E0BD5923043C7FED59@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923043C7FED59@PRVPEXVS15.corp.twcable.com> Content-Type: multipart/alternative; boundary="------------060807030909050103060802" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 15:33:31 -0000 This is a multi-part message in MIME format. --------------060807030909050103060802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Wes, I had to extract you reply and paste it into Word to read, because the lines you wrote were not properly wrapped by my e-mail reader. As a result, my reply adopts a slightly different format. OK, we agree that LTAM is out of scope for now. Your later comments are included below, along with my responses.: */[WEG] /*I think I was unclear in the way that I raised the concern, and your response (below) helped me see that, so I'll try to clarify. I don't care whether it's a charter/scope issue, and I'm not asking for the summary for that reason. I care about it from the perspective of its relative risk as a threat, and I made reference to the scope/WG/charter/design discussion because I thought that would inform the discussion of the level of risk (i.e. we decided that the risk was not high enough to justify changes to the design to secure additional attributes). I better understand your comment. Your concern appears to be that a reader of this doc will assume that we decided to not consider the security of other path attributes because they are less important than AS_Path. However, by stating that securing these other attributes is deemed out of scope, based on the charter, I think we make it clear that we have _not_ made a value judgement about the relative importance of them. */[WEG] /*I've seen the addition. It's not adequate to address my concern, because the text in section 5 was not changed at all to remove the reference to charter and "changes to this document at a later time" for both route leaks and secondary attributes. I don't see why you believe that references to the charter, augmented by the salient text from the charter, are not appropriate here; that's the reason these topics are not addressed. I also think the note about updating the threat doc, if and when the charter is changed to include these concerns, is appropriate. It tells the reader that these topics may be addressed in the future. */[WEG]/*I'm no connoisseur of threat analyses, so I don't have a large basis of comparison, but I do think that a threats document should not identify a residual threat and then hand-wave it away as "out of scope" instead of explaining the relative risk that it might be exploited. It might even perhaps draw the conclusion that the risk is negligible, but based on your explanation, WG charter and scope shouldn't figure into the discussion.Worse yet, as this section is currently written, it's circular logic: pathsec doesn't protect non-AS_Path attributes, so there's a risk of those attributes being manipulated without pathsec detecting it, but that's ok because pathsec isn't required to protect against those things. Why isn't pathsec required to protect against those things? Because the charter says it isn't. Why does the charter say that? Because...reasons? We fundamentally disagree on this point. A threat doc is always constrained by some set of contextual assumptions. Stating that we are aware of some concerns that are not addressed, and that they may be addressed in the future is a reasonable way to convey to the reader what some of the contextual constraints are. Your characterization of the discussion as "circular reasoning" is faulty. What the text says is that path security is the focus of the WG, and thus is a constraint adopted by this threat analysis, period. >From a threat analysis perspective, either the ability to manipulate unprotected attributes is a threat (a capability for an adversary to carry out an attack) to BGP Path security, or it's not. I believe the fact that you/the WG included it in the discussion means that you/the WG believe that it's a threat. I could infer based on the fact that SIDR chose not to design protections against that exploit that it's a real threat but very low risk, or extremely difficult to exploit, or whatever, but the document doesn't currently say anything about the relative level of risk for the threat being identified. You're right in that the design/requirements decisions that SIDR WG made about whether to address that threat are mostly irrelevant, but the fact that you discuss it in terms of design scope makes that confusing if one is to evaluate this text as purely a threats analysis. It goes back to a recurring issue that has happened with the order of these documents, where we're writing a threats doc and a requirements doc based on an existing design rather than the other around, and are tailoring these documents based on the current design to the exclusion of things deemed out of scope instead of documenting everything and then deciding some of the specific scope items in the requirements/design phase. As noted above, every threat analysis takes place in a context, else it could never be complete. We have a context defined by the WG charter, and I have chosen to use that context to constrain what the analysis covers. We cannot "document everything" any more than a scientist can "gather all the data and they form a hypothesis." Your criticisms about the order of doc preparation suggest a deeper discontent with the WG process. I suggest you talk with the WG chairs and the cognizant AD about that, rather than taking it out in this doc. Steve p.s. in the later parts of your comments you repeatedly use the term "threat" when you mean "attack" or maybe "vulnerability" or ... --------------060807030909050103060802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Wes,

I had to extract you reply and paste it into Word to read, because the lines you wrote
were not properly wrapped by my e-mail reader. As a result, my reply adopts a slightly different
format.

OK, we agree that LTAM is out of scope for now.

Your later comments are included below, along with my responses.:

[WEG] I think I was unclear in the way that I raised the concern, and your response (below) helped me see that, so I’ll try to clarify. I don’t care whether it’s a charter/scope issue, and I’m not asking for the summary for that reason. I care about it from the perspective of its relative risk as a threat, and I made reference to the scope/WG/charter/design discussion because I thought that would inform the discussion of the level of risk (i.e. we decided that the risk was not high enough to justify changes to the design to secure additional attributes).

I better understand your comment. Your concern appears to be that a reader of this doc will assume that we decided to not consider the security of other path attributes because they are less important than AS_Path. However, by stating that securing these other attributes is deemed out of scope, based on the charter, I think we make it clear that we have not made a value judgement about the relative importance of them.

[WEG] I’ve seen the addition. It’s not adequate to address my concern, because the text in section 5 was not changed at all to remove the reference to charter and “changes to this document at a later time” for both route leaks and secondary attributes.

I don't see why you believe that references to the charter, augmented by the salient text from the charter, are not appropriate here; that's the reason these topics are not addressed. I also think
the note about updating the threat doc, if and when the charter is changed to include these concerns,
is appropriate. It tells the reader that these topics may be addressed in the future.

[WEG] I’m no connoisseur of threat analyses, so I don’t have a large basis of comparison, but I do think that a threats document should not identify a residual threat and then hand-wave it away as “out of scope” instead of explaining the relative risk that it might be exploited. It might even perhaps draw the conclusion that the risk is negligible, but based on your explanation, WG charter and scope shouldn’t figure into the discussion. Worse yet, as this section is currently written, it’s circular logic: pathsec doesn’t protect non-AS_Path attributes, so there’s a risk of those attributes being manipulated without pathsec detecting it, but that’s ok because pathsec isn’t required to protect against those things. Why isn’t pathsec required to protect against those things? Because the charter says it isn’t. Why does the charter say that? Because…reasons?

We fundamentally disagree on this point. A threat doc is always constrained by some set of contextual
assumptions. Stating that we are aware of some concerns that are not addressed, and that they may be
addressed in the future is a reasonable way to convey to the reader what some of the contextual
constraints are. Your characterization of the discussion as "circular reasoning" is faulty. What
the text says is that path security is the focus of the WG, and thus is a constraint adopted by
this threat analysis, period.

From a threat analysis perspective, either the ability to manipulate unprotected attributes is a threat (a capability for an adversary to carry out an attack) to BGP Path security, or it’s not. I believe the fact that you/the WG included it in the discussion means that you/the WG believe that it’s a threat. I could infer based on the fact that SIDR chose not to design protections against that exploit that it’s a real threat but very low risk, or extremely difficult to exploit, or whatever, but the document doesn’t currently say anything about the relative level of risk for the threat being identified. You’re right in that the design/requirements decisions that SIDR WG made about whether to address that threat are mostly irrelevant, but the fact that you discuss it in terms of design scope makes that confusing if one is to evaluate this text as purely a threats analysis. It goes back to a recurring issue that has happened with the order of these documents, where we’re writing a threats doc and a requirements doc based on an existing design rather than the other around, and are tailoring these documents based on the current design to the exclusion of things deemed out of scope instead of documenting everything and then deciding some of the specific scope items in the requirements/design phase.

As noted above, every threat analysis takes place in a context, else it could never be complete. We have a
context defined by the WG charter, and I have chosen to use that context to constrain what the analysis covers. We cannot "document everything" any more than a scientist can "gather all the data and they form a hypothesis." Your criticisms about the order of doc preparation suggest a deeper discontent with the
WG process. I suggest you talk with the WG chairs and the cognizant AD about that, rather than taking
it out in this doc.

Steve

p.s. in the later parts of your comments you repeatedly use the term "threat" when you mean "attack" or maybe "vulnerability" or ...
--------------060807030909050103060802-- From prvs=3996b8285d=sandra.murphy@parsons.com Fri Oct 11 11:50:34 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA34111E8196 for ; Fri, 11 Oct 2013 11:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yX+9azoVmu5 for ; Fri, 11 Oct 2013 11:50:21 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 0019911E818B for ; Fri, 11 Oct 2013 11:50:20 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r9BIjTv3023994 for ; Fri, 11 Oct 2013 13:50:16 -0500 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1fenm3rg6j-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 11 Oct 2013 13:50:16 -0500 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r9BIoFqL016959 for ; Fri, 11 Oct 2013 13:50:15 -0500 Received: from CVA-CAS001.centreville.ads.sparta.com ([10.62.108.10]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r9BIo9v0004005 for ; Fri, 11 Oct 2013 13:50:10 -0500 Received: from CVA-MB002.centreville.ads.sparta.com ([fe80::6046:a82a:c500:c9ad]) by CVA-CAS001.centreville.ads.sparta.com ([fe80::8c45:43da:e59:604a%11]) with mapi id 14.02.0342.003; Fri, 11 Oct 2013 14:50:09 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: comments on draft-ietf-sidr-bgpsec-rollover Thread-Index: Ac7GsrUpoxKX3FduTRCYETgAmp9dFQ== Date: Fri, 11 Oct 2013 18:50:08 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F677CED309@CVA-MB002.centreville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-11_07:2013-10-11, 2013-10-11, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=166.008 compositescore=0.0502615222663303 urlsuspect_oldscore=0.502615222663302 suspectscore=0 recipient_domain_to_sender_totalscore=2672 phishscore=0 bulkscore=0 kscore.is_spamscore=0.00301820956030907 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=10063 rbsscore=0.0502615222663303 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1310110081 Subject: [sidr] comments on draft-ietf-sidr-bgpsec-rollover X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 18:50:34 -0000 Speaking as regular ol' member=0A= =0A= Some comments on the rollover draft.=0A= =0A= The title says "an alternative to beaconing" - the protocol doc no longer t= alks about beaconing, so this is an alternative to a behavior that no longe= r exists.=0A= =0A= I am not certain about the scope of this rollover discussion. The draft in= tro says the scope is changing the key pair and talks the need to reissue u= pdates because old signatures will be invalid. But section 3 also says th= e rollover process includes cases where you "generate a new certificate wit= hout changing the key pair". And the end of 3.1 says "When a new BGPSEC ce= rtificate is generated without changing its key"=0A= =0A= Section 2 mentions control of the replay window as a primary motivation. B= ut Section 3 does not list that as one of the causes.=0A= =0A= Section 3.1 mentions that the details of pre-publishing a new cert will var= y with circumstances. Should the possible differences be mentioned? For e= xample, one mentioned circumstance is whether the repository is "locally or= externally hosted" - I'm not sure what differences that particular circums= tance would make. I presume the difference is control of timing, but I'm n= ot sure.=0A= =0A= Section 3.1 - "in which case routing information may be lost" - why? (I fi= gure I know why, but I'm not so sure I'm thinking what the authors are thin= king.)=0A= =0A= "typical operation of refreshing out-bound BGP policies" - you mean typical= as is currently possible in current routers, right?=0A= =0A= "probably in the order of minutes to avoid reaching any expiration time" - = are the authors presuming a order of magnitude for cert expiration times?= =0A= =0A= Are steps 1-5 intended to be sequential? I would expect, but later text ta= kes care to point out that steps 1-2 "could happen ahead of time", which ra= ises the question of timing of the process.=0A= =0A= Step 2 is not deterministic - there's a good enough staging time but no way= to choose a certain maximum staging time. If step 3 reaches a router that= has the new key but has not yet been informed that the old key is no longe= r valid, then the new update will implicitly withdraw the old update. (Rig= ht?) If the new key has not reached a router, it will not be able to valid= ate the new update and will (likely?) not propagate the new update. Any th= oughts of what that will mean to overall bgp behavior?=0A= =0A= Section 4 refers to beaconing - which is no longer part of the protocol. "= Currently BGPSEC offers a timestamp (expiration time)" - not in the current= protocol spec that I could see. Can you be more specific?=0A= =0A= section 4.2 maybe should list the convergence churn resulting for a new key= .=0A= =0A= section 4.2 says:=0A= =0A= this reason, it is recommended that routers in this scenario been=0A= provisioned with two certificates: one to sign BGP UPDATES in transit=0A= and a second one to sign BGP UPDATE for prefixes originated in its=0A= AS. =0A= =0A= This was a strategy suggested by Sriram, IIRC. We should be sure that the = protocol draft supports this strategy. (Is this the right draft to make th= is keying suggestion?)=0A= =0A= --Sandy, speaking as regular ol' member=0A= From prvs=3999723afc=sandra.murphy@parsons.com Mon Oct 14 09:11:14 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373C121E80D0 for ; Mon, 14 Oct 2013 09:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfZpORIf+YrK for ; Mon, 14 Oct 2013 09:11:09 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB5621E80EA for ; Mon, 14 Oct 2013 09:11:06 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r9EG5T7x022982 for ; Mon, 14 Oct 2013 11:10:57 -0500 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1fga48kamr-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 14 Oct 2013 11:10:57 -0500 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r9EGAuaT026615 for ; Mon, 14 Oct 2013 11:10:56 -0500 Received: from CVA-CAS002.centreville.ads.sparta.com ([10.62.108.28]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r9EGAt5k021542 for ; Mon, 14 Oct 2013 11:10:56 -0500 Received: from CVA-MB001.centreville.ads.sparta.com ([fe80::58b4:c7c2:f9d:dff9]) by CVA-CAS002.centreville.ads.sparta.com ([fe80::bb:e18b:b460:f4b2%11]) with mapi id 14.02.0342.003; Mon, 14 Oct 2013 12:10:55 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: final agenda posted for IETF88 Thread-Index: Ac7I3zj8G6PMlgTFScOQWOls3BgFUg== Date: Mon, 14 Oct 2013 16:10:55 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F677CF3E50@CVA-MB001.centreville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-14_02:2013-10-11, 2013-10-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=110.568 compositescore=0.0527339388916443 urlsuspect_oldscore=0.527339388916442 suspectscore=0 recipient_domain_to_sender_totalscore=1469 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=7945 rbsscore=0.0527339388916443 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1310140069 Subject: [sidr] final agenda posted for IETF88 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 16:11:14 -0000 The final agenda for IETF88 has been posted.=0A= =0A= Here's the link.=0A= =0A= https://datatracker.ietf.org/meeting/88/agenda.html=0A= =0A= --Sandy= From rogaglia@cisco.com Mon Oct 14 12:41:20 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCAD21F9D0A for ; Mon, 14 Oct 2013 12:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TN0LCEQCA+oI for ; Mon, 14 Oct 2013 12:41:15 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BAC7821E80DC for ; Mon, 14 Oct 2013 12:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29115; q=dns/txt; s=iport; t=1381779674; x=1382989274; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=pXHECCK8iGCnkUT+kxH94PNeGQmZZcYxL6/SJEciP7Y=; b=etVSy92qnQqWNJC77eQD3SftkO5WsgbrPdAQF5sW/Om7z3f5CvIegkAM MzMsGxK3ofljIe2QbtbR++w0dk5/q+a+Iq+H3Yx3Bm08tE+/KmtHDGIWk rxXcUcoFobNXjv0NqE9nqZ0yQqq38zXyXD0Ym5TRFYowWhxabJp3yjHLO c=; X-Files: smime.p7s : 4459 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0GAOdHXFKtJXHA/2dsb2JhbABZgkNEOFK5MohJgSgWdIIlAQEBAwEBAQFoAxALAgEIIiQCJQslAgQTCAaHcgYMvWCOCIEYOIMfgQQDkCuBMIILQoUMkFOBZoE+gWkHFwYc X-IronPort-AV: E=Sophos;i="4.93,493,1378857600"; d="p7s'?scan'208,217";a="272079336" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 14 Oct 2013 19:41:13 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9EJfCB8016612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 14 Oct 2013 19:41:12 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.78]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Mon, 14 Oct 2013 14:41:12 -0500 From: "Roque Gagliano (rogaglia)" To: sidr wg list Thread-Topic: [sidr] possible interim meeting for draft-ietf-sidr-multiple-publication-points Thread-Index: AQHOyRVWmjATdmM0/EmnH3tQ52L7YA== Date: Mon, 14 Oct 2013 19:41:12 +0000 Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F677CEB6AB@CVA-MB002.centreville.ads.sparta.com>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.103] Content-Type: multipart/signed; boundary="Apple-Mail=_26379D5D-E6C6-49F5-9976-520E1003AF62"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: Re: [sidr] possible interim meeting for draft-ietf-sidr-multiple-publication-points X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 19:41:20 -0000 --Apple-Mail=_26379D5D-E6C6-49F5-9976-520E1003AF62 Content-Type: multipart/alternative; boundary="Apple-Mail=_82380AC9-9364-4E16-98E1-10F8BEB1201C" --Apple-Mail=_82380AC9-9364-4E16-98E1-10F8BEB1201C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear Working Group: The co-authors of the multi-publication points document would like to = propose a new course of action to the WG referring to this document.=20 Since its initial submission, the document addresses two problems = related to the support of multiple operators in RPKI:=20 i)- Multiple Operators support in TAL files (Section 3 of = current document) ii)- Multiple Operators support in Certificates (Section 4 of = current document) Today, we believe that the two problems are very different. On one side = point i) could be quickly solved by the WG by updating or obsoleting RFC = 6490 with the changes proposed in Section 3 of the document. We have = shown in Berlin that changes to RPs should be very small and that "some" = (and I say so because in some cases it was accidental) backward = compatibility exists with most popular RPs. However the second point ii) while it does not require changes to = existing standard document but rather a "BCP" document, it does require = much more research. While we go down to the RPKI hierarchy, we need to = understand how multiple operators may create transient states and how = RPs will typically react to these. Some of the questions to answer were = raised at the meeting and recently in the WG mailing list. Our proposal to the group is to split the current content in the = document in two documents: =20 - A "6490-bis" document that obsoletes RFC 6490 with the = addition of multiple operators in section 3 of the current document. - A new BCP/Informational document on best practices when RPKI = certificates include multiple repository operators for the same = materials. We look forward to hearing from you, Regards, Roque + Carlos + Terry On Oct 2, 2013, at 9:58 AM, Roque Gagliano (rogaglia) = wrote: > Thanks Sharon for your email and analysis. These points are some of = the points raised during our last meeting. >=20 > I personally believe that the non-TAL work requires more research = activity and I guess from your email that you have an interest in this = area :-). >=20 > Regards, > Roque >=20 >> Hi Roque, >>=20 >> As you work on this, I wanted share some observations made by my = colleague here at BU, Ethan Heilman. He read the draft in detail and had = a two suggestions and one question, see below. >>=20 >> Sharon >> =20 >> Suggestion 1: >> =20 >> Section 4.1 of the draft says: =93If the connection to the preferred = URI fails, the RP SHOULD fetch the repository objects from the next URI = of preference." >> =20 >> We suggest that the failover logic be extended to include validation = failures as well as connection failures (similar to the logic for TALs). = That is, when RPKI-validation generates a warning, an RP should fail = over to another publication point. These warnings could be generated by = stale manifests, manifest errors (http://tools.ietf.org/html/rfc6486), = expired certs, missing ROAs, and other validation failures. We call this = failover mode FO-Corrupt (Failover On Corruption) as opposed to the = current failover mode FO-Connect (Failover On Connection failure) in the = draft. Here=92s why we suggest FO-Corrupt: >> =20 >> 1) Multiple publication points using the FO-Connect policy = increase the attack surface, while multiple publication points using the = FO-Corrupt policy decrease the attack surface. With FO-Connect, = corruption failures in a given publication point will directly affect = RPs that select that publication point. Meanwhile, under FO-Corrupt, a = corruption failure must occur on all publication points before it = affects RPs; each additional publication point adds an additional = barrier to an attacker that seeks to corrupt objects. This also allows = operators to raise the cost of an attack by adding publication points = using diverse software and operating systems. Importantly, missing or = corrupted RPKI objects can cause routes to become classified as invalid, = and therefore be less preferred -- I provide examples of this happening = in the attached PDF =96 so if some of the publication points contain = uncorrupted objects, it=92s important to ensure that RP=92s fetch them. >> =20 >> 2) The differences in behavior between TAL failover and RPKI = object failover could cause confusion. FO-Corrupt would provide a = more consistent policy. Compare the quote from Section 4.1 above with = the following from Section 3.2: =93If the connection to the = preferred URI fails or the fetched certificate public key does not match = the TAL public key, the RP SHOULD fetch the TA certificate from the next = URI of preference.=94 >> =20 >> Suggestion 2: >> =20 >> Section 3.2 and 4.1 of the draft suggest three rules to select the = URI of the publication point: >> (1). Provided order, "the order provided in the correspondent = certificate" ---- my reading is that this would be consistent across = all RPs. >> (2). Random order (selecting randomly from the available list) >> (3). RP prioritized order, "a prioritized list of URIs based on RP = specific parameters such as connection establishment delay", this may or = may not be consistent across some subset of RPs.=20 >> =20 >> We see the value of giving RP=92s the flexibility to choosing = publications points based on their own concerns (delay, jurisdiction, = etc.). But rule (3) seems problematic because it could be exploited by = attackers to predict the order which an RP would fail over from one = publication point to the next. For example: >> i. An attacker could target the first publication = point of the list to distribute bad or missing objects, causing all RPs = to get bad information. >> ii. An attacker who happened to compromise a = publication point that was not the first element of the list, could e.g. = DOS publication points at the top of the list to ensure that RPs would = use the attacker=92s publication point. =20 >> iii. An attacker which could predict the fail over = order could perform a rolling DOS attack attacking the first element, = then the second and so on. >> =20 >> Question:=20 >> =20 >> Finally, there has been lots of work on fault-tolerant distributed = database systems that allow RPs to resolve inconsistencies between = replicas of a database. We=92re not experts on these systems, but given = that RPs will download RPKI data relatively infrequently, is this = something that could be considered here? >> >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_82380AC9-9364-4E16-98E1-10F8BEB1201C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Dear Working Group:

The = co-authors of the multi-publication points document would like to = propose a new course of action to the WG referring to this = document.

Since its initial submission, = the document addresses two problems related to the support of multiple = operators in RPKI:

i)- Multiple Operators = support in TAL files (Section 3 of current = document)

ii)- Multiple Operators support in Certificates = (Section 4 of current document)

Today, we = believe that the two problems are very different. On one side = point i) could be quickly solved by the WG by updating or obsoleting RFC = 6490 with the changes proposed in Section 3 of the document. We have = shown in Berlin that changes to RPs should be very small and that "some" = (and I say so because in some cases it was accidental) backward = compatibility exists with most popular = RPs.

However the second point ii) while it does = not require changes to existing standard document but rather a "BCP" = document, it does require much more research. While we go down to the = RPKI hierarchy, we need to understand how multiple operators may create = transient states and how RPs will typically react to these. Some of the = questions to answer were raised at the meeting and recently in the WG = mailing list.

Our proposal to the group is to = split the current content in the document in two documents: =

- A "6490-bis" document that obsoletes RFC 6490 = with the addition of multiple operators in section 3 of the current = document.

- A new BCP/Informational document on best practices when = RPKI certificates include multiple repository operators for the same = materials.

We look forward to hearing from = you,

Regards,

Roque + Carlos + = Terry

On Oct 2, 2013, at = 9:58 AM, Roque Gagliano (rogaglia) <rogaglia@cisco.com> = wrote:

Hi Roque,

As you work on this, I wanted share some = observations made by my colleague here at BU, Ethan Heilman. He read the = draft in detail and had a two suggestions and one question, see = below.

Sharon

Suggestion 1:

Section = 4.1 of the draft says: =93If the = connection to the preferred URI fails, the RP SHOULD fetch the repository objects from the next URI of preference." =

We suggest that the = failover logic be extended to include validation failures as well = as connection failures (similar to the logic for TALs). That is, when RPKI-validation generates a warning, an = RP should fail over to another publication point. These warnings could be = generated by stale manifests, manifest errors (http://tools.ietf.org/html/rfc6486), expired certs, missing ROAs, and other validation failures. We call this = failover mode FO-Corrupt (Failover On Corruption) as opposed to the current failover = mode FO-Connect (Failover On Connection failure) in the draft. = Here=92s why we suggest = FO-Corrupt:

1)   &= nbsp; Multiple publication points using the FO-Connect policy = increase the attack surface, while multiple publication points using the FO-Corrupt = policy decrease the attack surface. With FO-Connect, corruption failures in a given publication point will = directly affect RPs that select that publication point. Meanwhile, under FO-Corrupt, a corruption failure must occur on = all publication points before it affects RPs; each additional publication point adds an additional = barrier to an attacker that seeks to corrupt objects. This also allows operators to = raise the cost of an attack by adding publication points using diverse software = and operating systems. Importantly, missing or corrupted RPKI objects can cause routes to become classified as = invalid, and therefore be less preferred -- I provide examples of this happening in = the attached PDF =96 so if some of the publication points contain = uncorrupted objects, it=92s important to ensure that RP=92s fetch = them.
=

2)   &= nbsp; The differences in behavior between TAL = failover and RPKI object failover could cause confusion. =   FO-Corrupt would provide a more = consistent policy. Compare the quote from = Section 4.1 above with the following from Section 3.2: =          = =93If the connection to the = preferred URI fails or the fetched certificate public key does not match the TAL public key, = the RP SHOULD fetch the TA certificate from the next URI of = preference.=94

Suggestion 2:

Section 3.2 and = 4.1 of the draft suggest three rules to select the URI of the publication point:
(1). Provided order, "the order provided in the correspondent certificate" ---- my reading is that this would be = consistent across all RPs.

(2). Random order = (selecting randomly from the available = list)
=
(3). RP = prioritized order, "a prioritized list of URIs based on RP specific parameters such as connection establishment delay", this may or may not be consistent across some subset = of RPs.

We see the value = of giving RP=92s the flexibility to choosing publications points based on their own concerns (delay, jurisdiction, = etc.). But rule (3) seems problematic because it could be exploited by attackers to predict the order which an RP would fail over from one publication point to the next. For = example:

i.   &= nbsp;           &nb= sp;    An attacker could target the first publication point of the list to distribute bad or missing objects, = causing all RPs to get bad information.

ii.   &= nbsp;           &nb= sp; An attacker who happened to compromise a publication point that was not the first element of the = list, could e.g. DOS publication points at the top of the list to ensure that = RPs would use the attacker=92s publication point. =

iii.   &= nbsp;            An attacker which could predict the fail over order could perform a rolling DOS attack attacking the = first element, then the second and so on.

Question: =

Finally, there has = been lots of work on fault-tolerant distributed database systems that allow RPs to resolve inconsistencies between = replicas of a database. We=92re not experts on these systems, but given that RPs will download RPKI data relatively = infrequently, is this something that could be considered here? =

= <examples.pdf>

References: <2671C6CDFBB59E47B64C10B3E0BD5923043D13BD22@PRVPEXVS15.corp.twcable.com> <525F0036.5000200@bbn.com> In-Reply-To: <525F0036.5000200@bbn.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: sidr Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 16:17:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote on 10/16/13 11:08 PM: >> It goes back to a recurring issue that has happened with the >> order of these documents, where we’re writing a threats doc and a >> requirements doc based on an existing design rather than the >> other around, and are tailoring these documents based on the >> current design to the exclusion of things deemed out of scope >> instead of documenting everything and then deciding some of the >> specific scope items in the requirements/design phase. > This seems to be the telling issue. You seem to be unhappy with > the scope of the WG charter, and refuse to accept it as bounding > for the work that is being performed. Your earlier comment refers > to the charter as "arbitrary" suggesting an unwillingness to accept > a charter as a a way to bound the scope of a WG. I think formally you are absolutely right, Steve. The charter and the name of the document leave these issues outside the scope. But I see and agree with the points brought up by Wes. Since the ultimate goal of the SIDR effort is to secure interdomain routing, a threat analysis with a wider scope, not constrained by somewhat arbitrary limitation of the charter, could have been helpful. Not to call for a re-charter, but rather to put the proposed solutions in the overall security context. draft-ietf-sidr-bgpsec-threats could be that document. Andrei -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJujjIACgkQljz5tZmtij9iDACgsbNtKG8BSh6SNCcXpztL6sap aFwAniQffoXzmadVE4NFGyY22/OJ76uE =kMEL -----END PGP SIGNATURE----- From e.hall@snsreports.com Tue Oct 29 04:15:13 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E0F21E8105 for ; Tue, 29 Oct 2013 04:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.922 X-Spam-Level: * X-Spam-Status: No, score=1.922 tagged_above=-999 required=5 tests=[AWL=-1.633, BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, SARE_HTML_USL_OBFU=1.666, SARE_PRODUCT=0.333] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdsWNT3olsr8 for ; Tue, 29 Oct 2013 04:15:13 -0700 (PDT) Received: from 220-190.sl.smtp.com (220-190.sl.smtp.com [192.40.190.220]) by ietfa.amsl.com (Postfix) with ESMTP id 45D4611E8220 for ; Tue, 29 Oct 2013 04:15:07 -0700 (PDT) X-MSFBL: c2lkckBpZXRmLm9yZ0AxOTJfNDBfMTkwXzIyMEBTbnN0ZWxlY29tX2RlZGljYXRl ZF9wb29sQA== DKIM-Signature: v=1; a=rsa-sha256; d=smtp.com; s=smtpcomcustomers; c=relaxed/simple; q=dns/txt; i=@smtp.com; t=1383045304; h=From:Subject:To:Date:MIME-Version:Content-Type; bh=f4gGUnH5do8qkYrwB7KlH16l6Z6hxLM1aIhxOep+Iqc=; b=X30Smur9buZY8SFkRlI2kwntNu12sbUckca3HJwyIki9/1MInyvAw/AuVSf0Fgn4 nRX5+r3bx10DhVfLPHRITgJ6/jdwEvqngLmVh1ybw2QiQyifbR/4GYsqHfIM9Nzp uyRJHpPtOOS0/xtifD/kiWYiPfayXuH/yhEgcT0/+WM=; Received: from [78.146.238.192] ([78.146.238.192:29708] helo=host-92-24-86-50.ppp.as43234.net) by sl-mta04 (envelope-from ) (ecelerity 3.3.2.44647 r(44647)) with ESMTPA id 03/6E-20390-5B89F625; Tue, 29 Oct 2013 11:15:04 +0000 MIME-Version: 1.0 From: "Signals & Systems Telecom" To: sidr@ietf.org Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Mailer: Smart_Send_2_0_132 Date: Tue, 29 Oct 2013 11:14:57 +0000 Message-ID: <4036372857920540728158@Owner-PC> X-SMTPCOM-Tracking-Number: 6f97bb2f-7710-456a-9284-3b6b06479ad7 X-SMTPCOM-Sender-ID: 6005703 X-SMTPCOM-Spam-Policy: SMTP.com is a paid relay service. We do not tolerate UCE of any kind. Please report it ASAP to abuse@smtp.com Subject: [sidr] The SDN, NFV & Network Virtualization Bible: 2014 - 2020 (Report) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: e.hall@snsreports.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 11:15:13 -0000

The SDN, NFV= & Network Virtualization Bible: 2014 - 2020 (Report)

Hello,

Hope you are doing well.

I wanted to bring to your attention the latest SNS Telecom rep= ort in which you might be interested, " The SDN, NFV & Network Vir= tualization Bible: 2014 - 2020."<= /SPAN>

I believe this report will be highly applicable for you. If you woul= d like to see the report sample or have any questions, please let me know. =

Report Information:

Release Date: October 2013

Number of Pages: 263

Number of Tables and Figures: 84

Report Overview:

While the benefits of Software Defined Networking (SDN) and ne= twork virtualization are well known in the enterprise IT and data center wo= rld, both technologies also bring a hosts of benefits to the telecommunicat= ions service provider/carrier community.

Not only can SDN and = network virtualization help address the explosive capacity demand of mobile= traffic, but they can also reduce the CapEx and OpEx burden faced by servi= ce providers to handle this demand by diminishing reliance on expensive pro= prietary hardware platforms.

SDN and network virtualization so= lutions have been widely deployed in data center and enterprise environment= s, and many service provider deployments are already underway. <= BR>
Network Functions Virtualization (NFV) is service provider led initi= ative aimed at virtualizing network components in a service provider networ= k. While NFV is still a developing technology with its first set of s= pecifications published in October 2013, many vendors have already develope= d commercial-grade solutions that align well with the NFV initiative.
Driven by the thriving ecosystem, SNS Research estimates that the SDN, NF= V and network virtualization market will account for nearly $4 Billion in 2= 014 alone. Despite barriers relating to standardization and co-existence wi= th legacy networks, SNS Research estimates further growth at a CAGR of near= ly 60% over the next 6 years.

This report presents an in-depth= assessment of the global SDN, NFV and network virtualization market. In ad= dition to covering underlying technology, key market drivers, challenges, f= uture roadmap, value chain analysis, use cases, deployment case studies, ex= pert interviews, company profiles, product strategies and strategic recomme= ndations, the report also presents comprehensive forecasts for the market f= rom 2013 till 2020. Historical revenue figures for 2010 =96 2012 are also p= resented. The forecasts and historical revenue figures are individually seg= mented for 3 individual submarkets, 2 user base categories, 7 use case cate= gories, 6 geographical regions and 34 countries.

The report comes with an associated Excel datasheet covering qua= ntitative data from all figures presented within the report.

Key Finding= s:

The report has th= e following key findings:

Driven by the thriving ecosystem, SNS Research estimates that the= SDN, NFV and network virtualization market will account for nearly $4 Bill= ion in 2014 alone. SNS Research estimates further growth at a CAGR of nearl= y 60% over the next 6 years
Although network virtualization in the enterprise IT and data cen= ter domain has received significant attention in the past years, service pr= ovider network virtualization is still at a nascent stage
SDN and NFV empower a multitude of network functions to be implem= ented cost effectively in software, ranging from standard mobile IP Multime= dia System (IMS) services to features such as Deep Packet Inspection (DPI)<= BR>
By 2017 we expect to see significant price and gross margin erosi= on for traditional hardware-based network switching equipment driven by alt= ernative software based solutions
By 2020 SNS Research estimates that SDN and NFV can enable servic= e providers (both wireline and wireless) to save up to $32 Billion in annua= l CapEx investments

Topics Cove= red:

The report covers= the following topics:

The scope and implementation of SDN, NFV and network virtua= lization across the globe
SDN, NFV and network virtualization technology
Market drivers and key benefits of SDN, NFV and network virtualiz= ation
Challenges and inhibitors to the ecosystem
Standardization and regulatory initiatives
Use cases and application case studies of SDN and NFV
SDN and NFV deployment case studies
SDN and NFV induced service provider CapEx savings
Value chain analysis of the ecosystem and the recognition of key = players in each segment of the value chain
Industry roadmap from 2014 till 2020
Key trends in the ecosystem; SDN and NFV=92s impact on the networ= k infrastructure value chain, the stance of incumbent vendors towards SDN a= nd NFV, impact on the proprietary hardware market and co-existence with leg= acy networks
Exclusive interview transcripts of 17 players in the ecosystem;&n= bsp; Alvarion, Aricent, Arista Networks, Broadcomm, Connectem, ConteXtream,= Extreme Networks, GENBAND, Mavenir, Netronome, Open Networking Foundation = (ONF), Openwave Mobility, Pica8, Plexxi, Radisys, Spirent Communications an= d Tellabs
Profiles and strategies of 122 key players in the ecosystem

Strategic recommendations for silicon & server OEMs, network = & mobile Infrastructure vendors, IT giants, pure-play SDN/NFV spe= cialists, enterprises, data center operators and service providers

Historical revenue figures and forecasts till 2020

Historical = Revenue & Forecast Segmentation:

Market forecasts = and historical revenue figures are provided for each of the following 5 sub= markets and their 23 use case categories:

Submarkets

SDN Software & Hardware
Non-NFV Network Virtualization Software
NFV Software

SDN Submarkets

SDN Controller Hardware Appliances
SDN Controller Software

User Base Categories

Service Providers
Data Centers & Enterprises

Service Provider Use Case Categories

Radio Access Networks
Mobile Core, EPC, IMS & Services
OSS/BSS
Data Center
Mobile Backhaul
Wireline Fixed Access Networks
CPE/Home Environment

The following regional and country markets ar= e also covered:

Regional Markets

Asia Pacific
Eastern Europe
Latin & Central America
Middle East & Africa
North America
Western Europe

Country Markets

Argentina, Australia, Brazil, Canada, China, Czech Republic, Denm= ark, Finland, France, Germany, India, Indonesia, Israel, Italy, Japan= , Malaysia, Mexico, Norway, Pakistan, Philippines, Poland, Qatar, Russia, S= audi Arabia, Singapore, South Africa, South Korea, Spain, Sweden, Taiwan, T= hailand, UAE, UK and USA

Additional foreca= sts are provided for:

SDN and NFV Induced Service Provider CapEx Savings by Region

Key Que= stions Answered:

The report provid= es answers to the following key questions:

What are the key market drivers and challenges for SDN, NFV and t= he wider network virtualization ecosystem=3F
How can SDN and NFV complement each other=3F
What are the key applications and use cases of SDN and NFV=3F

How is the SDN, NFV and network virtualization value chain struct= ured and how will it evolve overtime=3F

What opportunities do SDN and NFV offer to silicon & server O= EMs, network & mobile Infrastructure vendors, IT giants, pure-play SDN/= NFV specialists, enterprises, data center operators and service providers a= nd other players in the value chain=3F

What strategies should these players adopt to capitalize on the S= DN and NFV opportunity=3F

How are SDN and NFV vendors positioning their product offerings= =3F

How big is the SDN, NFV and network virtualization ecosystem, and= how much revenue will it generate in 2020=3F

What particular submarkets does the ecosystem constitute=3F

What geographical regions, countries and submarkets offer the gre= atest growth potential for SDN and NFV investments=3F

Who are the key players in the SDN and NFV ecosystem and what are= their strategies=3F

How will SDN and NFV impact the network infrastructure value chai= n=3F

Is there a ring leader in the SDN and NFV ecosystem=3F

How long will service providers continue to utilize proprietary h= ardware platforms=3F

How can SDN and NFV help make the Voice over LTE (VoLTE) and Rich= Communication Services (RCS) business case work=3F

How can software-defined Deep Packet Inspection (DPI) complement = SDN functionality=3F

What level of CapEx savings can SDN and NFV facilitate for servic= e providers in each region=3F

Report Pricing:

Single User License: USD 2,500

Company Wide License: USD 3,500

Ordering Process:

Please contact Emily Hall at = e.hall@snsreports.com<= /FONT>

And provide the following information:
Report Title:
Report Lice= nse (Single User/Company Wide):
Name:
Email:
Job Title:
Company= :
Invoice Address:

Please contact me if you have any questions, or wish to purchase = a copy.

I look forward to hearing from you.

Kind Regards,

Emily Hall

Sales Dire= ctor

Signals and Systems Telecom

Email: e.hall@snsreports.com<= /P>

Address: Reef Tower
Jumeirah Lake Towers
Shei= kh Zayed Road
Dubai, UAE

= www.snstele= com.com

<= /P>

To unsubs= cribe please click on the link below or send an email with unsubscribe in t= he subject line to: unsubscribe@snsreports.com<= /SPAN>

Remove

From stbryant@cisco.com Tue Oct 29 10:04:16 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D564F21F9DCF for ; Tue, 29 Oct 2013 10:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.514 X-Spam-Level: X-Spam-Status: No, score=-110.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijUWPofelbYV for ; Tue, 29 Oct 2013 10:04:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8093911E814D for ; Tue, 29 Oct 2013 09:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=103877; q=dns/txt; s=iport; t=1383065931; x=1384275531; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=Z8YyUh3mZBArnHJbhz1HuKppoSUT+1oVjxmwMGoYldg=; b=gwOWLpHeIWOrj3f20UxKi+bZ04Jyn9oaS81TRtsajKT9AT/umblmDRpA hJeWJb3ZYRpM6eVke/P5jl5BVMowksxxK0YfazZElPOnK2GLL5CiP9C7U 9u7ge8GqmxHtEyI4U0fefO0dxXqFEtBY5SZhsIZ6g/DkNakYx2y+vy4ii g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAKnob1KQ/khM/2dsb2JhbABPCoJDRDiJRLV6S4ErFnSCJQEBAQQBAQEqQQoRCxgJFgEBDQkDAgECARUwBgEMBgIBAReHbA26G419B4FKhCwDlCqDYJIIgyY X-IronPort-AV: E=Sophos;i="4.93,594,1378857600"; d="scan'208,217";a="161165731" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 29 Oct 2013 16:58:33 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9TGwRs8012728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 16:58:29 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9TGwQ2N017303; Tue, 29 Oct 2013 16:58:26 GMT Message-ID: <526FE932.9010707@cisco.com> Date: Tue, 29 Oct 2013 16:58:26 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Stephen Kent , "George, Wes" , sidr References: <20131008204114.28645.53351.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043C7556E1@PRVPEXVS15.corp.twcable.com> <52557287.8010205@bbn.com> <2671C6CDFBB59E47B64C10B3E0BD5923043C7FED59@PRVPEXVS15.corp.twcable.com> <5256C8C2.60902@bbn.com> In-Reply-To: <5256C8C2.60902@bbn.com> Content-Type: multipart/alternative; boundary="------------040507060309020706030702" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 17:04:16 -0000 This is a multi-part message in MIME format. --------------040507060309020706030702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Wes I am happy to talk to you about this at IETF, but I think the doc addresses the problem that SIDR was chartered to address. I acknowledge that there are wider threats, that need to be addressed, but as Steve says this I-D should not be a hostage to us putting in place solutions to those problems. - Stewart On 10/10/2013 16:33, Stephen Kent wrote: > Wes, > > I had to extract you reply and paste it into Word to read, because the > lines you wrote > were not properly wrapped by my e-mail reader. As a result, my reply > adopts a slightly different > format. > > OK, we agree that LTAM is out of scope for now. > > Your later comments are included below, along with my responses.: > > */[WEG] /*I think I was unclear in the way that I raised the concern, > and your response (below) helped me see that, so I'll try to clarify. > I don't care whether it's a charter/scope issue, and I'm not asking > for the summary for that reason. I care about it from the perspective > of its relative risk as a threat, and I made reference to the > scope/WG/charter/design discussion because I thought that would inform > the discussion of the level of risk (i.e. we decided that the risk was > not high enough to justify changes to the design to secure additional > attributes). > > > I better understand your comment. Your concern appears to be that a > reader of this doc will assume that we decided to not consider the > security of other path attributes because they are less important than > AS_Path. However, by stating that securing these other attributes is > deemed out of scope, based on the charter, I think we make it clear > that we have _not_ made a value judgement about the relative > importance of them. > > > */[WEG] /*I've seen the addition. It's not adequate to address my > concern, because the text in section 5 was not changed at all to > remove the reference to charter and "changes to this document at a > later time" for both route leaks and secondary attributes. > > > I don't see why you believe that references to the charter, augmented > by the salient text from the charter, are not appropriate here; that's > the reason these topics are not addressed. I also think > the note about updating the threat doc, if and when the charter is > changed to include these concerns, > is appropriate. It tells the reader that these topics may be addressed > in the future. > > > */[WEG]/*I'm no connoisseur of threat analyses, so I don't have a > large basis of comparison, but I do think that a threats document > should not identify a residual threat and then hand-wave it away as > "out of scope" instead of explaining the relative risk that it might > be exploited. It might even perhaps draw the conclusion that the risk > is negligible, but based on your explanation, WG charter and scope > shouldn't figure into the discussion.Worse yet, as this section is > currently written, it's circular logic: pathsec doesn't protect > non-AS_Path attributes, so there's a risk of those attributes being > manipulated without pathsec detecting it, but that's ok because > pathsec isn't required to protect against those things. Why isn't > pathsec required to protect against those things? Because the charter > says it isn't. Why does the charter say that? Because...reasons? > > > We fundamentally disagree on this point. A threat doc is always > constrained by some set of contextual > assumptions. Stating that we are aware of some concerns that are not > addressed, and that they may be > addressed in the future is a reasonable way to convey to the reader > what some of the contextual > constraints are. Your characterization of the discussion as "circular > reasoning" is faulty. What > the text says is that path security is the focus of the WG, and thus > is a constraint adopted by > this threat analysis, period. > > From a threat analysis perspective, either the ability to manipulate > unprotected attributes is a threat (a capability for an adversary to > carry out an attack) to BGP Path security, or it's not. I believe the > fact that you/the WG included it in the discussion means that you/the > WG believe that it's a threat. I could infer based on the fact that > SIDR chose not to design protections against that exploit that it's a > real threat but very low risk, or extremely difficult to exploit, or > whatever, but the document doesn't currently say anything about the > relative level of risk for the threat being identified. You're right > in that the design/requirements decisions that SIDR WG made about > whether to address that threat are mostly irrelevant, but the fact > that you discuss it in terms of design scope makes that confusing if > one is to evaluate this text as purely a threats analysis. It goes > back to a recurring issue that has happened with the order of these > documents, where we're writing a threats doc and a requirements doc > based on an existing design rather than the other around, and are > tailoring these documents based on the current design to the exclusion > of things deemed out of scope instead of documenting everything and > then deciding some of the specific scope items in the > requirements/design phase. > > > As noted above, every threat analysis takes place in a context, else > it could never be complete. We have a > context defined by the WG charter, and I have chosen to use that > context to constrain what the analysis covers. We cannot "document > everything" any more than a scientist can "gather all the data and > they form a hypothesis." Your criticisms about the order of doc > preparation suggest a deeper discontent with the > WG process. I suggest you talk with the WG chairs and the cognizant AD > about that, rather than taking > it out in this doc. > > Steve > > p.s. in the later parts of your comments you repeatedly use the term > "threat" when you mean "attack" or maybe "vulnerability" or ... > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------040507060309020706030702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Wes

I am happy to talk to you about this at IETF, but I think the
doc addresses the problem that SIDR was chartered to
address.

I acknowledge that there are wider threats, that need to
be addressed, but as Steve says this I-D should not be
a hostage to us putting in place solutions to those problems.

- Stewart

On 10/10/2013 16:33, Stephen Kent wrote:

Wes,

I had to extract you reply and paste it into Word to read, because the lines you wrote
were not properly wrapped by my e-mail reader. As a result, my reply adopts a slightly different
format.

OK, we agree that LTAM is out of scope for now.

Your later comments are included below, along with my responses.:

[WEG] I think I was unclear in the way that I raised the concern, and your response (below) helped me see that, so I’ll try to clarify. I don’t care whether it’s a charter/scope issue, and I’m not asking for the summary for that reason. I care about it from the perspective of its relative risk as a threat, and I made reference to the scope/WG/charter/design discussion because I thought that would inform the discussion of the level of risk (i.e. we decided that the risk was not high enough to justify changes to the design to secure additional attributes).

I better understand your comment. Your concern appears to be that a reader of this doc will assume that we decided to not consider the security of other path attributes because they are less important than AS_Path. However, by stating that securing these other attributes is deemed out of scope, based on the charter, I think we make it clear that we have not made a value judgement about the relative importance of them.

[WEG] I’ve seen the addition. It’s not adequate to address my concern, because the text in section 5 was not changed at all to remove the reference to charter and “changes to this document at a later time” for both route leaks and secondary attributes.

I don't see why you believe that references to the charter, augmented by the salient text from the charter, are not appropriate here; that's the reason these topics are not addressed. I also think
the note about updating the threat doc, if and when the charter is changed to include these concerns,
is appropriate. It tells the reader that these topics may be addressed in the future.

[WEG] I’m no connoisseur of threat analyses, so I don’t have a large basis of comparison, but I do think that a threats document should not identify a residual threat and then hand-wave it away as “out of scope” instead of explaining the relative risk that it might be exploited. It might even perhaps draw the conclusion that the risk is negligible, but based on your explanation, WG charter and scope shouldn’t figure into the discussion. Worse yet, as this section is currently written, it’s circular logic: pathsec doesn’t protect non-AS_Path attributes, so there’s a risk of those attributes being manipulated without pathsec detecting it, but that’s ok because pathsec isn’t required to protect against those things. Why isn’t pathsec required to protect against those things? Because the charter says it isn’t. Why does the charter say that? Because…reasons?

We fundamentally disagree on this point. A threat doc is always constrained by some set of contextual
assumptions. Stating that we are aware of some concerns that are not addressed, and that they may be
addressed in the future is a reasonable way to convey to the reader what some of the contextual
constraints are. Your characterization of the discussion as "circular reasoning" is faulty. What
the text says is that path security is the focus of the WG, and thus is a constraint adopted by
this threat analysis, period.

From a threat analysis perspective, either the ability to manipulate unprotected attributes is a threat (a capability for an adversary to carry out an attack) to BGP Path security, or it’s not. I believe the fact that you/the WG included it in the discussion means that you/the WG believe that it’s a threat. I could infer based on the fact that SIDR chose not to design protections against that exploit that it’s a real threat but very low risk, or extremely difficult to exploit, or whatever, but the document doesn’t currently say anything about the relative level of risk for the threat being identified. You’re right in that the design/requirements decisions that SIDR WG made about whether to address that threat are mostly irrelevant, but the fact that you discuss it in terms of design scope makes that confusing if one is to evaluate this text as purely a threats analysis. It goes back to a recurring issue that has happened with the order of these documents, where we’re writing a threats doc and a requirements doc based on an existing design rather than the other around, and are tailoring these documents based on the current design to the exclusion of things deemed out of scope instead of documenting everything and then deciding some of the specific scope items in the requirements/design phase.

As noted above, every threat analysis takes place in a context, else it could never be complete. We have a
context defined by the WG charter, and I have chosen to use that context to constrain what the analysis covers. We cannot "document everything" any more than a scientist can "gather all the data and they form a hypothesis." Your criticisms about the order of doc preparation suggest a deeper discontent with the
WG process. I suggest you talk with the WG chairs and the cognizant AD about that, rather than taking
it out in this doc.

Steve

p.s. in the later parts of your comments you repeatedly use the term "threat" when you mean "attack" or maybe "vulnerability" or ...
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

--------------040507060309020706030702-- From iesg-secretary@ietf.org Wed Oct 30 08:10:30 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C610911E82AA; Wed, 30 Oct 2013 08:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.378 X-Spam-Level: X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os7j-rENTamd; Wed, 30 Oct 2013 08:10:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A2811E8344; Wed, 30 Oct 2013 08:09:11 -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: 4.81 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131030150911.6951.64059.idtracker@ietfa.amsl.com> Date: Wed, 30 Oct 2013 08:09:11 -0700 Cc: sidr@ietf.org Subject: [sidr] Last Call: (RPKI Router Implementation Report) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 15:10:30 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'RPKI Router Implementation Report' 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 2013-11-27. 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 is an implementation report for the RPKI Router protocol as defined in [RFC6810]. The editor did not verify the accuracy of the information provided by respondents. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. Respondents were asked to only use the YES answer if the feature had at least been tested in the lab. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-impl/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-impl/ballot/ No IPR declarations have been submitted directly on this I-D. From kent@bbn.com Wed Oct 30 09:09:05 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E045D11E8266 for ; Wed, 30 Oct 2013 09:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.52 X-Spam-Level: X-Spam-Status: No, score=-106.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8k4KMbpCLXJ for ; Wed, 30 Oct 2013 09:09:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 73A7F11E8174 for ; Wed, 30 Oct 2013 09:08:34 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:51932) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VbYJo-0005gZ-Na for sidr@ietf.org; Wed, 30 Oct 2013 12:08:28 -0400 Message-ID: <52712EFC.3090600@bbn.com> Date: Wed, 30 Oct 2013 12:08:28 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20131020170318.5AF3F172B7@thrintun.hactrn.net> In-Reply-To: <20131020170318.5AF3F172B7@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] Soliciting agenda ideas for Vancouver X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 16:09:06 -0000 Rob, I re-read your doc and I'm in favor of having SIDR pursue this work. because it retains rsync as the RP fetch protocol, it should be compatible with current deployments. Steve From wwwrun@rfc-editor.org Wed Oct 30 11:09:09 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89C811E82C4; Wed, 30 Oct 2013 11:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6HFW8Oi43Mj; Wed, 30 Oct 2013 11:09:09 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7355B11E82BC; Wed, 30 Oct 2013 11:07:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B2407726001; Wed, 30 Oct 2013 10:58:19 -0700 (PDT) To: david@mandelberg.org, gih@apnic.net, ggm@apnic.net, kent@bbn.com From: RFC Errata System Message-Id: <20131030175821.B2407726001@rfc-editor.org> Date: Wed, 30 Oct 2013 10:58:19 -0700 (PDT) Cc: rfc-editor@rfc-editor.org, sidr@ietf.org, iesg@ietf.org Subject: [sidr] [Errata Verified] RFC6489 (3756) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 18:09:10 -0000 The following errata report has been verified for RFC6489, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6489&eid=3756 -------------------------------------- Status: Verified Type: Technical Reported by: David Mandelberg Date Reported: 2013-10-16 Verified by: Stewart Bryant (IESG) Section: 2 Original Text ------------- This request MUST include the same SIA extension that is present in the CURRENT CA certificate. Corrected Text -------------- The AccessDescriptions with accessMethods of id-ad-caRepository in the request's SIA extension MUST be the same as the AccessDescriptions with accessMethods of id-ad-caRepository in the CURRENT CA certificate's SIA extension. Notes ----- An RFC6487-compliant CA certificate's SIA extension has AccessDescriptions for both its repository (id-ad-caRepository) and its manifest (id-ad-rpkiManifest). Section 2 of RFC6489 also states, "While the 'current' and 'new' CA instances share a single repository publication point, each CA has its own CRL and its own manifest." This indicates that only the id-ad-caRepository AccessDescriptions should be identical, not the id-ad-rpkiManifest AccessDescriptions. -------------------------------------- RFC6489 (draft-ietf-sidr-keyroll-08) -------------------------------------- Title : Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI) Publication Date : February 2012 Author(s) : G. Huston, G. Michaelson, S. Kent Category : BEST CURRENT PRACTICE Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From kent@bbn.com Thu Oct 31 07:13:20 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5077911E811A; Thu, 31 Oct 2013 07:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uUMsRnaRaoK; Thu, 31 Oct 2013 07:13:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 95D4B21F9E33; Thu, 31 Oct 2013 07:13:15 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49278) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Vbszf-000CgI-Ve; Thu, 31 Oct 2013 10:13:04 -0400 Message-ID: <52726570.8090507@bbn.com> Date: Thu, 31 Oct 2013 10:13:04 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: RFC Errata System , david@mandelberg.org, gih@apnic.net, ggm@apnic.net References: <20131030175821.B2407726001@rfc-editor.org> In-Reply-To: <20131030175821.B2407726001@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org, iesg@ietf.org Subject: Re: [sidr] [Errata Verified] RFC6489 (3756) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 14:13:20 -0000 I concur with the clarifying errata. Steve ------ On 10/30/13 1:58 PM, RFC Errata System wrote: > The following errata report has been verified for RFC6489, > "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6489&eid=3756 > > -------------------------------------- > Status: Verified > Type: Technical > > Reported by: David Mandelberg > Date Reported: 2013-10-16 > Verified by: Stewart Bryant (IESG) > > Section: 2 > > Original Text > ------------- > This > > request MUST include the same SIA extension that is present in > > the CURRENT CA certificate. > > Corrected Text > -------------- > The AccessDescriptions with accessMethods of id-ad-caRepository in the > > request's SIA extension MUST be the same as the AccessDescriptions with > > accessMethods of id-ad-caRepository in the CURRENT CA certificate's SIA > > extension. > > Notes > ----- > An RFC6487-compliant CA certificate's SIA extension has AccessDescriptions for both its repository (id-ad-caRepository) and its manifest (id-ad-rpkiManifest). Section 2 of RFC6489 also states, "While the 'current' and 'new' CA instances share a single repository publication point, each CA has its own CRL and its own manifest." This indicates that only the id-ad-caRepository AccessDescriptions should be identical, not the id-ad-rpkiManifest AccessDescriptions. > > -------------------------------------- > RFC6489 (draft-ietf-sidr-keyroll-08) > -------------------------------------- > Title : Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI) > Publication Date : February 2012 > Author(s) : G. Huston, G. Michaelson, S. Kent > Category : BEST CURRENT PRACTICE > Source : Secure Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG > From ebarnes@bbn.com Thu Oct 31 11:26:19 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD10C11E822D for ; Thu, 31 Oct 2013 11:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHHdUZCRXMaO for ; Thu, 31 Oct 2013 11:26:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id BC36B11E824F for ; Thu, 31 Oct 2013 11:25:56 -0700 (PDT) Received: from trenzalore.bbn.com ([128.89.88.54]:58295) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VbwwH-000FLa-4i; Thu, 31 Oct 2013 14:25:49 -0400 Message-ID: <5272A0AA.20507@bbn.com> Date: Thu, 31 Oct 2013 14:25:46 -0400 From: Edric Barnes User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: rpstir-announce@bbn.com, rpki@rpki.net, sidr@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------060805040708080806010807" Subject: [sidr] RPSTIR v0.9 Released X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 18:28:14 -0000 This is a multi-part message in MIME format. --------------060805040708080806010807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit We released a new version of the BBN RPKI validator, Relying Party Security Technology for Internet Routing (RPSTIR). This update focused on portable RFC and Internet-Draft conformance tests, which are available independent of the validator. Conformance Cases: rsync://rpki.bbn.com/conformance/ Conformance Cases Readme: rsync://rpki.bbn.com/conformance/README RPSTIR: https://sourceforge.net/projects/rpstir/ Contact: rpstir-support@bbn.com Change log for version 0.9: * Add many more conformance test cases, around 350 total. (See doc/conformance-cases for the full list.) These test cases can be used by relying party software to test compliance with published RFCs and Internet-Drafts. Additionally, relying party software that passes the tests can be used to test the output of a Certification Authority. * Fix bugs found by the above test cases. * Add a pseudo-random factor to the calculation of how long to wait before retrying an rsync connection. This should help prevent many relying parties from hitting the same server at the same time. * Implement basic support for collecting statistics of the RPKI over time. -- Edric Barnes --------------060805040708080806010807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

We released a new version of the BBN RPKI validator, Relying Party Security Technology for Internet Routing (RPSTIR). This update focused on portable RFC and Internet-Draft conformance tests, which are available independent of the validator.

Conformance Cases: rsync://rpki.bbn.com/conformance/
Conformance Cases Readme: rsync://rpki.bbn.com/conformance/README
RPSTIR: https://sourceforge.net/projects/rpstir/
Contact: rpstir-support@bbn.com

Change log for version 0.9:

Add many more conformance test cases, around 350 total. (See doc/conformance-cases for the full list.) These test cases can be used by relying party software to test compliance with published RFCs and Internet-Drafts. Additionally, relying party software that passes the tests can be used to test the output of a Certification Authority.
Fix bugs found by the above test cases.
Add a pseudo-random factor to the calculation of how long to wait before retrying an rsync connection. This should help prevent many relying parties from hitting the same server at the same time.
Implement basic support for collecting statistics of the RPKI over time.

-- 
Edric Barnes

--------------060805040708080806010807--