[secdir] secdir review of draft-ietf-mpls-proxy-lsp-ping-03

Tom Yu <tlyu@mit.edu> Tue, 17 February 2015 23:10 UTC

Return-Path: <tlyu@mit.edu>
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 D4F601A8862; Tue, 17 Feb 2015 15:10:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 g4mFPxcCDFJq; Tue, 17 Feb 2015 15:10:14 -0800 (PST)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0FEF1A1AB5; Tue, 17 Feb 2015 15:10:13 -0800 (PST)
X-AuditID: 1209190d-f792d6d000001fc7-bc-54e3ca540127
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 4F.7F.08135.45AC3E45; Tue, 17 Feb 2015 18:10:12 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t1HNABGj007862; Tue, 17 Feb 2015 18:10:12 -0500
Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1HNA9Pf017191; Tue, 17 Feb 2015 18:10:10 -0500
From: Tom Yu <tlyu@mit.edu>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org
Date: Tue, 17 Feb 2015 18:10:08 -0500
Message-ID: <ldv1tlow2wf.fsf@sarnath.mit.edu>
Lines: 38
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUixCmqrBty6nGIwb4P6hYr+qcxWsz4M5HZ 4sPChywOzB5Llvxk8vhy+TNbAFMUl01Kak5mWWqRvl0CV0bXQd6CmfwV575eYG1gXMPTxcjJ ISFgIvFqyz4mCFtM4sK99WxdjFwcQgKLmSRudnYzQjgbGSWmzHvIDOG8YZRY0LaFEaSFTUBa 4vjlXWDtIgJxEu82L2MHsYUFrCVWP/7BBmKzCKhK/LjbyQJi8wroSuw/e4cZxOYR4JRYuK6L HSIuKHFy5hOwGmYBLYkb/14yTWDknYUkNQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJd I73czBK91JTSTYzgkJLk3cH47qDSIUYBDkYlHl6LCY9ChFgTy4orcw8xSnIwKYnyBh55HCLE l5SfUpmRWJwRX1Sak1p8iFGCg1lJhFfpBFCONyWxsiq1KB8mJc3BoiTOu+kHX4iQQHpiSWp2 ampBahFMVoaDQ0mCd95JoEbBotT01Iq0zJwShDQTByfIcB6g4YdBaniLCxJzizPTIfKnGBWl xHmngSQEQBIZpXlwvbCYf8UoDvSKMK80SBUPMF3Adb8CGswENHj+n0cgg0sSEVJSDYzMC/UO TmzbcMRpOst8vT+curoLKrImcD8MDvmxoiv0yFfLjmCRjE7/hxqWej7KEvNKDL5/vPqizcdk wzylEB+2z5ZT1jzqCvbxUMqS4tsn4aj6ZPWXf7z9ttvM/vgYSp7/Y/pC8OHjZ2s8HAryBDyC 3v9S/CI1+cg66w/ztqUeYHF0zkt3ZFBiKc5INNRiLipOBAB2I9ks1AIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/0ucJ4tnGT_8YgmS3dpcc_7z2OVc>
Subject: [secdir] secdir review of draft-ietf-mpls-proxy-lsp-ping-03
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: Tue, 17 Feb 2015 23:10:16 -0000

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 primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

Summary: ready with nits

The Security Considerations section seems mostly adequate, assuming that
it is an acceptable risk to use address-based filtering.

I am a little concerned about the wording of the destination address
checks on the proxy ping requests.  Shouldn't the Proxy LSR know what
its own addresses are, and explicitly check for them?  Does "Martian"
filtering refer to all undesired destination addresses, or just reserved
ones?

There seems to be no citation for the term "Martian address" as used in
sections 3.2 and 6 of this document; RFC 3704 comes close.  If that
definition is appropriate here, perhaps this document should cite RFC
3704?  I think I have also heard "Martian" used more expansively to
refer to other address blocks that should not be routed, despite not
being formally reserved (e.g., unallocated by the responsible registry).
Perhaps that definition is more appropriate.

Editorial:

The use of destination addresses in range 127/8 seems odd to me, but I
eventually found that RFC 4379 allows the use of such loopback range
addresses for the LSP echo requests.  Is this correct?  It might be good
to briefly explain that unusual usage.

Also, I am not too familiar with the special IPv6 address ranges, but it
seems that ::FFFF:7F00:0/104 is a IPv4-mapped loopback range, and
therefore is equivalent to the 127/8 IPv4 range mentioned earlier.  I
don't know whether you need to call this out specifically.  Also, RFC
4379 uses the notation ::FFFF:127/104.  I'm not sure which of those
notations is preferred for IPv4-mapped addresses.