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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 16 September 2015 08:34 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 093B31B38E1; Wed, 16 Sep 2015 01:34:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jQCJeBjQTndR; Wed, 16 Sep 2015 01:34:08 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B0971B38E0; Wed, 16 Sep 2015 01:34:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D668CBE7B; Wed, 16 Sep 2015 09:34:00 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHkpYgpxLgg5; Wed, 16 Sep 2015 09:34:00 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 36D52BE5D; Wed, 16 Sep 2015 09:34:00 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1442392440; bh=iXWC8OSuwUVjHYZFSpLHT2GMFp6yliPUI2Ps47Yg+hs=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=yqUepW5nvbhkYgWnZuYZSQ3c9EsPRd4bhWA9ArXlf9Wvumd4kCrWLnFX8Qriqx4+P lVPItIPkFQdck8jErtutS+F7L2n+sxo7ajN7UJFZ2ehcWNDlg+A63Az7DYY8mqRxg4 sRT+smycTIKy20vvnF7NWfiJgCChxgUeWUIFvvTY=
To: IJsbrand Wijnands <ice@cisco.com>
References: <20150915121844.9126.51946.idtracker@ietfa.amsl.com> <55E921B2-C178-45D6-8E7F-12E4DB950583@cisco.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <55F92978.7020403@cs.tcd.ie>
Date: Wed, 16 Sep 2015 09:34:00 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <55E921B2-C178-45D6-8E7F-12E4DB950583@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/4rPWXdBdQZHtrn09wXQqpZSvyC0>
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@ietf.org, draft-ietf-mpls-mldp-node-protection.ad@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 08:34:10 -0000

Hiya,

On 16/09/15 07:54, IJsbrand Wijnands wrote:
> 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

Can't "N" also cause the potential DoS, if N is the compromised LSR?
But the main thing is that once this mechanism is supported, any LSR
(that is compromised) could try use this as a DoS vector/accelerator.

>   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.
> —

Yes, that text seems about right and good enough to clear
when you post a revision with that in it.

I could maybe quibble about the current security mechanisms being
adequate bit (are they really? say in a network with a small but
persistent percentage of compromised routers?) but I'll not quibble
in this case, as I guess that is a more general problem and it'd
not be right to try force a solution via this document.

Cheers,
S.

> 
> 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)?
>>
>>
>