Re: [secdir] Secdir review of draft-ietf-pce-rfc6006bis

Dhruv Dhody <dhruv.ietf@gmail.com> Fri, 01 September 2017 05:13 UTC

Return-Path: <dhruv.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FECB1330FA; Thu, 31 Aug 2017 22:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 lSI4J1Ow4ejT; Thu, 31 Aug 2017 22:13:27 -0700 (PDT)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 0C42D1330F1; Thu, 31 Aug 2017 22:13:27 -0700 (PDT)
Received: by mail-qk0-x230.google.com with SMTP id l65so6711163qkc.0; Thu, 31 Aug 2017 22:13:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hXs3loFdPVPq7sdxo8PdFl4JOab3FjWd9RMQiRS7Qfw=; b=IeS54nkLl6QHavY0BJsjt8ACPX3MNwj4Med6mkWrL9C8txWn6uG72U7EH5SV/ygyrc taTF9pdG7Z6oR+f6Lwss6PeldICg3WrqTRk5j+0Bnglc72eoCwlnQY6Yq2f04c506elx 6ZX80svpP4KatQWKZ1ctDfK39QiOgGjNwBHG7siI3S8FVK+mq4LysTKDRBzjLqD22O6j RzsyyJvblDPbgcO6B8hT/OPZAdt+VM5ZVuvE6nU04OErhgH1ldDwOA+ZF0Janv9K4xtO 6P3HPGEg1/aB2QQUPyqAxfqljfMV7FcSIeqTcWh5TfFhLT3e5ixcXkBKEAch5b/A67Gw WFmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hXs3loFdPVPq7sdxo8PdFl4JOab3FjWd9RMQiRS7Qfw=; b=oH2SMBNlo+jMT12rEvIhvq/0OAwD9EadApaZ6UvU3rhr85VPdQ2k1OdvlSQVSfA1hp 09n81iWw16sJSBZNL7UlaGuceM4tSD09X9iFW4b6xGQ9DnYBm+xVM4mByo/CRhC5XAnH 0AO3Qkjdj7OSgo5xnr1NfDM9rB4ptnPkVcdVwC5dlhI1FLmac8v9a7v8Ky1UVWCjhM1W gpGA5hC94Ci5Jy5Y6Z6z2hutGtDq85rcUmBMbaAPakzQEZMtsbs1okb8yeW5tSmnhwBX aBknI8sBugyGh5gopNLQRgAtGtMWs7744X+trQEMGxEvKOOfE14XVdcm8Rt7hpZWseNU f2zw==
X-Gm-Message-State: AHPjjUgeEaeV71DTCrKbfXOdESDJd73YilmK/pq1llbAVEkw/w/CKnMK npOqwkco5N0IDCtA4rs/ViCtwH4DiA==
X-Google-Smtp-Source: ADKCNb4kGQtXH6cLqlmS3g3r55Dl5nVL/kiPvkE8xAITfCoBWUTtDrxsgbRSJCE2OfK+JmQzE+FlCiSHkwEMhQF7NSM=
X-Received: by 10.55.41.69 with SMTP id p66mr1098798qkh.109.1504242806113; Thu, 31 Aug 2017 22:13:26 -0700 (PDT)
MIME-Version: 1.0
Sender: dhruvdhody@gmail.com
X-Google-Sender-Delegation: dhruvdhody@gmail.com
Received: by 10.140.107.73 with HTTP; Thu, 31 Aug 2017 22:13:25 -0700 (PDT)
In-Reply-To: <CY4PR1701MB1926723B19518B2895C016D9DF8F0@CY4PR1701MB1926.namprd17.prod.outlook.com>
References: <CY4PR1701MB1926723B19518B2895C016D9DF8F0@CY4PR1701MB1926.namprd17.prod.outlook.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Fri, 1 Sep 2017 10:43:25 +0530
X-Google-Sender-Auth: lOl3Wosb4yAGggf8nU2boT08_ng
Message-ID: <CAB75xn5PsWi7EKHpocz3_fb9ukCCLK0ULSkX9o8-5e1NTN-1yw@mail.gmail.com>
To: Charlie Kaufman <charliekaufman@outlook.com>
Cc: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-pce-rfc6006bis.all@tools.ietf.org" <draft-ietf-pce-rfc6006bis.all@tools.ietf.org>, "BRUNGARD, DEBORAH A" <db3546@att.com>, pce-chairs@ietf.org, "dhruv.dhody@huawei.com" <dhruv.dhody@huawei.com>
Content-Type: multipart/alternative; boundary="001a1147af321d4bc8055819d2e4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/qrAiKL6kfPuNvXUPzEgAFN3dqeY>
Subject: Re: [secdir] Secdir review of draft-ietf-pce-rfc6006bis
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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, 01 Sep 2017 05:13:29 -0000

