Sorry for my silence but I have caught up on this really good thread.
I think everyone is learning from each other as well as being
challenged. This is goodness.
To mitigate the DoS attack problem on filling up an ITR cache, uRPF
can be done at these places in the network:
(1) At the ITR
(2) At the PE router connecting the site's ITR to the service provider
PE
(3) At the ETR
(4) At a firewall router anywhere in the path.
I believe (3) and (4) shared the same disadvantages. Many have
mentioned doing it at the ETR. It can be done there but it requires
more work and in my opinion it is done too late in the data path.
Ditto for a firewall at the destination site.
The best place is (1) and if you have a non-compromised ITR but
compromised hosts, the ITR will drop packets that come from a spoofed
EID. Today, if an ITR gets a packet from a source at the site where it
does not match its EID-prefixes it will forward the packet natively
because it thinks the packet is coming from an RLOC and going to
either a non-LISP or LISP site (the destination doesn't matter for
this discussion). We need to support this because a site might be
partially converted to LISP so some hosts are assigned EIDs but others
are not.
When an ITR is configured with "LISP-based uRPF checking", and is a
fully converted to a LISP site, it can drop packets before ever
leaving the site. This way an EID-prefix associated with a locator-set
is consistent for any packets leaving the site. And that mapping is
the same mapping registered to the mapping database system. The
destination sites will not have to participate in the solution and
won't have to do mapping database lookups during decapsulation (and
therefore don't have to fill their cache up for uRPF reasons).
If we wanted cooperation from the service provider, the PE router
could look deeper into the packet to verify the source EID in the
packet is from a customer that owns it. This would require
configuration of EID-prefixes (in ACLs perhaps) so it may be an OpEx
burden. But having a PE router modified to look deeper into the packet
is not much of a concern since the LISP encapsulation header is fixed
length and the source EID can be found easily.
This is one way to protect remote ITR caches from reflection attacks.
Dino
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
