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

[Erblichs <[e-mail]>]

Mukesh,

        Inline...

        Mitchell
        -------

[e-mail] wrote:
>
> 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 ?

        IMO, Minimally it should be explicitly stated.
>
> >        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.

        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.

        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.

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