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

Mukesh.Gupta@NOKIA.COM Wed, 07 July 2004 20:44 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id QAA16347 for <ospf-archive@LISTS.IETF.ORG>; Wed, 7 Jul 2004 16:44:13 -0400 (EDT)
Received: from ( by (LSMTP for Digital Unix v1.1b) with SMTP id <>; Wed, 7 Jul 2004 16:44:14 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24921734 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 7 Jul 2004 16:44:11 -0400
Received: from by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 7 Jul 2004 16:44:07 -0400
Received: from ( []) by (Switch-2.2.8/Switch-2.2.8) with ESMTP id i67Ki6J19298 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 7 Jul 2004 23:44:06 +0300 (EET DST)
X-Scanned: Wed, 7 Jul 2004 23:43:20 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost) by (8.12.9/8.12.9) id i67KhKrS016526 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 7 Jul 2004 23:43:20 +0300
Received: from ( by 004aidYd; Wed, 07 Jul 2004 23:43:18 EEST
Received: from ( []) by (Switch-2.2.8/Switch-2.2.8) with ESMTP id i67KhHu07815 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 7 Jul 2004 23:43:17 +0300 (EET DST)
Received: from ([]) by with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jul 2004 15:42:07 -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: AcRkTaYiwtuqeTK+RseaN7lJUFIwHgACeqZQ
X-OriginalArrivalTime: 07 Jul 2004 20:42:07.0216 (UTC) FILETIME=[DE49AF00:01C46462]
Message-ID: <>
Date: Wed, 7 Jul 2004 15:42:06 -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
Precedence: list
Content-Transfer-Encoding: quoted-printable


See inline..
>        IMO, the current above sentance implies that the OSPF
>        layer is dropping the MISMATCHED packets. If IP
>        is actually dropping ALL of the mismatched pkts,
>        then I would think that the sentance could be changed
>        to add something like this:
>        OSPF packets recieved in clear text or with incorrect
>        AH integrity Check value (ICV) MUST be dropped when
>        authentication enabled. This layer, which is below the
>        OSPF code, will transparently drop all all the above
>        packets that would have been recieved by OSPF.

Now I understand your concern.  The basic assumption in the
draft is that all the packets are dropped by the IPsec layer 
and none of the unauthenticated pkts reach OSPF.  This 
assumption is mentioned in section 2.

The text that you mentioned "OSPF packets received in clear ..
.. MUST be dropped when authentication is enabled." is assuming
that they are dropped by the IPsec layer as always.

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 ?

>        Mukesh and Acee, the SIMPLEST scenario that I can think of
>        is the acceptance of 100% OSPF control pkts, a admin who
>        performs a CLI change that changes the config and now all
>        OSPF pkts are dropped.
>        In this scenario, if ALL MISMATCH checks are done and
>        acted upon transparently, it would take a min of hello
>        interval times the hello multiplier before the 2-way
>        or adj is dropped by the link partner.
>        I thought we were going to a lower latency detection
>        of changed adjs or 2-ways.
>        And the worst cases IMO, is when the periodic hellos
>        are surpressed, as in the case of demand circuits, I believe
>        that incorrect routing can occur for up to 1 hour
>        in these cases, if the above auth/encrypt MISMATCH drop
>        is done transparently in a layer other than OSPF.
>        IMO, if the MISMATCH drop is currently done
>         transparently then some arch change needs to be done
>         to remove or minimize these delayed effects.
>        Lastly, I just wanted to see if anyone has the same
>        concerns about this possible Very Long Convergence
>        time frame due to a simple incorrect change by a
>        admin.

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.

If we are ok with that behavior in OSPFv2, why should we have
any problems for OSPFv3 ?