Subject: [lisp] Comments regarding PETR's in the deployment document.

From: Paul Vinciguerra <[email-masked]>
Date: Sun, 28 Oct 2012 14:35:50 +0000

As I read section 4.2,  I'd like to point out two issues that could simplify/optimize deployment :

   P-ETRs can be deployed by ISPs wishing to offer value-added services
   to their customers.  As is the case with P-ITRs, P-ETRs too may
   introduce path stretch.  Because of this the ISP needs to consider
   the tradeoff of using several devices, close to the customers, to
   minimize it, or few devices, farther away from the customers,
   minimizing cost instead.

We see this in practice as well.  Much more of the traffic path winds up on the EID side. (All the non-LISP prefixes are EID's to a PeTR, yes?)  This minimizes the amount of time that packets are encapsulated between RLOCS.  I see a need for traffic engineering where PeTR's could advertise prefixes into the mapping system (with some kind of no-export tag into the DDT).  Our specific use would be to egress traffic at our peering points where we directly connect to the endpoint.

If the encapsulated path were longer, the intermediary providers would also see empirical evidence of LISP running on their networks, as the packets would be UDP/4342. Once the packet passes through the PeTR, it's just a regular packet again.  This process should happen as close to the endpoints as possible.   This suggests that as a best practice, anycast addresses should not be used for PeTR addresses, because anycast addresses  minimize the encapsulated path.

   As a security measure, access to P-ETRs should be limited to

   legitimate users by enforcing ACLs.

In practice, this is hard to do.  It is hard to do with outer header source addresses if you support DHCP based RLOCs.

Likewise, ACL's on the inner header source addresses help against theft of service, but packets with IP options set can move the fixed offset of the inner header source address and make using ACL's a challenge.

With ACL's, limiting legitimate users would imply matching the proper pairing of both inner and outer header source addresses at a minimum.  An alternative approach would be valuable as suggested in the interworking document.

   A Proxy-ETR should verify the (inner) source EID of the packet at

   time of decapsulation in order to verify that this is from a

   configured LISP site.  This is to prevent spoofed inner sources from

   being encapsulated through the Proxy-ETR.

Paul