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, 06 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
- [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