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

"Retana, Alvaro" <alvaro.retana@hp.com> Fri, 06 July 2012 20:51 UTC

Return-Path: <alvaro.retana@hp.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 B8CBE11E810C; Fri, 6 Jul 2012 13:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.299
X-Spam-Level:
X-Spam-Status: No, score=-109.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 1JC8TnhBvgDo; Fri, 6 Jul 2012 13:51:25 -0700 (PDT)
Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfa.amsl.com (Postfix) with ESMTP id DB5F711E80DE; Fri, 6 Jul 2012 13:51:24 -0700 (PDT)
Received: from G1W3635G.americas.hpqcorp.net (g1w3635g.austin.hp.com [16.193.48.86]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id 8CED63842C; Fri, 6 Jul 2012 20:51:41 +0000 (UTC)
Received: from G2W1813G.americas.hpqcorp.net (16.238.8.212) by G1W3635G.americas.hpqcorp.net (16.193.48.86) with Microsoft SMTP Server (TLS) id 14.2.283.4; Fri, 6 Jul 2012 20:50:20 +0000
Received: from G2W2446.americas.hpqcorp.net ([169.254.7.17]) by G2W1813G.americas.hpqcorp.net ([fe80::2d8c:5671:edf9:26b0%12]) with mapi id 14.02.0283.003; Fri, 6 Jul 2012 20:50:20 +0000
From: "Retana, Alvaro" <alvaro.retana@hp.com>
To: Julien Laganier <julien.ietf@gmail.com>
Thread-Topic: SecDir review of draft-ietf-ospf-prefix-hiding-04
Thread-Index: AQHNW7H2jmw/JizKEk62icH9vhErYpccuHkA
Date: Fri, 6 Jul 2012 20:50:19 +0000
Message-ID: <C03AAF38AD209F4BB02BC0A34B774CE70B75F3@G2W2446.americas.hpqcorp.net>
References: <CAE_dhjvtKqfgJF+vjp1un_672sEZ_gw-6q6N_RsCsYgmrjr36g@mail.gmail.com> <CAE_dhjsgQZoC4_4jJ14JVKrp_ajjOfbbo9iTgp0XsK91mVozDw@mail.gmail.com>
In-Reply-To: <CAE_dhjsgQZoC4_4jJ14JVKrp_ajjOfbbo9iTgp0XsK91mVozDw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [15.217.50.29]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Sun, 08 Jul 2012 10:42:12 -0700
Cc: "draft-ietf-ospf-prefix-hiding.all@tools.ietf.org" <draft-ietf-ospf-prefix-hiding.all@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, Yi Yang <yiya@cisco.com>, Abhay Roy <akr@cisco.com>
Subject: Re: [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 20:51:26 -0000

Julien:

Hi!

[Thanks for forwarding.]

In short, avoiding installation of the routing information (even if still carried in the LSAs) means that the routers don't have forwarding information to reach a specific transit interface.  IOW, even if you know my IP address you can't send me a packet (if you're more than one hop away).  

We'll expand on the security considerations.

Thanks!!

Alvaro.

> -----Original Message-----
> From: Julien Laganier [mailto:julien.ietf@gmail.com]
> Sent: Friday, July 06, 2012 4:00 PM
> To: Retana, Alvaro
> Subject: Fwd: SecDir review of draft-ietf-ospf-prefix-hiding-04
> 
> FYI.
> 
> 
> ---------- Forwarded message ----------
> From: Julien Laganier <julien.ietf@gmail.com>
> Date: Fri, Jul 6, 2012 at 12:44 PM
> Subject: SecDir review of draft-ietf-ospf-prefix-hiding-04
> To: secdir@ietf.org, draft-ietf-ospf-prefix-hiding.all@tools.ietf.org,
> The IESG <iesg@ietf.org>
> 
> 
> 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