[Isis-wg] Genart last call review of draft-ietf-isis-auto-conf-04

Robert Sparks <rjsparks@nostrum.com> Fri, 07 April 2017 20:24 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: isis-wg@ietf.org
Delivered-To: isis-wg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D0E124BFA; Fri, 7 Apr 2017 13:24:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
To: <gen-art@ietf.org>
Cc: draft-ietf-isis-auto-conf.all@ietf.org, ietf@ietf.org, isis-wg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.49.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149159669211.11107.3275242226580240988@ietfa.amsl.com>
Date: Fri, 07 Apr 2017 13:24:52 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/H2-FNT5m2tDrHnDv7IODk5Vd2hs>
Subject: [Isis-wg] Genart last call review of draft-ietf-isis-auto-conf-04
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Apr 2017 20:24:52 -0000

Reviewer: Robert Sparks
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-isis-auto-conf-04
Reviewer: Robert Sparks
Review Date: 2017-04-07
IETF LC End Date: 2017-04-10
IESG Telechat date: 2017-04-13

Summary: Ready for publication as Proposed Standard, but with 
one possible thing to add to the security consideration section

This document is clear and seems straightforward to implement. 

I think, however, there is an attack possibility you should call out 
in the security considerations section. As home routers are used 
as examples of elements that might use this protocol, consider 
the case of a malicious party wanting to deny service in that home.
A suborned device in the home could watch for the protocol, and
present a crafted packet to force the home router(s) to re-start
the autoconfiguration protocol continually (by claiming to be a
duplicate and being careful to make it the routers job to restart).
Having the md5 password configured would mitigate this attack.