Re: [OSPF] OSPF Information Hiding

Acee Lindem <acee.lindem@ericsson.com> Wed, 23 February 2011 15:02 UTC

Return-Path: <acee.lindem@ericsson.com>
X-Original-To: ospf@core3.amsl.com
Delivered-To: ospf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B6E23A6A28 for <ospf@core3.amsl.com>; Wed, 23 Feb 2011 07:02:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.369
X-Spam-Level:
X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1D1h9eSqpkG for <ospf@core3.amsl.com>; Wed, 23 Feb 2011 07:02:51 -0800 (PST)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 5EE243A68E0 for <ospf@ietf.org>; Wed, 23 Feb 2011 07:02:47 -0800 (PST)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p1NFoZwI015219; Wed, 23 Feb 2011 09:50:37 -0600
Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.224]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 23 Feb 2011 10:03:27 -0500
From: Acee Lindem <acee.lindem@ericsson.com>
To: Russ White <russ@cisco.com>
Date: Wed, 23 Feb 2011 10:03:24 -0500
Thread-Topic: [OSPF] OSPF Information Hiding
Thread-Index: AcvTatK0KV7R5ccSTWafW8hmunBjsg==
Message-ID: <1B04BA90-6619-4CD9-9BFC-C66B833FE655@ericsson.com>
References: <EC96753D-4C19-400C-8717-7B81D6413E50@ericsson.com> <4D651936.9020206@cisco.com>
In-Reply-To: <4D651936.9020206@cisco.com>
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-10-191141611"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Cc: "ospf@ietf.org" <ospf@ietf.org>
Subject: Re: [OSPF] OSPF Information Hiding
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Feb 2011 15:02:52 -0000

Hi Russ, 

OSPFv2, as specified in RFC 2328, states that a multi-access network's subnet is specified by the DR's Network-LSA LSID/mask and installed during the SPF graph traversal. Hence, without some form of signaling, there is no way to prevent other routers in the OSPF area from installing the subnet route (whether or not it is really needed for any purpose in the OSPF network deployment). 

Thanks,
Acee


On Feb 23, 2011, at 9:27 AM, Russ White wrote:

> 
>> Given all the discussions on OSPFv2 security, we've neglected discussion on some of the other drafts. Please send you views, positive, or negative, as to whether or not this draft should be a WG document. 
> 
> I have some questions on 2.2.2.1...
> 
> ==
>   To hide a transit-only broadcast network, a special network mask
>   value 255.255.255.255 MUST be used in the network LSA.  While a
>   broadcast network connects more than routers, using 255.255.255.255
>   will not hide an access broadcast network accidentally.
> ==
> 
> I'm never really "happy" with "magic numbers" like this... I know we are
> forced to resort to them from time to time, but I think avoidance is the
> better part of design, if possible.
> 
> With that in mind --do we really need it? In an SPF from "off link,"
> doesn't a broadcast link really just look like a bunch of point to
> points (hub and spoke), on which all the routers are attached to the
> same ip subnet? Why, if so, do we actually need the connection to the
> shared broadcast network off link, if so? IE, the TWCC should be running
> id-to-id across the apparent point-to-points, and routers off link don't
> much care about the shared broadcast network in the middle.
> 
> On link, we care about the shared broadcast link (to make certain we're
> actually on the same IP subnet to go full), but that's not carried in
> the type 2, and the trick of representing this as a host route would
> break that anyway (if we were relying on it).
> 
> So I'm not certain we even need the magic number here. Just advertise
> the connection to the other routers as p-2-p in the type 2 (by the DR),
> and advertise the p-2-p connection in the type 1 from all the other
> routers on the link, and you're done (?)... You can just pull the
> attached subnet out, like you would with a type 1?
> 
> Thoughts?
> 
> :-)
> 
> Russ
> 
> 
> 
> 
>