Re: [secdir] secdir review draft-ietf-teas-p2mp-loose-path-reopt-08

"Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com> Fri, 10 February 2017 13:28 UTC

Return-Path: <rgandhi@cisco.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 E3F4A1296F8; Fri, 10 Feb 2017 05:28:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 0_92M2h_Rg-j; Fri, 10 Feb 2017 05:28:16 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C95A61298D9; Fri, 10 Feb 2017 05:28:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2218; q=dns/txt; s=iport; t=1486733295; x=1487942895; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=yZ1WUuHHUftnD9EWl/5O4QA1Q8BOW5DKR+aUeugDNCE=; b=YFxVzQyZIQmE1/Hd2Ay5RVlUJhMV548ZfDMBNsNYxXZqbPQElhQoR4Iv SGCrRs1AnLIaMXK0nhOzk38abBEe1MHX55rQUGhlWi0pl81tmE1HRp7lE EAHo9k+Pw/2+3YchZAoylDjvM/jzgqMewxLMFyV0P9UZXhBgl4W1I1g5z g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CFAQCJv51Y/5BdJa1eGQEBAQEBAQEBAQEBBwEBAQEBg1KBageDUooIp0KCDYYiAhqCXD8YAQIBAQEBAQEBYiiEagYjETceAgEGAhoCJgICAjAVEAIEARKJeJIPnU6CJYtUAQEBAQEBAQEBAQEBAQEBAQEBIIELhUGCBYJqhFQXgm8ugjEBBJtyAZITkQWTFAEfOH5PFU0BhDIdgWF1iRKBDAEBAQ
X-IronPort-AV: E=Sophos;i="5.35,141,1484006400"; d="scan'208";a="179082421"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Feb 2017 13:28:00 +0000
Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v1ADS0Cn032125 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Feb 2017 13:28:00 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 10 Feb 2017 07:28:00 -0600
Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Fri, 10 Feb 2017 07:28:00 -0600
From: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
To: Leif Johansson <leifj@sunet.se>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-teas-p2mp-loose-path-reopt.all@ietf.org" <draft-ietf-teas-p2mp-loose-path-reopt.all@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Thread-Topic: secdir review draft-ietf-teas-p2mp-loose-path-reopt-08
Thread-Index: AQHSg3BeCgs9ReovyU+ah1HabloPmqFiTOCA
Date: Fri, 10 Feb 2017 13:28:00 +0000
Message-ID: <4CCAD7DC-173A-41E9-A22B-E87A05CFC07B@cisco.com>
References: <36116fa6-2670-c0b2-3a4f-b72107bfbc82@sunet.se>
In-Reply-To: <36116fa6-2670-c0b2-3a4f-b72107bfbc82@sunet.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1d.0.161209
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.246.247]
Content-Type: text/plain; charset="utf-8"
Content-ID: <5F5B462C160F1644BB61641AD77F82E5@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/TyFEoQeVJ5kjeWIq_OaRHvyYtik>
Subject: Re: [secdir] secdir review draft-ietf-teas-p2mp-loose-path-reopt-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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, 10 Feb 2017 13:28:17 -0000

Hi Leif,

Thank you for the review of the document. 

RFC 4736 (basis for this document), Security Section 9, has coverage for this aspect – “Furthermore, a head-end LSR may decide to ignore explicit notification coming from a mid-point residing in another domain.”

Thanks,
Rakesh


On 2017-02-10, 2:30 AM, "Leif Johansson" <leifj@sunet.se> wrote:

    
    Reviewer: Leif Johansson
    Review result: Minor issues
    
    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.
    
    The draft describes a way to handle groupings of large sets of sub-
    LSPs in a P2MP GMPLS setup for the purpose of traffic engineering
    (re-)optimization by introducing the concept of "fragment identifiers"
    
    Let me state up front that the topic is outside my normal area of
    expertise. My only question is this: could an attacker fake messages
    that would (to the receiver ingress node) appear to be part of a
    fragmented group of sub-LSPs so as to trigger a full re-computation
    of the tree? The text in the last but one paragraph of 4.2 would
    seem to suggest that this attack is a possibility. At "worst" this
    would be a denial-of-service attack but it should perhaps be addressed
    in the security considerations section anyway.
    	
    	Cheers Leif