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
>
>  
>