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

[Erblichs <[e-mail]>]

        Inline.

        Mitchell Erblich

[e-mail] wrote:
>
> Acee/Mitchell,
>
> Comments inline..
>
> > > Ace, et al,
> > >
> > >         I realize that this is a late comment..
> > >
> > >         Section 3. Authentication
> > >
> > >                 But this really applies throughout
> > >                 this doc.
> > >
> > >       "OSPF packets recieved ... MUST be dropped ..."
> > >
> > >         Their is no mention that I have seen that identifies
> > >         an appropriate MISMATCH message that allows the
> > >         recv'r administrator to correct this or other bad
> > >         configurations.
> > >
> > I don't think we should try and standardise logging and/or
> > log throttling mechanisms. The OSPFv2 MIB does define an
> > ospfIfAuthFailure trap and I would imagine that when traps
> > are added to the OSPFv3 MIB, this one would be included.
> > It might be ok to say add a general statement saying that there
> > should be some type of local auth failure notification and that
> > it would be a good idea to throttle them.
>
> I don't think OSPFv3 MIB could include this trap.  As the packets
> are being dropped by IPsec before they even reach OSPF, OSPF is
> not going to know about the packets being dropped.
>

        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.


> The point that I am not able to understand is that how is it
> possible that some packets will be dropped and the others will
> not be ?  If the keys are matching then all the packets will
> be delivered to OSPF.  If there is a mismatch in the keys,
> all the packets will be dropped by the IPsec.  The OSPF
> adjacency will be down in the mismatch case so the admin
> will definitely know about that :)
>
> > >         Also, can a OSPF router sychronize
> > >         or update its database with another router if a
> > >         percentage of its packets are dropped?
> >
> > It depends on the percentage.
> >
> > >
> > >         I keep on thinking that dropped msgs of this type
> > >         need to be tracked and as much information should
> > >         be logged about the xmit'er of the MISMATCHED pkt.
> > >
> > >         What happens if some OSPF packets are dropped from
> > >         a router and others are accepted?
> >
> > It depends on which packets :^)
>
> Again when do you expect to see a percentage of the pkts
> being dropped ?
>
> > >         Thus, I would think and this is a bit extreme, if
> > >         a OSPF packet is recieved that has a mismatch in
> > >         any encryption or authentication field(s) from the
> > >         xmit router, the adjacency or its 2-way link status
> > >         should be dropped. The router can not be a trusted
> > >         router if some of its packets are untrusted and/or
> > >         its contents are unknown. Can it?
> > >         Yes, this is assuming that the router-id is known.
> >
> > I disagree. Authentication should be done on a packet by packet
> > basis without OSPF trying to maintain any state other than what is
> > maintained by IPSEC itself.
>
> I also disagree.  First of all I am not able to understand
> the situation in which some of the packets are being dropped
> and some of them are being delivered to OSPF.
>

        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.
> Regards
> Mukesh

[e-mail] wrote:
>
> Acee/Mitchell,
>
> Comments inline..
>
> > > Ace, et al,
> > >
> > >         I realize that this is a late comment..
> > >
> > >         Section 3. Authentication
> > >
> > >                 But this really applies throughout
> > >                 this doc.
> > >
> > >       "OSPF packets recieved ... MUST be dropped ..."
> > >
> > >         Their is no mention that I have seen that identifies
> > >         an appropriate MISMATCH message that allows the
> > >         recv'r administrator to correct this or other bad
> > >         configurations.
> > >
> > I don't think we should try and standardise logging and/or
> > log throttling mechanisms. The OSPFv2 MIB does define an
> > ospfIfAuthFailure trap and I would imagine that when traps
> > are added to the OSPFv3 MIB, this one would be included.
> > It might be ok to say add a general statement saying that there
> > should be some type of local auth failure notification and that
> > it would be a good idea to throttle them.
>
> I don't think OSPFv3 MIB could include this trap.  As the packets
> are being dropped by IPsec before they even reach OSPF, OSPF is
> not going to know about the packets being dropped.
>
> The point that I am not able to understand is that how is it
> possible that some packets will be dropped and the others will
> not be ?  If the keys are matching then all the packets will
> be delivered to OSPF.  If there is a mismatch in the keys,
> all the packets will be dropped by the IPsec.  The OSPF
> adjacency will be down in the mismatch case so the admin
> will definitely know about that :)
>
> > >         Also, can a OSPF router sychronize
> > >         or update its database with another router if a
> > >         percentage of its packets are dropped?
> >
> > It depends on the percentage.
> >
> > >
> > >         I keep on thinking that dropped msgs of this type
> > >         need to be tracked and as much information should
> > >         be logged about the xmit'er of the MISMATCHED pkt.
> > >
> > >         What happens if some OSPF packets are dropped from
> > >         a router and others are accepted?
> >
> > It depends on which packets :^)
>
> Again when do you expect to see a percentage of the pkts
> being dropped ?
>
> > >         Thus, I would think and this is a bit extreme, if
> > >         a OSPF packet is recieved that has a mismatch in
> > >         any encryption or authentication field(s) from the
> > >         xmit router, the adjacency or its 2-way link status
> > >         should be dropped. The router can not be a trusted
> > >         router if some of its packets are untrusted and/or
> > >         its contents are unknown. Can it?
> > >         Yes, this is assuming that the router-id is known.
> >
> > I disagree. Authentication should be done on a packet by packet
> > basis without OSPF trying to maintain any state other than what is
> > maintained by IPSEC itself.

        If the state is done independently, and the above scenario
        occurs, are we incurring a penalty of lost packets, routing
        loops, etc, just because we have moved the auth / encrypt
        checks outside of OSPF and don't inform OSPF?

>
> I also disagree.  First of all I am not able to understand
> the situation in which some of the packets are being dropped
> and some of them are being delivered to OSPF.
>
> Regards
> Mukesh