> |I don't see why we can't enforce anti-spoofing on encap, since it > |requires a mapping to be in place. And we can on decap easily where > |the traffic is symmetrical (that is there is a mapping for the source
> |RLOC/EID pair. > > > Ok, but what about asymmetric decap? As some one I know in the Industry likes to say 'there is no free lunch here' ;-) > That implies that the > ETR does a mapping lookup on the receipt of a packet, buffers > the packet until the lookup succeeds, and the does the > compare. Oh you mean like the IPv6 neighbor discovery process!? >This seems like another fine way of DoSing the ETR. > Of course, so implementation has to be smart. If the outer header isn't spoofed, and the inner is, its trivial to find the culprit. Once you've determined the offending site, you have a whole lot of interesting options - including using the control plane to inform that site that he's dos'ing you and asking it to stop, or building an ACL to block that particular source. Post decap, this spoofing is no different than what we have today. If he outer header and inner header source are both spoofed, and the flows are asymmetrical, I'd suspect you need to have an implementation that can do something like 1) turn on some sort of verification function and drop packets while it waits to verify them or 2) simply pass the decapsulated traffic to some ddos scrubbing box like you'd do with any spoofed attack today. The key, as you point out, is simply that the implementation doesn't allow itself to be dos'd by traffic. And this goes for encap/caching as well as decap. Regards, -Darrel _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
