Re: [sidr] Gen-ART review of draft-ietf-sidr-bgpsec-threats-06
"Black, David" <david.black@emc.com> Mon, 30 September 2013 23:02 UTC
Return-Path: <david.black@emc.com>
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 E51CF21F99E9; Mon, 30 Sep 2013 16:02:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level:
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=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 LabRlwO-hmnz; Mon, 30 Sep 2013 16:02:37 -0700 (PDT)
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0FB21F9AA1; Mon, 30 Sep 2013 16:02:33 -0700 (PDT)
Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r8UN2S1j006653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Sep 2013 19:02:28 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com r8UN2S1j006653
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1380582148; bh=dDgd9THgV6eZli+a6imdS828dvM=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=r7Ts7EmUFw7W6fkr26nDV7qCxl3WJjlutYFvipXW33+/3R3q6+egT0oG0GrYZ8i+r hLHpdNTC7jsJ16z2+RJWdsPvQR6/04T3Fv44t1SEmBsINRMaMWPfRjFarcruXKhid9 +sJxokHsLcY8anqNGRCE2DSJhgjril9IxfBk8RLw=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com r8UN2S1j006653
Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd06.lss.emc.com (RSA Interceptor); Mon, 30 Sep 2013 16:02:12 -0700
Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r8UN2B2R008180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Sep 2013 19:02:11 -0400
Received: from mx15a.corp.emc.com ([169.254.1.46]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Mon, 30 Sep 2013 19:02:11 -0400
From: "Black, David" <david.black@emc.com>
To: Stephen Kent <kent@bbn.com>
Date: Mon, 30 Sep 2013 19:02:09 -0400
Thread-Topic: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06
Thread-Index: Ac6+CBbVhSmDE70mQoK256XQLmYrMwAJU83Q
Message-ID: <8D3D17ACE214DC429325B2B98F3AE712025DBB7B41@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE712025DBB6FDA@MX15A.corp.emc.com> <5249BE21.4060702@bbn.com>
In-Reply-To: <5249BE21.4060702@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_8D3D17ACE214DC429325B2B98F3AE712025DBB7B41MX15Acorpemcc_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com
X-EMM-GWVC: 1
X-RSA-Classifications: DLM_1, public
X-EMM-McAfeeVC: 1
Cc: "ietf@ietf.org" <ietf@ietf.org>, "Black, David" <david.black@emc.com>, "sidr@ietf.org" <sidr@ietf.org>, "General Area Review Team (gen-art@ietf.org)" <gen-art@ietf.org>
Subject: Re: [sidr] Gen-ART review of draft-ietf-sidr-bgpsec-threats-06
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Sep 2013 23:02:43 -0000
Steve, [1] Terminology: > The term PATHSEC is used to refer to a generic path security solution > approach, consistent with the WG charter, rather than to the specific > solution approach, BGPsec, that has been developed. The rationale for > using the different term is that this threat doc should precede the > requirements doc, which should precede the solution design. In reality, > the requirements doc was generated before the threat analysis, and the > BGPSEC design was well along before this doc was finalized. Earlier versions > of the doc did refer to BGPsec, but the term was changed for the reasons > cited above. This doc does embed assumptions about what a general path > security architecture would entail, e.g., based on prior work on such > architectures, e.g, S-BGP. That change in terminology is fine - what's missing (IMHO) is an explanation of how the new terminology relates to terminology used in related drafts. As the term "PATHSEC" appears to be unique to this draft, I think this draft should explain how that term relates to the BGPsec terminology used elsewhere for a specific instance of the PATHSEC concept. Discussion of related prior work that also falls under the heading of PATHSEC would be good to add (e.g., a sentence or two on S-BGP in addition to BGPsec would make it clear that PATHSEC is the more general term), but I don't view that as essential. That should address most of my concerns around text that I found hard to interpret, e.g., the excerpt from section 4.2 in the original review: >> 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. >> >> What is "PATHSEC data"? What are "the PATHSEC goals"? > > PATHSEC data is whatever data is sent via a path security design to enable > an AS to verify that the UPDATE has traversed the indicated set of ASes. The > goals for PATHSEC are the ones stated in the SIDR WG charter . (The relevant > charter text used to appear up front, but was removed at the request of the > WG chairs and the cognizant AD. The relevant text appears in this version on > page 16, as part of the residual vulnerabilities discussion.) I think the terminology clarification will clear up what "PATHSEC data" is, but the notion of describing the goals of an architecture ("PATHSEC goals") as "residual vulnerabilities" strikes me as both peculiar and unclear. [2] Caching > The RPKI mandates caching (see RFCs 6480 and 6481), and since use of the RPKI > as a basis for PATHSEC is mandated by the SIDR charter, I didn't feel it was > necessary to repeat that here. But we can include a cite: > > Note first that the RPKI calls for RPs to cache the data they acquire > and verify from the repository system [RFC6480, RFC6481]. That addition would definitely help. I'd suggest: "calls for" -> "requires that" I would also observe that it's not a good assumption that the RFC that results from this draft will be read in tandem with the SIDR charter (not much of a problem here, but a more serious problem in [1] above). If that really is intended, then an informative reference to the SIDR charter should be added, although I don't think it's a good idea for an RFC to reference a WG charter - the relevant WG charter portions should be reproduced in the RFC. [3] TCPMD5 reference > idnits 2.12.17 complains about a missing reference: > > == Missing Reference: 'TCPMD5' is mentioned on line 114, but not defined > > 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 ignore. > > I disagree, and I discussed this with Stewart previously. The reference appears > in a quote and was appropriate at the time the quoted text was generated. Ok - I was suggesting adding an informative reference to RFC 2385, but this is a nit, and so if the responsible AD is happy with omitting that reference entirely, I don't have a problem. Thanks, --David From: Stephen Kent [mailto:kent@bbn.com] Sent: Monday, September 30, 2013 2:09 PM 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 Subject: Re: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06 David, Major issue: This draft contains more than just a threat model. agreed. It also contains a high level security analysis of the security architecture/approach that applies the RPKI to secure use of BGP. yes. we didn't create a threat model doc for the RPKI, and this seemed like a good time to address that omission, since the SIDR charter mandates use of the RPKI as a basis for the path security design. 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. The term PATHSEC is used to refer to a generic path security solution approach, consistent with the WG charter, rather than to the specific solution approach, BGPsec, that has been developed. The rationale for using the different term is that this threat doc should precede the requirements doc, which should precede the solution design. In reality, the requirements doc was generated before the threat analysis, and the BGPSEC design was well along before this doc was finalized. Earlier versions of the doc did refer to BGPsec, but the term was changed for the reasons cited above. This doc does embed assumptions about what a general path security architecture would entail, e.g., based on prior work on such architectures, e.g, S-BGP. 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: I hope my explanation above explains why the terminology was adopted. 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. 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. PATHSEC data is whatever data is sent via a path security design to enable an AS to verify that the UPDATE has traversed the indicated set of ASes. The goals for PATHSEC are the ones stated in the SIDR WG charter . (The relevant charter text used to appear up front, but was removed at the request of the WG chairs and the cognizant AD. The relevant text appears in this version on page 16, as part of the residual vulnerabilities discussion.) Minor Issue: Section 4.4 seems somewhat loose on caching by RPs, considering the importance of that caching in countering a number of the attacks described 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. 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. The RPKI mandates caching (see RFCs 6480 and 6481), and since use of the RPKI as a basis for PATHSEC is mandated by the SIDR charter, I didn't feel it was necessary to repeat that here. But we can include a cite: Note first that the RPKI calls for RPs to cache the data they acquire and verify from the repository system [RFC6480, RFC6481]. Nits/editorial comments: Also in Section 4.4: (The RP would be very unhappy if there is no CRL for the CA instance anyway.) 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. I'll remove the flippant parenthetical. You're right that it isn't useful. idnits 2.12.17 complains about a missing reference: == Missing Reference: 'TCPMD5' is mentioned on line 114, but not defined 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 ignore. I disagree, and I discussed this with Stewart previously. The reference appears in a quote and was appropriate at the time the quoted text was generated.
- [sidr] Gen-ART review of draft-ietf-sidr-bgpsec-t… Black, David
- Re: [sidr] Gen-ART review of draft-ietf-sidr-bgps… Stephen Kent
- Re: [sidr] Gen-ART review of draft-ietf-sidr-bgps… Black, David
- Re: [sidr] Gen-ART review of draft-ietf-sidr-bgps… Stephen Kent
- Re: [sidr] Gen-ART review of draft-ietf-sidr-bgps… Black, David
- Re: [sidr] Gen-ART review of draft-ietf-sidr-bgps… Stephen Kent
- Re: [sidr] Gen-ART review of draft-ietf-sidr-bgps… Black, David