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

From: Lori Jakab <[email-masked]>
Date: Wed, 02 Jan 2013 11:13:10 +0200

Hi Paul,

I missed this email when it was sent, I was traveling at the time. I
just reviewed mailing list traffic now, and saw this was unanswered.
Please see inline below:

On 10/28/12 16:35, Paul Vinciguerra wrote:
>
> 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.
>

This is a very interesting optimization, which may reduce path strech
even with a relatively low number of deployed PxTRs. How about
configuring source based replies in the DDT, instead of the "no-export"?
This could be an easier way to accomplish the same goal, and we can keep
P-ETRs simple, without the need to send Map-Registers. The ETRs of the
site would register the P-ETR RLOCs for queries coming from P-ITRs from
peers. I like the source based approach better, because there are other
use cases already for LISP, when a source based reply may be necessary.

> 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.
>

I will incorporate this suggestion into the document, thanks!

>    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.

Ok, in that case we will remove this recommendation.

-Lori

> Paul