Re: [secdir] secdir review of draft-ietf-mpls-lsp-ping-relay-reply

Loa Andersson <loa@pi.nu> Mon, 15 December 2014 06:30 UTC

Return-Path: <loa@pi.nu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A0C1A1A00; Sun, 14 Dec 2014 22:30:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SVbFAo9yC-zz; Sun, 14 Dec 2014 22:29:59 -0800 (PST)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589A41A0363; Sun, 14 Dec 2014 22:29:59 -0800 (PST)
Received: from [192.168.1.12] (unknown [112.205.93.13]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id B4D1D1801590; Mon, 15 Dec 2014 07:29:55 +0100 (CET)
Message-ID: <548E7FDF.80801@pi.nu>
Date: Mon, 15 Dec 2014 14:29:51 +0800
From: Loa Andersson <loa@pi.nu>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Sean Turner <turners@ieca.com>, draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org, secdir@ietf.org, The IESG <iesg@ietf.org>
References: <B04C70D5-6C5C-4962-8867-32F68AF74D47@ieca.com>
In-Reply-To: <B04C70D5-6C5C-4962-8867-32F68AF74D47@ieca.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/7ftXCowZjOhDcVlZHox5qxyNILo
Subject: Re: [secdir] secdir review of draft-ietf-mpls-lsp-ping-relay-reply
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 15 Dec 2014 06:30:02 -0000

Sean,

We had a "wrinkle" on this :( ! Two of the authors discovered (very
late) something that needs to be addressed.

I asked the AD to send the ducment back to the working group for "more
work". I hope it be a smooth process, and that we'll get the document
timely back on track again.

Anyhow, I expect that the authors takes care of your comments during the
"more work" process.

/Loa

On 2014-12-14 03:29, Sean Turner wrote:
> Do not be alarmed.  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 with the intent
> of improving security requirements and considerations in IETF drafts.
> Comments not addressed in last call may be included in AD reviews
> during the IESG review.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> Version: 06
> Summary: Ready with some non-security/non-privacy nits.
>
> Ping mechanisms always give me the heebie-jeebies [1]
> because of the security concerns associated with them (i.e., DoS,
> spoofing/hijacking/etc., and unauthorized disclosure).  This document
> specifies an extension to the existing ECHO mechanism in RFC 4379
> and it does nothing to address these concerns in fact it increases the
> concerns wrt DoS. *BUT* it rightly points this increase exposure out in
> the security considerations section.  It provides remediation techniques
> similar to those specified in RFC 4379: rate limit and validate source
> against access list.  This draft, unlike RFC 4379, does recommend that
> operators wishing to not disclose their nodes blank the address out in
> the TLV.  This draft also refers to RFC 4379 for additional security
> considerations.
>
> WARNING - questions and nits follow:
>
> s3 - 1st paragraph: Relayed Echo Reply “replaces” Echo Reply - does this
> mean you’re deprecating the use of “Echo Reply”?
>
> s4.1: Is the outermost label allowed to be set to 255 to support the
> “ping” mode or must it always be set to 1, 2, etc. to support “traceroute"
> mode - as described in RFC 4379 s4.3?   I know s5 is just an example
> but it really looks like this extension is just supposed to be for fault
> isolation.
>
> s4.1 - last paragraph: Does the next initiator put it’s address in the stack
> before or after the previous initiator?  I assume it’s after, but I maybe
> missed that part?  Would be good to state that explicitly.
>
> Cheers,
> spt
>
> [1] http://en.wikipedia.org/wiki/Heebie-jeebies_(idiom)
>

-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64