Re: secdir review of draft-ietf-mpls-lsp-ping-relay-reply
"lizho.jin@gmail.com" <lizho.jin@gmail.com> Sat, 07 March 2015 15:33 UTC
Return-Path: <lizho.jin@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95AB1A90F9; Sat, 7 Mar 2015 07:33:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.702
X-Spam-Level:
X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 ZOyNX55R66JZ; Sat, 7 Mar 2015 07:33:46 -0800 (PST)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34E321A90F4; Sat, 7 Mar 2015 07:33:46 -0800 (PST)
Received: by igbhl2 with SMTP id hl2so10246292igb.0; Sat, 07 Mar 2015 07:33:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:references:mime-version:message-id :content-type; bh=NBLG47+OUYH0oT9U+sUaEvGMf7kAJvpotD6aEqi+lfc=; b=wREcfhdePKMKTGu3Ut1WYjNDls7iEVOVNv7+V0SZaXloz1nlxEzkRr+dEAhm5f4WW7 kDNIXwIs2IEaK7cmIoqkmMKK9bjRo0lQTMZvnjst7WOckY0763ud/H4PYoHtIQcSGajF b7fztzDo9QCG/VF6pmRNYz0NNIxje/e65JsWT0HBDZL5Rd4ngZyMztf9mRm94caDw9kU GOvI7sS0z0bA/aYbVFMU/IOO5w2Pq79TdvzOYxKsh+jJ7SlcxtIePKqbTGnZmAjc/06W lMj06cQ7Msmo7wSO+Jndukdb9WOeFifT/cM1NOGZAka0JO3RYyxw7tryELeYfjsdW+8C vhFQ==
X-Received: by 10.50.222.70 with SMTP id qk6mr61292992igc.47.1425742425684; Sat, 07 Mar 2015 07:33:45 -0800 (PST)
Received: from Lizhong ([118.132.61.135]) by mx.google.com with ESMTPSA id x10sm2834252igl.13.2015.03.07.07.33.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Mar 2015 07:33:44 -0800 (PST)
Date: Sat, 07 Mar 2015 23:34:00 +0800
From: "lizho.jin@gmail.com" <lizho.jin@gmail.com>
To: turners <turners@ieca.com>, draft-ietf-mpls-lsp-ping-relay-reply <draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org>, secdir <secdir@ietf.org>, iesg <iesg@ietf.org>, ietf <ietf@ietf.org>
Subject: Re: secdir review of draft-ietf-mpls-lsp-ping-relay-reply
References: <B04C70D5-6C5C-4962-8867-32F68AF74D47@ieca.com>
X-Priority: 3
X-GUID: 8436043E-B8A4-4F6A-AFAE-32CF90514F8F
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 5, 140[en]
Mime-Version: 1.0
Message-ID: <2015030723335400131415@gmail.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart033887510674_=----"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/5nNmm_XI2NaNi_wjRaRRx_j1huA>
X-Mailman-Approved-At: Mon, 09 Mar 2015 07:49:41 -0700
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Mar 2015 15:33:48 -0000
Hi Sean Turner Thank you for the review. I am so sorry to reply after a long time. We need to update the document according to George's comments. Now we have post v7, URL: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-relay-reply-07.txt The change lists are as below: 1. add a destination point in stack TLV to avoid potential loop. 2. add a source address in stack TLV, then the initiator could get the replying node address. I also reply inline to your questions as below. Thank you. Regards Lizhong From: Sean Turner Date: 2014-12-14 03:29 To: draft-ietf-mpls-lsp-ping-relay-reply; secdir; The IESG; ietf Subject: secdir review of draft-ietf-mpls-lsp-ping-relay-reply 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”? [Lizhong] no. The reply message from any node to initiator will still be Echo Reply. But the reply message from replying LSR to a relay node or from a relay node to another relay node will be Relayed 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. [Lizhong] It is possible to set 255. One implementation in my mind is to manually generate the stack TLV list, and the replying LSR could still relay the message back to the initiator according to the received stack TLV list. The case in the document is for stack TLV list auto learning. 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. [Lizhong] are you referring to section 4.2. There is some change in v7. Please help to check again, to see if that is OK for you now. Cheers, spt [1] http://en.wikipedia.org/wiki/Heebie-jeebies_(idiom)
- secdir review of draft-ietf-mpls-lsp-ping-relay-r… Sean Turner
- Re: secdir review of draft-ietf-mpls-lsp-ping-rel… lizho.jin@gmail.com