[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, 06 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
- [secdir] SecDir review of draft-ietf-ospf-prefix-… Julien Laganier
- Re: [secdir] SecDir review of draft-ietf-ospf-pre… Acee Lindem
- Re: [secdir] SecDir review of draft-ietf-ospf-pre… Retana, Alvaro
- Re: [secdir] SecDir review of draft-ietf-ospf-pre… Retana, Alvaro
- Re: [secdir] SecDir review of draft-ietf-ospf-pre… Julien Laganier