Re: [OSPF] OSPF Information Hiding

Russ White <russ@cisco.com> Wed, 23 February 2011 14:26 UTC

Return-Path: <russ@cisco.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 22E883A6A0D for <ospf@core3.amsl.com>; Wed, 23 Feb 2011 06:26:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.531
X-Spam-Level:
X-Spam-Status: No, score=-10.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 95ec85BsTeJf for <ospf@core3.amsl.com>; Wed, 23 Feb 2011 06:26:16 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 077353A69F8 for <ospf@ietf.org>; Wed, 23 Feb 2011 06:26:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=2587; q=dns/txt; s=iport; t=1298471223; x=1299680823; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=S/HPh8zNozKpeYAHBOF4zYKC12G2nUhHwy0110BnnYs=; b=ceo2QFeJNYGh71ppXrKxuDbAYaQkquCk3rs4UKFHR3XJ+zpimYOhgLcx U8+C7s/Y03IUi5Neydny5/SI+0tTqSbO9LVEMvDNd21aW0zRgu3c7zuKj BnUIRW4Cjoh3ZcWfRWBvVB4eho1QAzVpy8sbNC/SNmk76km9KfWSno60H c=;
X-Files: signature.asc : 259
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAHqoZE1AZnwM/2dsb2JhbACmGXOgQ5t0hV4EhQ2HCYM7
X-IronPort-AV: E=Sophos; i="4.62,212,1297036800"; d="asc'?scan'208"; a="218635240"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Feb 2011 14:27:03 +0000
Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1NER2l5022643; Wed, 23 Feb 2011 14:27:02 GMT
Message-ID: <4D651936.9020206@cisco.com>
Date: Wed, 23 Feb 2011 09:27:02 -0500
From: Russ White <russ@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Acee Lindem <acee.lindem@ericsson.com>
References: <EC96753D-4C19-400C-8717-7B81D6413E50@ericsson.com>
In-Reply-To: <EC96753D-4C19-400C-8717-7B81D6413E50@ericsson.com>
X-Enigmail-Version: 1.1.1
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigFF8272A8A2D315409CDE47F2"
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 14:26:17 -0000

> 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