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

"Retana, Alvaro" <> Fri, 06 July 2012 20:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B8CBE11E810C; Fri, 6 Jul 2012 13:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -109.299
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1JC8TnhBvgDo; Fri, 6 Jul 2012 13:51:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DB5F711E80DE; Fri, 6 Jul 2012 13:51:24 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CED63842C; Fri, 6 Jul 2012 20:51:41 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 6 Jul 2012 20:50:20 +0000
Received: from ([]) by ([fe80::2d8c:5671:edf9:26b0%12]) with mapi id 14.02.0283.003; Fri, 6 Jul 2012 20:50:20 +0000
From: "Retana, Alvaro" <>
To: Julien Laganier <>
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: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
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: "" <>, "" <>, "" <>, Yi Yang <>, Abhay Roy <>
Subject: Re: [secdir] SecDir review of draft-ietf-ospf-prefix-hiding-04
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Jul 2012 20:51:26 -0000



[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.



> -----Original Message-----
> From: Julien Laganier []
> 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 <>
> Date: Fri, Jul 6, 2012 at 12:44 PM
> Subject: SecDir review of draft-ietf-ospf-prefix-hiding-04
> To:,,
> The IESG <>
> 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