Re: [secdir] Secdir review of draft-ietf-mpls-rfc4379bis-07

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Wed, 26 October 2016 06:58 UTC

Return-Path: <cpignata@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 CC23312946E; Tue, 25 Oct 2016 23:58:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.951
X-Spam-Level:
X-Spam-Status: No, score=-14.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, 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 MfIu6HVYS110; Tue, 25 Oct 2016 23:58:40 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388C7129A27; Tue, 25 Oct 2016 23:58:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21424; q=dns/txt; s=iport; t=1477465120; x=1478674720; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3FRkoRw/Y5Xr99UY4uarxM3eF+wqezPj1mWNncfNIiw=; b=ddYScS5Ocpct5943RmDYxLzkYK2WkAwCcZY0FcwM3laW9YEKDCft/KOa r4Dxu7RjmgDbd3MwYMUn6Lt7qD+hYEHYwrRTPP6fzIL9NN4NkmOq77Y9a aIK48fRS1Qw0U0sTPCLLz5KXemydA7fOCygdqCuKYa8Jy+QuB87im6zHj w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAQDiUhBY/5JdJa1bGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR2BVQeNLqYnhRaCB4YiAhqBYD8UAQIBAQEBAQEBYiiEYwE?= =?us-ascii?q?BBCNWEAIBCD8DAgICMBQRAgQOBYhUsyuMcwEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RyGPYF9gliEIwFZgk4sgi8FlDiFXgGQF4FuhG2JKI0IhAABHjZegxMFHFYBe3K?= =?us-ascii?q?GLgEBJAeBAoEJAQEB?=
X-IronPort-AV: E=Sophos;i="5.31,549,1473120000"; d="scan'208,217";a="340273343"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2016 06:58:39 +0000
Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u9Q6wcqs030789 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Oct 2016 06:58:39 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Oct 2016 02:58:38 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 26 Oct 2016 02:58:38 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Vincent Roca <vincent.roca@inria.fr>
Thread-Topic: Secdir review of draft-ietf-mpls-rfc4379bis-07
Thread-Index: AQHSK3L7mLnNZERQ4Uy2pbturGUgUqC6mOiA
Date: Wed, 26 Oct 2016 06:58:38 +0000
Message-ID: <59069EEB-D17D-4ECD-8AF6-507F9E6B3084@cisco.com>
References: <E1052DB3-20AB-4A0B-9869-927E0CADAFDA@inria.fr>
In-Reply-To: <E1052DB3-20AB-4A0B-9869-927E0CADAFDA@inria.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.5.58]
Content-Type: multipart/alternative; boundary="_000_59069EEBD17D4ECD8AF6507F9E6B3084ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/hTSYFEr4PHM_-tWQAE6FRm4czD8>
Cc: "draft-ietf-mpls-rfc4379bis.all@ietf.org" <draft-ietf-mpls-rfc4379bis.all@ietf.org>, IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-mpls-rfc4379bis-07
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: Wed, 26 Oct 2016 06:58:43 -0000

Hello Vincent,


Many thanks for your review! Please find some responses inline.

On Oct 21, 2016, at 1:13 AM, Vincent Roca <vincent.roca@inria.fr<mailto:vincent.roca@inria.fr>> wrote:

Hello,

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.

IMHO, the document is Ready with issues.

I have two main comments:

1- This document has an interesting security considerations section. However it
lacks some key information. First of all, there is no attacker model. Is the
threat coming from corrupted equipment? Do we assume those attackers have full
control over the equipment and flows? Are attackers on path or off path?
Clarifying these points (it's not an exhaustive list) would help structuring the
discussion on a case by case basis.


The security considerations section covers the approaches to attacking LSRs using LSP Ping/Traceroute. This is an exhaustive list which includes active and passive attacks. Is there some specific attack you see that is not covered?


2- Something else to clarify: I have the feeling (after quickly searching integrity/
authentication/HMAC/... keywords in the doc) that is no message integrity
nor sender authentication mechanism in the echo request/response detailed here.

That is correct, no message integrity nor sender authentication in LSP Ping.

If the attacker model also includes a full control of LSR, nothing can be done to
prevent some attacks. Please clarify.


Sorry but if an attacker has full control of an LSR, she or he is probably too busy on said LSR to send LSP Pings :-)


And a few additional ones:

3- First sentence says:
   "Overall, the security needs for LSP ping are similar to those of ICMP ping."
Such debugging tools as ping and traceroute (not speaking of MPLS version here)
have an efficiency that heavily relies on (sometimes arbitrary) decisions made
by the system administrators whose security policies lead to total or partial
blackholes.
Hence my questions: is the situation similar with MPLS or can we expect more
homogeneous and favorable security policies (e.g., because there's a limited
number of administrative domains, or because we are not relying on an ICMP
mechanism any more, or because the present document is more directive on
what a system administrator should authorize/block/limit)?

Yes. We can expect a more homogeneous and favorable set of security policies, because of all those reasons.

This could change a lot the security aspects and the potential impacts on the
debugging tools.


4- Later it is said:
     "To avoid potential Denial-of-Service attacks, it is RECOMMENDED that
     implementations regulate the LSP ping traffic going to the control
     plane.  A rate limiter SHOULD be applied to the well-known UDP port
     defined below."
- Do you mean port 3503? It is mentionned but not defined below in this section.
  Wording should be adjusted.

It actually is defined below. The Security Considerations is Section 5, and the port definition is in Section 6.

I added a more precise pointer:

   To avoid potential Denial-of-Service attacks, it is RECOMMENDED that
   implementations regulate the LSP ping traffic going to the control
   plane.  A rate limiter SHOULD be applied to the well-known UDP port
   defined in Section 6.1.

Thanks for the comment.


- It is not clear to me by reading this sentence if it concerns the sender
  (who sends traffic to the control plane) or forwarding nodes, which I guess
  are the target. In other words, "going to the control plane" is somewhat
  ambiguous.

If you look at the document locking on "sent to the control plane” and variations of it, the meaning will be clear.



5- Then:
     "To protect against unauthorized sources using MPLS echo request
     messages to obtain network information, it is RECOMMENDED that
     implementations provide a means of checking the source addresses of
     MPLS echo request messages against an access list before accepting
     the message."
Are ACL efficient in this context? If an attacker can forge the source address,
it's not. Unless some cryptographic mechanism is used, there's little hope to
provide a secure ping service. This is a follow up of comment 1.


This document does not goal itself in defining "secure ping”. It specifies “LSP Ping”, as a bis document.

However, if you have specific textual suggestions for improvement, those may also help clarify.


- Typo:
     "...an implementation MAY also validate the TimeStamp
     Sent by requiring an exact match on this field."
Sent => sent.

No. It’s the “TimeStamp Sent” field (see page 12).

Thanks again,

— Carlos.


Cheers,

  Vincent