On Thu, Jul 21, 2011 at 8:31 PM, Dino Farinacci <[email protected]>
wrote:
On Thu, Jul 21, 2011 at 5:13 AM, Dino Farinacci <[email protected]>
wrote:
(1) At the ITR
I think this presumes that a malicious end-user in the Locator
address space can't simply forge packets and pretend to be an ITR.
It would also rely on most/all operators of ITRs to configure uRPF
or BCP-38 at their site, which historically has been impossible to
achieve for a large enough portion of the Internet to prevent large
spoofed source attacks.
No, you build it into the implementation.
How will the ETRs know if packets have come from a "real ITR" that
follows this part of the specification, or if the packets came from
malicious hosts masquerading as ITRs? It is obvious that an
attacker will
So we are thinking of putting some data-plane authentication in which
we can talk about later. This is work in progress and nothing has been
published yet.
simply originate encapsulated packets from machines with native
Internet access, so they appear to come from ITRs, but really come
from his tool that does not obey this rule.
This is where you need a firewall (at the access SP) to do mapping
database lookups to verify the (source-EID, source-RLOC) binding.
Also, we do have data-plane gleaning in an ETR specified in the spec.
So the packet could be accepted in an ETR, source-EID and RLOC
gleaned, and when the SYN-ACK is returned, the map-cache can be
verified. That way, you put the mapping database lookup in the place
where it is already being done for other reasons.
This is a tough problem. We will probably discuss this next week.
Luigi has an agenda slot to discuss LISP related security threats.
Dino
--
Jeff S Wheeler <[email protected]>
Sr Network Operator / Innovative Network Concepts
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
