Re: Comments on draft-lindem-ospfv3-dest-filter-01.txt

Mukesh.Gupta@NOKIA.COM Wed, 12 May 2004 17:10 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27352 for <ospf-archive@LISTS.IETF.ORG>; Wed, 12 May 2004 13:10:21 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00DA46E9@cherry.ease.lsoft.com>; Wed, 12 May 2004 13:10:19 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 16289512 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 May 2004 13:10:17 -0400
Received: from 131.228.20.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 May 2004 13:10:17 -0400
Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4CHAFk17197 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 12 May 2004 20:10:16 +0300 (EET DST)
X-Scanned: Wed, 12 May 2004 20:10:07 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE
Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i4CHA739016467 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 12 May 2004 20:10:07 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00pyYudY; Wed, 12 May 2004 20:10:06 EEST
Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4CHA5H01563 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 12 May 2004 20:10:05 +0300 (EET DST)
Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 12 May 2004 12:09:25 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Topic: Comments on draft-lindem-ospfv3-dest-filter-01.txt
Thread-Index: AcQ3yNfBEQX8C5eEQamIOBb20AevXwAetsbA
X-OriginalArrivalTime: 12 May 2004 17:09:25.0353 (UTC) FILETIME=[E07DED90:01C43843]
Message-ID: <8D260779A766FB4A9C1739A476F84FA4015475DA@daebe009.americas.nokia.com>
Date: Wed, 12 May 2004 12:09:25 -0500
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Mukesh.Gupta@NOKIA.COM
Subject: Re: Comments on draft-lindem-ospfv3-dest-filter-01.txt
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: quoted-printable

Hi Acee,

> It's true the same could be accomplished with one or more
> ACL(s). However, if the same approach is taken for every
> protocol/service one could end up having to configure and maintain
> quite an extensive administrative ACL (i.e., an ACL applied to packets
> to be delivered locally as opposed to all packets received on 
> an interface).
> One thing that started us thinking about the problem and the 
> elegance of
> simply rejecting all packets without a link-local destination 
> was the OSPF
> vulnerabilities work going on in the RPSEC group. With that 
> work in mind, it
> seemed natural to have a single mechanism built into OSPFv3. 
> One could use
> a knob (so you'd know whether or not virtual link could be 
> configured) or simply
> always have the check in force when no virtual links are 
> configured at the
> level of application. Finally, dependent on the implemenation 
> and where/how
> the ACL(s) is/are applied this solution could be cheaper and 
> simpler (I know I've
> opened myself up to all of those who are going to tell me how 
> well they've
> implemented their ACLs ;^).

Sounds reasonable to me.  I don't see any harm in publishing
this document.  What is the status that this document is 
seeking ?  Informational or BCP ?

Regards
Mukesh