IETF Logo Mail Archive

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

Mukesh.Gupta@NOKIA.COM Thu, 13 May 2004 21:50 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 RAA18788 for <ospf-archive@LISTS.IETF.ORG>; Thu, 13 May 2004 17:50:12 -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 <16.00DA7F90@cherry.ease.lsoft.com>; Thu, 13 May 2004 17:50:12 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 16479771 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 13 May 2004 17:50:10 -0400
Received: from 131.228.20.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 13 May 2004 17:50:10 -0400
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4DLo9H12919 for <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 14 May 2004 00:50:09 +0300 (EET DST)
X-Scanned: Fri, 14 May 2004 00:49:36 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE
Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4DLnaYG006765 for <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 14 May 2004 00:49:36 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00vL0zPf; Fri, 14 May 2004 00:49:35 EEST
Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4DLnUH24771 for <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 14 May 2004 00:49:30 +0300 (EET DST)
Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 13 May 2004 16:48:53 -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: AcQ5J86BfUzmYxI/T6Wuh7+0cigVdwADBg6Q
X-OriginalArrivalTime: 13 May 2004 21:48:53.0356 (UTC) FILETIME=[1569E2C0:01C43934]
Message-ID: <8D260779A766FB4A9C1739A476F84FA4015475EE@daebe009.americas.nokia.com>
Date: Thu, 13 May 2004 16:48:53 -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

I would go for informational.  That is just my opinion
ofcourse.

Posting it to rpsec definitely is a good idea.

Regards
Mukesh

> -----Original Message-----
> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext
> Acee Lindem
> Sent: Thursday, May 13, 2004 1:20 PM
> To: OSPF@PEACH.EASE.LSOFT.COM
> Subject: Re: Comments on draft-lindem-ospfv3-dest-filter-01.txt
> 
> 
> 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
>

v2.23.0 | Report a Bug | By Email