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

Acee Lindem <acee@REDBACK.COM> Thu, 13 May 2004 20:20 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 QAA10743 for <ospf-archive@LISTS.IETF.ORG>; Thu, 13 May 2004 16:20:44 -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 <6.00DA7B29@cherry.ease.lsoft.com>; Thu, 13 May 2004 16:20:43 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 16472134 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 13 May 2004 16:20:16 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 13 May 2004 16:20:16 -0400
Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 95234A44CAF for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 13 May 2004 13:20:14 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08131-06 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 13 May 2004 13:20:14 -0700 (PDT)
Received: from aceeinspiron (unknown [172.31.253.186]) by prattle.redback.com (Postfix) with SMTP id 6D5CAA44CAD for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 13 May 2004 13:20:13 -0700 (PDT)
References: <8D260779A766FB4A9C1739A476F84FA4015475DA@daebe009.americas.nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Virus-Scanned: by amavisd-new at redback.com
Message-ID: <058801c43927$aeadf3c0$0202a8c0@aceeinspiron>
Date: Thu, 13 May 2004 16:20:05 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Comments on draft-lindem-ospfv3-dest-filter-01.txt
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Mukesh,
I guess I'd put the question of status to the WG and it
depends on how useful everyone thinks it is. I'm also
going to post it to the RPSEC WG since I believe they've
accepted OSPF Vulnerabilities draft.

Thanks,
Acee

----- Original Message -----
From: <Mukesh.Gupta@NOKIA.COM>
To: <OSPF@PEACH.EASE.LSOFT.COM>
Sent: Wednesday, May 12, 2004 1:09 PM
Subject: Re: Comments on draft-lindem-ospfv3-dest-filter-01.txt


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