Re: [mpls] Stephen Farrell's Discuss on draft-ietf-mpls-mldp-node-protection-05: (with DISCUSS and COMMENT)

IJsbrand Wijnands <ice@cisco.com> Wed, 16 September 2015 06:54 UTC

Return-Path: <ice@cisco.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E801B37AF; Tue, 15 Sep 2015 23:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 5uDNRmE_OalY; Tue, 15 Sep 2015 23:54:15 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9B31B37AC; Tue, 15 Sep 2015 23:54:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2704; q=dns/txt; s=iport; t=1442386455; x=1443596055; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=l9ceGCv2KRGoU+J3kVvKMexLd0vsrtPincwE9Wtlgvs=; b=lc7aTlNxQHUVT0XtKMSjVi6kjQz4WjRz0c94xAgJF1/+2ueEt+8OsHbI fo8fl3PYbSqEfcwUu26CMMqwTfEvguYDuCFtqNIzdo848EpM3BeZb/RV2 YQQr5AeS3xvS3gLNLzFy8gHrNQsP4guDGUM7Fd3YrVZ3bKGvc0ekZz4eW I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AJAgBjEflV/xbLJq1dg3dpqTsBAQEBAQEFAYEKkwIBDYF5hXkCgXgUAQEBAQEBAYEKhCMBAQEDASNWBQsLGAICHwcCAlcGE4gmCA21LZRGAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIoUKglaCboQqEQEeMweCaS+BFAWHM44rhRCHc4FNhDWRIoNsHwEBQoJDgUA8MwGIaoE/AQEB
X-IronPort-AV: E=Sophos;i="5.17,537,1437436800"; d="scan'208";a="611633996"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 16 Sep 2015 06:54:12 +0000
Received: from ams-iwijnand-8816.cisco.com (ams-iwijnand-8816.cisco.com [10.60.202.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8G6sBku027574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Sep 2015 06:54:12 GMT
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: IJsbrand Wijnands <ice@cisco.com>
In-Reply-To: <20150915121844.9126.51946.idtracker@ietfa.amsl.com>
Date: Wed, 16 Sep 2015 08:54:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <55E921B2-C178-45D6-8E7F-12E4DB950583@cisco.com>
References: <20150915121844.9126.51946.idtracker@ietfa.amsl.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.1993)
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/RROXQ16-DUuzerX5Jdk4k0hpCIQ>
Cc: mpls@ietf.org, mpls-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-mpls-mldp-node-protection.shepherd@ietf.org, draft-ietf-mpls-mldp-node-protection.ad@ietf.org, draft-ietf-mpls-mldp-node-protection@ietf.org
Subject: Re: [mpls] Stephen Farrell's Discuss on draft-ietf-mpls-mldp-node-protection-05: (with DISCUSS and COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Sep 2015 06:54:17 -0000

Hi Steven,

Does Adrian’s proposed text solve your ‘DISCUSS’?

—
  The procedures in this document add two new TLVs to existing LDP
  messages.  Those TLVs can be protected by the mechanisms that are
  used to protect LDP messages as described in [RFC6388] and [RFC5920].
  If it were possible to attack the mechanisms described in this 
  document an LSR (a PLR or a MPT) could be induced to support a large
  number of tLDP sessions and set up an even larger number of LSPs.
  The security mechanisms in [RFC6388] and [RFC5920] are believed to be
  adequate, but an implementation could provide additional protection
  by counting such protection sessions and LSPs and producing a log
  message to the operator if a threshold is crossed.
—

Thx,

Ice.



> On 15 Sep 2015, at 14:18, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-mpls-mldp-node-protection-05: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-node-protection/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> The MUST in para 2 section 3 seems to me to create a possibly
> new DoS enabler. The ability of N to cause this kind of ripple
> effect, (setting up then pushing traffic to a bunch of new
> LSPs), is what may be new. Exactly where in the referenced RFCs
> is that covered? Or am I wrong that this is a new threat? (BTW:
> Answering that this new threat is no worse than other existing
> threats if one has access to the internals of a node.... is a
> non-answer:-)
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> While it is fine to re-use text, it is increasingly hard to
> believe that almost nothing done since RFC5920 (dated in 2010)
> has any new security considerations.  Put another way, who is
> really helped by a 2 line security considerations section that
> points at 6388 which points at 5036 (etc)?
> 
>