Re: NSSA summarization
sujay <sujayg@HUAWEI.COM> Tue, 16 August 2005 05:15 UTC
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4tnd-000439-Ds for ospf-archive@megatron.ietf.org; Tue, 16 Aug 2005 01:15:45 -0400
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 BAA07273 for <ospf-archive@LISTS.IETF.ORG>; Tue, 16 Aug 2005 01:15: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 <2.010CD491@cherry.ease.lsoft.com>; Tue, 16 Aug 2005 1:15:43 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82691687 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 01:15:42 -0400
Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 16 Aug 2005 01:15:41 -0400
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILA00822UXBRO@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 13:22:23 +0800 (CST)
Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILA006VAUXAY0@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 13:22:23 +0800 (CST)
Received: from dell60 ([10.18.4.207]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ILA00F0UV2DA5@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 13:25:26 +0800 (CST)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook, Build 10.0.4024
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Message-ID: <002c01c5a221$95c0fb00$cf04120a@china.huawei.com>
Date: Tue, 16 Aug 2005 10:45:57 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: sujay <sujayg@HUAWEI.COM>
Subject: Re: NSSA summarization
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <43016ECA.2070204@netd.com>
Precedence: list
Content-Transfer-Encoding: 7bit
As there is now a single type-5 lsa to represent both the exact match as well as all the LS-id's falling under the summary-address range, in my opinion the metric/path-type etc. should follow section 4.1(2). Regds, ~Sujay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Ajay Thakur Sent: Tuesday, August 16, 2005 10:13 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: NSSA summarization Hi all, I have some more queries in OSPF - NSSA area. Suppose I am summarizing type-7 LSAs. In this case while generating type-5 lsa we follow section 4.1 of rfc 1587, e.g. 1> If none of the LSA's LS-Id matches to my summary-address range but LS-Id falls under configured summary address range, then we generate type-5 as per rfc 1587 -section 4.1 (2) and 2> If my LSA has LS-Id equal to summary address range then we generate type-5 lsa as per rfc 1587 section-4.1(1) Now my question is , What happens if ospf database has one LSA with LS-Id matches to my summary-address range and some LSAs with LS-Id falling under summary-address range. Then in this case what type of metric or path-type we should set in the type-5 lsa? Need your help, Thanks, with regards ajay Vishwas Manral wrote: >Hi Acee, > > > >>Acee: In practice, for OSPFv2 the sequence numbers are not monotically >>increasing; Usage of router's clock for cryptographic sequence number >>generation reduces the chance for replay attacks across restarts. >>?: OSPF spec does not say it ... >> >> >Acee, what I meant was that although the OSPF spec does not state that >we need to use clocks. > >I think the vulnerabilities draft is the right place to state the >problems that can happen if we do not use a clock (or something >equivalent which increments even when a system goes down). > >Another issue is that even if the sender uses clock for the "sequence >number" and goes down, all the packets of a previous session can still >be replayed by another router. So the chance of replay attacks is still >there. > >Thanks, >Vishwas >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Monday, August 15, 2005 7:50 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: OSPF WG Minutes > >Attached are the minutes from the Paris OSPF WG meeting. Thanks to >Dimitri for taking them. > >Acee > > >
- OSPF WG Minutes Acee Lindem
- Re: OSPF WG Minutes Vishwas Manral
- NSSA summarization Ajay Thakur
- Re: NSSA summarization sujay
- Re: OSPF WG Minutes Acee Lindem
- Re: OSPF WG Minutes Vishwas Manral
- Re: OSPF WG Minutes ashok
- Re: OSPF WG Minutes Paul Jakma
- [OSPF] OSPF WG Minutes Acee Lindem
- Re: [OSPF] OSPF WG Minutes Vishwas Manral
- Re: [OSPF] OSPF WG Minutes Acee Lindem
- [OSPF] OSPF WG Minutes Acee Lindem
- Re: [OSPF] OSPF WG Minutes Acee Lindem (acee)
- [OSPF] OSPF WG Minutes Acee Lindem (acee)
- Re: [OSPF] OSPF WG Minutes Shraddha Hegde