Hi Sri, > > 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.
I agree that all implementations rate limit all kinds of traffic, but you would concede that limiting is much less aggressive for network control (NC) packets. This also means that a bunch of illegitimate NC packets will actually affect the genuine NC traffic - so you could on certain platforms see 10ms BFD flaps because theres a flood of data-plane forwarded LSAs. Most QoS scheduling algorithms would drain the NC queue first before getting to the other (BE, AF, etc) queues. While the algorithm could change (strict scheduling, WFQ, etc) the end result would still be the same, where NC packets would *affect* other queues/traffic. Thus my point is that we should be extremely circumspect with any proposal that unabashedly floods control traffic. > > > > > 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 I can say with a very high degree of confidence that most, if not all, ASIC based silicons will not be able to do the HMAC-SHA kind of authentication verification that has been proposed in RFC 5310, RFC 5709, RFC 4822 and scores of other IETF routing drafts on BFD, LDP, etc. > some architectures and implementations. So forwarding without > verifying could get better convergence times at the expense of the > invalid FN packet reaching more nodes. .. and potentially flapping BFD and other control plane protocols. > 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. Yes, but that cant happen today. Cheers, Manav _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
