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

Acee Lindem <> Sat, 07 July 2012 01:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06DD621F85E0; Fri, 6 Jul 2012 18:33:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.532
X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id stHCpbsGGyTp; Fri, 6 Jul 2012 18:33:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3DE4221F8540; Fri, 6 Jul 2012 18:33:14 -0700 (PDT)
Received: from ([]) by (8.13.8/8.13.8) with ESMTP id q671XOA4002421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Jul 2012 20:33:25 -0500
Received: from ([]) by ([]) with mapi; Fri, 6 Jul 2012 21:33:23 -0400
From: Acee Lindem <>
To: "Retana, Alvaro" <>
Date: Fri, 6 Jul 2012 21:33:21 -0400
Thread-Topic: SecDir review of draft-ietf-ospf-prefix-hiding-04
Thread-Index: Ac1b4H9T1NGStHs7S7Sp+FR2GPic9Q==
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail-2-392865302"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: "" <>, Yi Yang <>, "" <>, "" <>, Julien Laganier <>, 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: Sat, 07 Jul 2012 01:33:15 -0000

Actually, with this draft, the OSPF LSAs do not necessarily contain any IP addresses - only topology information. The OSPF Router ID certainly doesn't have to be a routable IP address and can be explicitly configured to avoid the default of configured address selection supported by most implementations. 

On Jul 6, 2012, at 4:50 PM, Retana, Alvaro wrote:

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