Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01

Hi Manav, see inline

On Wed, Mar 30, 2011 at 12:54 AM, Bhatia, Manav (Manav)
<manav.bhatia@alcatel-lucent.com> wrote:
> Hi Sri,
>
> This is regarding the point that i had raised yesterday - If the routers
> flood the "LSAs" in the data plane without verifying them, then we're
> leaving a hole open for DoS attacks, as any packet masquerading as a
> legitimate OSPF packet will get flooded on all routers. This is different
> from data packets flooding as these packets will be occupying the higest
> priority queues in both the ingress, egress and the CPU.

Control pkts (not restricted to FN) though given high priority, the
good implementations use throttling mechanisms to prevent (D)DoS.
Root-causing of related alarms is also a high priority operational
procedure.

>
> Second, what happens if the control packet is carrying an OSPF
> authentication digest? Would you still flood it without verifying the
> contents or would those be flooded regardless? I guess, you said that it
> would be the former. If thats the case, then this is not easy to do it in
> the HW as you would (i) need to parse the OSPF payload first to determine
> that its carrying a digest (ii) you would then need to verify it, which
> means you would be running HMAC-SHA in HW on the packet (given the Apad
> stuff that we have added in RFC5709 i dont think you can easily do this in
> HW) (iii) once the digest is verified you would need to flood it out on all
> the valid OSPF interfaces.

What I said is that verification before flooding is also an option we
have considered (see draft-lu-fn-transport for details). In our
prototyping experience the overhead of verifying auth in HW was not
much. However we do recognize that this may not be true with all HW
and all auth methods. It may introduce more delays in FN delivery in
some architectures and implementations. So forwarding without
verifying could get better convergence times at the expense of the
invalid FN packet reaching more nodes. If a platform is capable of
verifying without introducing a lot of delay then it should definitely
do it and such a platform can mitigate the problem in the network
where other platforms may not verifying before forwarding.

>
> Cheers, Manav
>
> ________________________________
> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of
> Sriganesh Kini
> Sent: Tuesday, March 29, 2011 9.20 PM
> To: ospf@ietf.org
> Subject: [OSPF] FYI on draft-kini-ospf-fast-notification-01
>
> Just an FYI to the list
>
> This draft
> http://tools.ietf.org/html/draft-kini-ospf-fast-notification-01 was
> presented at the OSPF WG mtg today.
>
> Thanks for the comments/questions at the mic. We will submit a new version
> addressing the comments.
>
> Note that the other drafts related to Fast Notification (FN) are
> draft-lu-fn-transport and draft-lu-fast-notification-framework. These were
> presented in RTGWG.
>
> Thanks
>
> - Sri
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>
>

-- 
- Sri