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

Loa Andersson <> Mon, 15 December 2014 06:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D4A0C1A1A00; Sun, 14 Dec 2014 22:30:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SVbFAo9yC-zz; Sun, 14 Dec 2014 22:29:59 -0800 (PST)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 589A41A0363; Sun, 14 Dec 2014 22:29:59 -0800 (PST)
Received: from [] (unknown []) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id B4D1D1801590; Mon, 15 Dec 2014 07:29:55 +0100 (CET)
Message-ID: <>
Date: Mon, 15 Dec 2014 14:29:51 +0800
From: Loa Andersson <>
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 <>,,, The IESG <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [secdir] secdir review of draft-ietf-mpls-lsp-ping-relay-reply
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Dec 2014 06:30:02 -0000


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.


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]


Loa Andersson                        email:
Senior MPLS Expert                
Huawei Technologies (consultant)     phone: +46 739 81 21 64