Re: [lisp] [Ila] LISP for ILA

[Dino Farinacci <[e-mail]>]

> Would it be practical to have the map server, having detected an attack, simply send a cookie back in its reply to the spoofed address and then stop replying for a period of time to the spoofed source address unless subsequent requests from that source address contained the cookie in an opaque LCAF or some other LCAF type? 

Thanks for the comment Paul. A couple points/comments here:

(1) I would hope that the Map-Request doesn’t go all the way to the Map-Server. That is the first time a Map-Request hits the mapping system is at the Map-Resolver node. We probably should put logic there on what is sent along the DDT route or how much is sent to the Map-Server if the Map-Resolver has the EID in the referral-cache. This is just a side comment.

(2) If the Map-Request is being spoofed, it isn’t a problem. When I say spoofed, I mean if the source address in the IP header is spoofed. It turns out the “ITR-RLOC” field in the Map-Request is where the Map-Reply goes to. But it depends what the bad actor looks like. If its a mis-configured spec-compliant xTR, then this could work. If this is a python hacker, it won’t do anything with the responses. Because its sole point is to disrupt the mapping system.

But this reminds me of a funny story a friend told me about 10 years ago when he was sick and tired of receiving physical junk mail at his house. What he did was collect all the junk mail, put it in one big envelope and put his address as the destination and put the source of the junk mail as the sender field. He then went to the post office and dropped it in the bin WITHOUT a stamp. So the heavy package was returned to sender. LOL.  ;-)

So maybe this story could be a solution to the problem. Why don’t we DoS attack the bad actor. Kill its bandwidth and CPU so it can’t attack us?  ;-) Of course the Map-Resolver would have to detect the situation, create a VM to be the attacker and launch it.  ;-)

I don’t know if I’m joking or serious about this. But the cloud providers would love this.  ;-)

Dino