[secdir] SecDir review of draft-ietf-rtgwg-ipfrr-notvia-addresses-10

Yaron Sheffer <yaronf.ietf@gmail.com> Thu, 31 January 2013 17:43 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E0B21F86EA; Thu, 31 Jan 2013 09:43:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gf3A8bW5U3nn; Thu, 31 Jan 2013 09:43:05 -0800 (PST)
Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id CDE4121F87AB; Thu, 31 Jan 2013 09:43:04 -0800 (PST)
Received: by mail-ee0-f42.google.com with SMTP id b47so1606187eek.15 for <multiple recipients>; Thu, 31 Jan 2013 09:43:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=SQWqWx6hmUqKqOb8wJOc3JR4+N6HSAIfFc0qpKwtz+U=; b=Cb0KqyVa+cubhNea11DblsvEhvsVe5rHygTR/RLceojq55QxRDLHD81HPI9CoW7DdQ oTonWtawctRdL2muD4ZxcLtQh55XnXntpiHh5/70LA9IYO2gEWWhUHYLlRx59QvY6UUv 4CIoaPhXqn2YdXtL3gooxUD859PZOyMoo9ajm8bcOoI9q6DvS5tVabQAR72LLbVx8/Pm 966Jlo0TjR15ARVlssFg/9vB9M4qL9Cc+fpj/d9wDhtr6gwgpLK1TpJ7RahDyM16YiBc fH6m0CQ3IcSGeM56FC0S5TAdwoALgWtKzsn0C0N5niKJMJjCU72sPVzd2eDsmIqyM6Jz 9g0g==
X-Received: by 10.14.4.194 with SMTP id 42mr29633836eej.35.1359654183988; Thu, 31 Jan 2013 09:43:03 -0800 (PST)
Received: from [10.0.0.5] ([109.67.127.19]) by mx.google.com with ESMTPS id 44sm8451184eek.5.2013.01.31.09.43.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jan 2013 09:43:02 -0800 (PST)
Message-ID: <510AAD22.1010601@gmail.com>
Date: Thu, 31 Jan 2013 19:42:58 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: IETF Security Directorate <secdir@ietf.org>, draft-ietf-rtgwg-ipfrr-notvia-addresses.all@tools.ietf.org, The IESG <iesg@ietf.org>
References: <4FBFAE5F.8010305@gmail.com>
In-Reply-To: <4FBFAE5F.8010305@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [secdir] SecDir review of draft-ietf-rtgwg-ipfrr-notvia-addresses-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 31 Jan 2013 17:43:05 -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.

This document describes a method to protect a network from router/link 
failures by encapsulating packets in an envelope that denotes what nodes 
it should *not* be routed through. This is not a protocol definition 
(despite a few stray MUSTs), it is only an informational summary of 
design issues and a framework.

Summary

The document is good to go. In fact, a SecDir review is not applicable.

Details

The document does contain a Security Considerations section that goes 
through 3 potential security issues. But since the document in general 
is a high-level discussion, it is impossible to analyze whether all 
pertinent security issues are covered. If the not-via mechanism is ever 
specified as a protocol, the security analysis will need to be done from 
scratch.

Thanks,
      Yaron