Hi Charlie,

Thanks for your review and comments. Eric also raised similar concerns and
I proposed this as the updated text as what can be a part of a bid document
for a PCEP extension -

5.  Security Considerations

   As described in [RFC5862], P2MP path computation requests are more
   CPU-intensive and also utilize more link bandwidth.  In the event of
   an unauthorized P2MP path computation request, or a denial of service
   attack, the subsequent PCEP requests and processing may be disruptive
   to the network.  Consequently, it is important that implementations
   conform to the relevant security requirements that specifically help
   to minimize or negate unauthorized P2MP path computation requests and
   denial of service attacks.  These mechanisms include:

   o  Securing the PCEP session requests and responses is RECOMMENDED
      using TCP security techniques such as TCP Authentication Option
      (TCP-AO) [RFC5925] or using Transport Layer Security (TLS) [I-
      D.ietf-pce-pceps], as per the recommendations and best current
      practices in [RFC7525].

   o  Authenticating the PCEP requests and responses to ensure the
      message is intact and sent from an authorized node using TCP-AO or
      TLS is RECOMMENDED.

   o  Providing policy control by explicitly defining which PCCs, via IP
      access-lists, are allowed to send P2MP path requests to the PCE.

   PCEP operates over TCP, so it is also important to secure the PCE and
   PCC against TCP denial of service attacks.

   As stated in [RFC6952], PCEP implementations should support TCP-AO
   [RFC5925] and not use TCP-MD5 because of the known vulnerabilities
   and weakness.

You can see the diff at - https://www.ietf.org/rfcdiff?url1=draft-ietf-pce-
rfc6006bis-03&url2=https://raw.githubusercontent.com/
dhruvdhody-huawei/ietf/master/draft-ietf-pce-rfc6006bis-04.txt

Let me know if you have any modification suggestions here.

See inline...


On Sun, Aug 13, 2017 at 8:54 AM, Charlie Kaufman <charliekaufman@outlook.com
> wrote:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> Document editors and WG chairs should treat these comments just like any
> other last call comments.
>
>
> Summary: No significant security issues
>
>
> This document is a "refreshing" of rfc6006 (Extensions to PCEP for
> Point-to-Multipoint Traffic Engineering Label Switched Paths) to
> incorporate errata that have accumulated over the last seven years. There
> may be some small additional changes.
>
>
> One minor change was made to Security considerations, and it was a good
> change, but I fear makes the security considerations somewhat internally
> inconsistent. That change was to change a recommendation to use TCP-AO to a
> recommendation to use TLS. TLS is a more logical protocol to use in this
> context, but the security considerations also references RFC5440, what
> mandates TCP-MD5 and recommends TCP-AO (which was not available when
> RFC5440 was written).
>
>
> I'm not sure the best way to resolve this... probably to leave it as is.
> Someday, RFC5440 should be updated.
>
>
> Security considerations in this document discusses that dangers of
> someone impersonating a client for the purpose of denying service or
> learning about the network configuration, and RFC5440 talks about that
> dangers of eavesdropping in learning what the client is doing. It does
> not discuss whether there are important threats posed by someone
> impersonating a PCEP server and returning bad routing information. I
> suspect that might be a more serious threat then either of the other
> attacks, but don't know enough about how the protocol is used to know for
> sure.
>
>
> ​RFC5440 has this text -

   Attacks on PCEP may result in damage to active networks.  If path
   computation responses are changed, the PCC may be encouraged to set
   up inappropriate LSPs.  Such LSPs might deviate to parts of the
   network susceptible to snooping, or might transit congested or
   reserved links.  Path computation responses may be attacked by
   modification of the PCRep message, by impersonation of the PCE, or by
   modification of the PCReq to cause the PCE to perform a different
   computation from that which was originally requested.

​


> In any case, all the considerations mentioned above probably belong in
> RFC5440 (PCEP) rather than this document concerning extensions.
>
>
>
​Agreed. ​



> --Charlie Kaufman
>
>
> ​Thanks for your review.

Regards,
Dhruv​