Re: [secdir] review of draft-ietf-pce-pcep-domain-sequence-09
Dhruv Dhody <dhruv.ietf@gmail.com> Fri, 13 November 2015 08:53 UTC
Return-Path: <dhruv.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501411A1BCC; Fri, 13 Nov 2015 00:53:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.598
X-Spam-Level:
X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZNS9lk3TTpQ; Fri, 13 Nov 2015 00:53:02 -0800 (PST)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C55951A6F38; Fri, 13 Nov 2015 00:49:55 -0800 (PST)
Received: by iouu10 with SMTP id u10so83941768iou.0; Fri, 13 Nov 2015 00:49:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0rddT2vp7S33TfWMqZOjwSDzqwOcWT5nzzURJ9iHg2Q=; b=i6MxqFNAAXqxIydgiCrQVN4oL3jluXMT66uDPBFophnKs+IFrT4h6siKmSDKuSV5rM ed1rt8/Ol6ShDvr5WOTPDZWTkpafBo4jobLtKNkKgM15NzhK8XGIgbbtTrPutpWS5PGA dmBJgaCfJTbCDdcHAG4Hdhp+YwX53yRpV3e4OKMv76sOGZElNKVyjhXtWaXI5iviuhjU 4Ru9fDCC5JopMTqJ/mBzwEWpqfRZfpTNL75wZks8swTWea2JWG75hIrDDWClS1nywndD aoWaL+r7JfKLzn55yqgOaJdRP679ZJuyiULdq6/Dk9nxckMIqiFdMqvzQ73izSGJYuAh +OrA==
MIME-Version: 1.0
X-Received: by 10.107.164.24 with SMTP id n24mr19547773ioe.21.1447404595046; Fri, 13 Nov 2015 00:49:55 -0800 (PST)
Sender: dhruvdhody@gmail.com
X-Google-Sender-Delegation: dhruvdhody@gmail.com
Received: by 10.50.138.129 with HTTP; Fri, 13 Nov 2015 00:49:54 -0800 (PST)
In-Reply-To: <0424E22D-879D-4F05-B474-DE421FF1FADB@cisco.com>
References: <0424E22D-879D-4F05-B474-DE421FF1FADB@cisco.com>
Date: Fri, 13 Nov 2015 14:19:54 +0530
X-Google-Sender-Auth: o0Gnu9hTUaU8Cnht7GnpwN4ixRk
Message-ID: <CAB75xn49w2se7QfcP6AwoHmxVM1m8sTbRDOjJLWCdaEbOxNUOA@mail.gmail.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
To: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>
Content-Type: multipart/mixed; boundary="001a1141bc5cbc27eb052468244f"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/L3t8TWX7H7ytX_0Y8K_ipBeFclw>
X-Mailman-Approved-At: Fri, 13 Nov 2015 02:25:27 -0800
Cc: "draft-ietf-pce-pcep-domain-sequence.all@ietf.org" <draft-ietf-pce-pcep-domain-sequence.all@ietf.org>, "dhruv.dhody@huawei.com" <dhruv.dhody@huawei.com>, "pce-chairs@tools.ietf.org" <pce-chairs@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] review of draft-ietf-pce-pcep-domain-sequence-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2015 08:53:10 -0000
Hi Klaas, Thank you for your review and sorry for the delay in the reply [ Diwali festivities in these neck of woods :) ] Please see inline... On Mon, Nov 9, 2015 at 9:10 PM, Klaas Wierenga (kwiereng) < kwiereng@cisco.com> wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > I consider the document “ready with issues”, see below for detailed > comments: > > * 4.1 Inter-Area Path Computation > > you write: "This could be represented in the IRO as:” and then a number of > diagrams. It is unclear to me whether those different option are > functionally equivalent. The text suggests so to me, but that doesn’t seem > to make sense….. (or I completely misunderstand the text) > > To me it seems that the three sequences you give are all possible > sequences for the given topology not equivalent, I think the text needs > some clarification in that case. > > The same goes for 4.2, 4.3 etc. > > [Dhruv]: They are equivalent in the sense that if the source is in Area 2, destination in Area 4 and transit through Area 0, a PCC can encode the IRO in any of these combinations to get the same result. I can add clarification to make it clearer. > > * 4.5 P2MP > > I am guessing that the tree you show is the result of the three paths you > give before, but some explanation would be good. > > [Dhruv]: Ok, i can use the same example as https://tools.ietf.org/html/rfc7334#section-7.2 and add some more text here. > 7 security considerations > > I think these are a bit weak. Especially compared to what RFC5440 > provides. I consider an attacker gaining fine grained control over the > network path a very serious risk. The flippant comment about “routing > around trouble” doesn’t really do it for me. I would encourage you to take > a good look at the security considerations in 5440 and assess how those > considerations change given the finer grained control you provide. Some or > even most may remain the same, and it is fine to say so, but I can imagine > that some risks are higher because of the fine-grained control, and you > seem to suggest so too given the “the security techniques in rfc5440 are > considered more important”. So I really think this draft would benefit from > a better security considerations section. > [Dhruv]: Here is the updated text, let me know if you would like to see any changes. Text would be extra helpful. 7. Security Considerations The protocol extensions defined in this document do not substantially change the nature of PCEP. Therefore, the security considerations set out in [RFC5440] apply unchanged. Note that further security considerations for the use of PCEP over TCP are presented in [RFC6952]. This document specifies a representation of Domain-Sequence and new subobjects, which could be used in inter-domain PCE scenarios as explained in [RFC5152], [RFC5441], [RFC6805], [RFC7334] etc. The security considerations set out in each of these mechanisms remain unchanged by the new subobjects and Domain-Sequence representation in this document. But the new subobjects do allow finer and more specific control of the path computed by a cooperating PCE(s). Such control increases the risk if a PCEP message is intercepted, modified, or spoofed because it allows the attacker to exert control over the path that the PCE will compute or to make the path computation impossible. Consequently, it is important that implementations conform to the relevant security requirements of [RFC5440]. These mechanisms include: o Securing the PCEP session messages using TCP security techniques (Section 10.2 of [RFC5440]). PCEP implementations SHOULD also consider the additional security provided by the TCP Authentication Option (TCP-AO) [RFC5925] or [PCEPS]. o Authenticating the PCEP messages to ensure the message is intact and sent from an authorized node (Section 10.3 of [RFC5440]). o PCEP operates over TCP, so it is also important to secure the PCE and PCC against TCP denial-of-service attacks. Section 10.7.1 of [RFC5440] outlines a number of mechanisms for minimizing the risk of TCP-based denial-of-service attacks against PCEs and PCCs. o In inter-AS scenarios, attacks may be particularly significant with commercial as well as service-level implications. Note, however, that the Domain-Sequence mechanisms also provide the operator with the ability to route around vulnerable parts of the network and may be used to increase overall network security. Thank you for your review. The working copy diff is attached for reference (includes IANA, Gen-ART, Sec-Dir reviews). Regards, Dhruv > > Hope this helps, > > Klaas > > -- > Klaas Wierenga > Identity Architect > Cisco Cloud Services > > > > > > >
- [secdir] review of draft-ietf-pce-pcep-domain-seq… Klaas Wierenga (kwiereng)
- Re: [secdir] review of draft-ietf-pce-pcep-domain… Dhruv Dhody