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

Acee Lindem <acee.lindem@ericsson.com> Sat, 07 July 2012 01:33 UTC

Return-Path: <acee.lindem@ericsson.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 06DD621F85E0; Fri, 6 Jul 2012 18:33:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.532
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stHCpbsGGyTp; Fri, 6 Jul 2012 18:33:14 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE4221F8540; Fri, 6 Jul 2012 18:33:14 -0700 (PDT)
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (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 EUSAACMS0702.eamcs.ericsson.se ([169.254.1.236]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 6 Jul 2012 21:33:23 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: "Retana, Alvaro" <alvaro.retana@hp.com>
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: <16AA6D76-A64E-4191-B874-B4C84EDB286F@ericsson.com>
References: <CAE_dhjvtKqfgJF+vjp1un_672sEZ_gw-6q6N_RsCsYgmrjr36g@mail.gmail.com> <CAE_dhjsgQZoC4_4jJ14JVKrp_ajjOfbbo9iTgp0XsK91mVozDw@mail.gmail.com> <C03AAF38AD209F4BB02BC0A34B774CE70B75F3@G2W2446.americas.hpqcorp.net>
In-Reply-To: <C03AAF38AD209F4BB02BC0A34B774CE70B75F3@G2W2446.americas.hpqcorp.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail-2-392865302"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: "secdir@ietf.org" <secdir@ietf.org>, Yi Yang <yiya@cisco.com>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-ospf-prefix-hiding.all@tools.ietf.org" <draft-ietf-ospf-prefix-hiding.all@tools.ietf.org>, Julien Laganier <julien.ietf@gmail.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: 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. 
Thanks,
Acee 

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