[secdir] SecDir review of draft-ietf-ospf-prefix-hiding-04

Julien Laganier <julien.ietf@gmail.com> Fri, 06 July 2012 19:44 UTC

Return-Path: <julien.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 43C4221F8620; Fri, 6 Jul 2012 12:44:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dxb83GsmPNze; Fri, 6 Jul 2012 12:44:36 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A91D021F861C; Fri, 6 Jul 2012 12:44:36 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so15395466pbc.31 for <multiple recipients>; Fri, 06 Jul 2012 12:44:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tCoz3CML/HwCVCyQG3SLSTTEeA1Su8UW24GwDje8Im0=; b=DokYMAAs830gWDNbyF4TslhFNHBMif6VoWaniSOc7JH1sS7tIHjS2ECrrrx06nG8ZV 7eFu8bXKdeNM7XJ3leXMqunaA0JBxYI02Nun6onUxrw7HxVHr1tbI8cdYO6Sc+zbqZhs NWdkg0CK99YHsijO/HyqplUeGGoo4lcqbKAO3J1b13fNHPbpDi3abns9eH+KwVyrHCx/ Wp5VXujWBt0TK9ba8k+IW6wuPyVunchdaoTqiFrSLshguXYSjy2JyFaLarYQDLAcEWuy w9vmS4jJ+ue2lpqYY28H7S1791sCK5WB3mWmbz+YEc8D0uy8H7tRJPBQfpZwt1x9LrCH 4fFQ==
MIME-Version: 1.0
Received: by 10.68.193.195 with SMTP id hq3mr39578810pbc.30.1341603893771; Fri, 06 Jul 2012 12:44:53 -0700 (PDT)
Received: by 10.68.138.137 with HTTP; Fri, 6 Jul 2012 12:44:53 -0700 (PDT)
Date: Fri, 6 Jul 2012 12:44:53 -0700
Message-ID: <CAE_dhjvtKqfgJF+vjp1un_672sEZ_gw-6q6N_RsCsYgmrjr36g@mail.gmail.com>
From: Julien Laganier <julien.ietf@gmail.com>
To: secdir@ietf.org, draft-ietf-ospf-prefix-hiding.all@tools.ietf.org, The IESG <iesg@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: [secdir] SecDir review of draft-ietf-ospf-prefix-hiding-04
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: Fri, 06 Jul 2012 19:44:37 -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.

Disclaimer: I am no routing or OSPF expert and might be missing
something obvious...

According to its abstract the draft describes a mechanism that allows
hiding transit-only networks in OSPF:

   A transit-only network is defined as a network connecting routers
   only.  In OSPF, transit-only networks are usually configured with
   routable IP addresses, which are advertised in Link State
   Advertisements (LSAs) but not needed for data traffic.  In addition,
   remote attacks can be launched against routers by sending packets to
   these transit-only networks.  This document presents a mechanism to
   hide transit-only networks to speed up network convergence and
   minimize remote attack vulnerability.

While the desire to speed up the network convergence is probably
obvious and not of concern, I think the document and its security
considerations section in particular could do a better job at
explaining what the mechanism achieves in terms of minimizing remote
attack vulnerability.

As per my understanding, the proposed mechanism essentially remove the
subnet / netmask information from Link State Advertisements, but these
still contain the routers' IP addresses.

It is not clear to me how removing the subnet / netmask information
actually minimizes the risk of remote attacks.

First of all, the type of remote attacks that minimized should be made
more explicit. What is the target of the remote attacks? Is it any
address in the subnet? Or the address of a router? If the latter, then
it is not clear how the mechanism actually improves -- the router's IP
addresses are still in the LSAs so presumably an attacker can still
launch remote attacks on these addresses, no? If the former, then it
is not clear how effective is omission of the subnet in avoiding
attacks avoid addresses within that subnet -- addresses in the
(unknown) subnet can still be inferred from addresses of the routers,
no? Or is it the case that the LSAs containing the IP addresses of the
routers will not be propagated outside of an area that the attacker
has no access to?

Expanding the security considerations might help answering these questions...

--julien