IETF Logo Mail Archive

Re: [Isis-wg] (no subject)

Tony Li <tony.li@tony.li> Wed, 14 April 2004 23:22 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05252 for <isis-wg-archive@odin.ietf.org>; Wed, 14 Apr 2004 19:22:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDtdr-0004OJ-M8 for isis-wg-archive@odin.ietf.org; Wed, 14 Apr 2004 19:18:04 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ENI38Z016879 for isis-wg-archive@odin.ietf.org; Wed, 14 Apr 2004 19:18:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDtZj-0003DX-OV for isis-wg-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 19:13:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04953 for <isis-wg-web-archive@ietf.org>; Wed, 14 Apr 2004 19:13:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDtZi-0004f0-00 for isis-wg-web-archive@ietf.org; Wed, 14 Apr 2004 19:13:46 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDtYp-0004cT-00 for isis-wg-web-archive@ietf.org; Wed, 14 Apr 2004 19:12:52 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDtYY-0004Z6-00 for isis-wg-web-archive@ietf.org; Wed, 14 Apr 2004 19:12:34 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDtSE-0001Af-Hd; Wed, 14 Apr 2004 19:06:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDtQ0-0000er-TS for isis-wg@optimus.ietf.org; Wed, 14 Apr 2004 19:03:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04604 for <isis-wg@ietf.org>; Wed, 14 Apr 2004 19:03:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDtPx-0004B4-00 for isis-wg@ietf.org; Wed, 14 Apr 2004 19:03:41 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDtP2-00049F-00 for isis-wg@ietf.org; Wed, 14 Apr 2004 19:02:45 -0400
Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx with esmtp (Exim 4.12) id 1BDtOe-00044s-00 for isis-wg@ietf.org; Wed, 14 Apr 2004 19:02:20 -0400
Received: from [192.168.1.3] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (rwcrmhc12) with SMTP id <20040414230145014001c4k4e>; Wed, 14 Apr 2004 23:01:46 +0000
In-Reply-To: <200404141800.XAA12664@WS0005.indiatimes.com>
References: <200404141800.XAA12664@WS0005.indiatimes.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <B196CF13-8E67-11D8-BC33-000A95D1475E@tony.li>
Content-Transfer-Encoding: 7bit
Cc: isis-wg@ietf.org
From: Tony Li <tony.li@tony.li>
Subject: Re: [Isis-wg] (no subject)
To: appallar <appallar@indiatimes.com>
X-Mailer: Apple Mail (2.613)
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/isis-wg/>
Date: Wed, 14 Apr 2004 16:01:41 -0700
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

We tried to explain this in the authentication RFC.  If there is no body
to the LSP, then you can't really have authentication.  And without 
authentication, this gives folks a trivial way to attack you.  
Therefore, you MUST retain some portion of the body and, when 
authentication is enforced, you must ignore 0 age LSPs that have no 
body.

The system generating a 0 age LSP can either then retain the entire 
body of the LSP or remove the body and recalculate the authentication.  
Either is acceptable.

Tony



On Apr 14, 2004, at 11:31 AM, appallar wrote:

>  Hello,  When an LSP ages out, should the checksum recalculated and 
> modified, or left unmodified? as per ISO 10589, check sum should not 
> be modified. In section 7.3.16.4, "Note 32" says a check of the 
> checksum succeeds even though the data portion is not present. How 
> about the authentication part? do an implementation keep 
> authentication while aging LSPs? and if authentication information is 
> present, how does checksum succeeds? as per RFC 3719, if the checksum 
> errors found, the LSPs are dropped, so do all implementations check 
> Remaining life time before check sum??  Thanks in advance, 
> Suryanarayana
> Indiatimes Email now powered by APIC Advantage. Help!
> <image.tiff>Help
> Click on the image to chat with me


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg

v2.46.0 | Report a Bug | By Email | System Status