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

[[e-mail]]

Mitchell,

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 ?

Regards
Mukesh