Re: draft-ietf-ospf-ospfv3-auth-04.txt

Mukesh.Gupta@NOKIA.COM Fri, 09 July 2004 21:52 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 RAA04215 for <ospf-archive@LISTS.IETF.ORG>; Fri, 9 Jul 2004 17:52:25 -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 <14.00E0DB30@cherry.ease.lsoft.com>; Fri, 9 Jul 2004 17:52:25 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25256726 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 9 Jul 2004 17:52:23 -0400
Received: from 131.228.20.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 9 Jul 2004 17:52:23 -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 i69LqMA26409 for <OSPF@PEACH.EASE.LSOFT.COM>; Sat, 10 Jul 2004 00:52:22 +0300 (EET DST)
X-Scanned: Sat, 10 Jul 2004 00:51:49 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i69LpnBB011850 for <OSPF@PEACH.EASE.LSOFT.COM>; Sat, 10 Jul 2004 00:51:49 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00mNh2CT; Sat, 10 Jul 2004 00:51:47 EEST
Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i69Lpkn04939 for <OSPF@PEACH.EASE.LSOFT.COM>; Sat, 10 Jul 2004 00:51:46 +0300 (EET DST)
Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 9 Jul 2004 16:51:45 -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: draft-ietf-ospf-ospfv3-auth-04.txt
Thread-Index: AcRlC/eTRcHCWO7nQISLwujGTe1CxgA7/2lw
X-OriginalArrivalTime: 09 Jul 2004 21:51:45.0374 (UTC) FILETIME=[ED7D7FE0:01C465FE]
Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79A8E@daebe009.americas.nokia.com>
Date: Fri, 9 Jul 2004 16:51:45 -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: draft-ietf-ospf-ospfv3-auth-04.txt
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: quoted-printable

Mitchell,

Comments inline..

> > Do you still think that we should mention it everywhere in the
> > draft that the pkts will be dropped by the IPsec layer ?  Or
> > we should clarify it more in section 2 and make it explicit
> > that whenever we say "drop the pkt", it means it is dropped
> > by the IPsec layer ?
> 
>         IMO, Minimally it should be explicitly stated.

Ok we will try to make it explicit in the next version.

> > By the way, isn't it the way we handle authentication in OSPFv2 ?
> > If you don't have any authentication and FULL adjacency between
> > the neighbors and then you change the configuration of one of
> > the neighbors to use simple/md5 authentication, the adjacency
> > is not torn down immediately.  It takes the dead interval time
> > before each of them mark the adjacency down.
> 
>         First, what we are dealing here is online reconfiguration
>         or dynamic reconfiguration. I haven't seen really any
>         discussion in 2328, wrt changing values after 2-ways/
>         adjs are established.

I haven't seen anything either.  I tried our implementation
and reported the findings.

Are there any implementations that will tear down the adjacency
immediately when the authentication method is changed ?

>         IMO, I have two very different ways of thinking about this.
> 
>         #1 If a field within a pkt is changed that "forces" the
>          link partner to now drop the pkt, the router dead
>          interval time frame is a built in latency period to
>          re-establish re-synchronization of the values. However,
>         this allows data movement accross the adj, where the
>         adj REALLY is no longer valid / synchronized. In addition,
>         if another router duplicates anothers router-id, but
>         changes one required synchronized value, to invalidate
>         the pkt, and this one pkt causes the adj to be dropped,
>         it could be a DOS type attack.
> 
>         #2 To properly achieve "Faster Failure Detection",
>         IMO Guyal, et al, should have considered the reception
>         of a NOW invalid pkt. This would eliminate the router
>         dead interval delay in tearing down the adj.
> 
>         It is the delay's / latencies that are built in
>         tearing down a now no longer valid adj.
> 
>         So, we should be leaning from OSPFv2 the behaviours
>         that we don't want in v3, and attempt to remove them
>         versus forcing us to live with our past ?mistakes? for
>         consistency sakes. Thus, IMO, if authentication is
>         CHANGED locally the adj should be torn down immediately,
>         and the reception of a pkt that would cause it to be
>         dropped by the recvr, should effect the state of the
>         adj. BTW, this should be only one of many fields that
>         should effect the state of the adj. Don't we have to assume
>         that the adj is going to fail anyway? Is the reception
>         of a hello pkt that will be dropped repeatedly,
>         the first indication that the nbr is no longer reachable?
>         I think yes. Thus, it is a valid nbr state machine event
>         to the down state. However, since it is so drastic,
>         I assume that a CLI command should allow this event.

The current behavior is actually helpful during the configuration 
changes.  Consider the scnerio when an admin is transitioning the
OSPF (v2 or v3) network from "no authentication" to "simple 
authentication".  Because of the current behavior, he/she gets 
enough time to change the configuration on all the routers without 
bringing the network (or data forwarding) down.  If the router
tears down the adjacency immediately, there will be a forwarding
break in this case.

IMHO, it is not worth tearing down the adjacency when the admin
makes this configuration change just to notify him/her for some
incorrect configuration.  If the configuration is incorrect
(mismatching authentication types on routers), the admin will
know within minutes anyway.

Regards
Mukesh