[nsp-sec] FYI - Cisco IOS XR Software DVMRP Memory Exhaustion Vulnerability

[Dario Ciccarone (dciccaro)]

I don't know enough of multicast and related protocols to ascertain if it is a good idea, a bad idea, or somewhere in the middle. And as we all know, simplicity is the enemy of security and installed base limits what you can do . . . 

So even if we could, we would need to make it "disabled by default", and then a percentage of customers would never become aware of it, and those aware might decide don't have the time to test & make sure it won't break what they have already running, and a long list of other reasons why they wouldn't implement . . . 

But if you think it could be implemented with a reasonable assumption it wouldn't break stuff, or wouldn't affect negatively existing deployments - shoot me an email w/ your proposal, and I'll be happy to open an enhancement request to track it. But as any other enhancement request, it would need to be prioritized - and the most people asking for it, the more likely it would be implemented.

And I would also need to contend with the usual "well, people can deploy ACLs, or limit scope of multicast, or deploy iACLs as they should be doing to protect their infrastructure" and the list goes on and on . . .


On 8/31/20, 9:58 PM, "John Kristoff" <jtk at depaul.edu> wrote:

    On Tue, 1 Sep 2020 01:49:13 +0000
    "Dario Ciccarone (dciccaro)" <dciccaro at cisco.com> wrote:

    > DC> John, I don't know what your experience is like, but each time we
    > DC> talk to customers (or advanced services folks working w/
    > DC> customers, or TAC, or) we hear thinks that we just can't compute.
    > DC> "I don't know my infra addresses", "I don't know if this traffic
    [...]

    You know the 'no ip forward ..." knobs?  There should be one for IGMP
    and it should be off by default.  I think I brought this up before and
    there is probably a reason it is not so easy to implement, but
    intuitively it seems the ideal way to limit IGMP to me.

    John