Subject: [lisp] VPN Leaks

From: Ronald Bonica <[email-masked]>
Date: Mon, 20 Apr 2015 11:30:35 +0000

Folks,

In draft-ietf-lisp-eid-block-10 you say:

  Avoid excessive stretch:  In some deployment scenarios, in order to
         avoid packet drops, packets triggering a LISP Cache miss are
         forwarded toward a PETR, during the time necessary to perform a
         mapping lookup over the LISP mapping system.  Once a mapping is
         obtained packet are not forwarded anymore toward the PETR, they
         are LISP encapsulated and forwarded according to the LISP
         specifications.  The existence of a LISP specific EID block
         would allow to avoid scenarios with excessive overhead, where
         the destination is a LISP EID and where (while the mapping is
         looked up) packets are forwarded over paths like
         Source->ITR->PETR->PITR->ETR->Destination, which may show an
         excessive stretch factor and degraded performance.

Is this behavior documented anywhere else? If so, where?

Is this behavior also observed in IPv4 implementations?

Also, is there serious consideration to using LISP as a VPN mechanism (as suggested in draft-ietf-lisp-impact-01 and draft-ietf-lisp-introduction-13). If so, this behavior should be mentioned in the Threats document.

Ron Bonica

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 20 Apr 2015 07:52:39 -0700

>         forwarded toward a PETR, during the time necessary to perform a

This is actually incorrect. An ITR or PITR will encapsulate to a PETR, not when a cache miss happens but when the mapping system returns a “forward-native” action in a Null Map-Reply (one with no locator-set).

>         are LISP encapsulated and forwarded according to the LISP

What is returned by the mapping system is the best least specific prefix that describes all non EID destinations within it.

This “forward-native” entry is put in the map-cache with one or more PETRs in the locator-set. Current implementations configure this set of PETRs.

>         Source->ITR->PETR->PITR->ETR->Destination, which may show an

This is totally wrong. PITR, by definition, are not decapsulators. Maybe the author meant:

	Source -> ITR -> RTR -> ETR -> Destination

which is a different type of path and use-case then:

	Source -> ITR -> PETR -> Destination 

where the PETR is natively forwarding to the destination. This is the case where a LISP-site is sending to a non-LISP site.

> Is this behavior documented anywhere else? If so, where?

The latter is in the Interworking RFC and the Deployment RFC.

> Is this behavior also observed in IPv4 implementations?

In all environments. Even VXLAN/LISP data-center environments.

> Also, is there serious consideration to using LISP as a VPN mechanism (as suggested in draft-ietf-lisp-impact-01 and draft-ietf-lisp-introduction-13). If so, this behavior should be mentioned in th…

Yes, there are several large deployments and there was a use-case ID that was written and has expired.

Dino

> 
> Ron Bonica
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: "Selina Heimlich (selina)" <[email-masked]>
Date: Mon, 20 Apr 2015 15:25:06 +0000

>> Also, is there serious consideration to using LISP as a VPN mechanism
>>(as suggested in draft-ietf-lisp-impact-01 and
>>draft-ietf-lisp-introduction-13). If so, this behavior should be
>>mentioned in the Threats document.
>

Just a note that there is no VPN leak even if a PxTR is configured for the
VPN and an EID doesn’t exist.  The PxTR for a VRF has to be connected to
the VRF in some manner and will only forward VRF traffic to/from the
legacy VPN network and the LISP VPN network.  This is a common method used
for transitioning from another VPN model to LISP or for marrying different
parts of a network.  The PxTR acts just like an xTR for the non-LISP part
of a VPN.

Selina

---

From: Sander Steffann <[email-masked]>
Date: Mon, 20 Apr 2015 17:28:15 +0200

Hi,

> This is totally wrong. PITR, by definition, are not decapsulators.

The example is correct, and the PITR in the example is an encapsulator. The ITR->PETR bit is encapsulated. The PETR->PITR bit is unencapsulated (probably BGP routed) internet traffic, and the PITR->ETR bit is encapsulated again.

Cheers!
Sander

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 20 Apr 2015 08:34:41 -0700

> The example is correct, and the PITR in the example is an encapsulator. The ITR->PETR bit is encapsulated. The PETR->PITR bit is unencapsulated (probably BGP routed) internet traffic, and the PITR-…

Then the example is not coded properly. It nees to be more specific for accuracy:

source (native forward) -> ITR (encap) -> PETR (native forward) -> PITR (encap) -> ETR (native forward) -> dest

Dino

---

From: Sander Steffann <[email-masked]>
Date: Mon, 20 Apr 2015 17:36:04 +0200

> source (native forward) -> ITR (encap) -> PETR (native forward) -> PITR (encap) -> ETR (native forward) -> dest

Yep, that's it :)
Sander

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 20 Apr 2015 17:03:02 +0000

> -----Original Message-----
> From: Dino Farinacci [mailto:[email-masked]]
> Sent: Monday, April 20, 2015 10:53 AM
> To: Ronald Bonica
> Cc: LISP mailing list list
> Subject: Re: [lisp] VPN Leaks
> 
> 
> >
> This is actually incorrect. An ITR or PITR will encapsulate to a PETR, not when a
> cache miss happens but when the mapping system returns a “forward-
> native” action in a Null Map-Reply (one with no locator-set).

[RPB] 

That's much better. The behavior described in draft-ietf-lisp-eid-block would cause data to leak out of the VPN.

                                                                Ron

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 21 Apr 2015 12:00:33 +0200

> On 20 Apr 2015, at 17:34, Dino Farinacci <[email-masked]> wrote:
> 
> 
>> Hi,
>> 

I would suggest:

source -> ITR (encap) -> PETR (recap) -> (native forward) -> PITR (encap) -> ETR (decap) -> dest

Because of the current status of the document (and as co-author) this can be done during the IESG review or right before forwarding it to the RFC queue if no other changes are required.

ciao

L.

---

From: Brian Haberman <[email-masked]>
Date: Tue, 21 Apr 2015 08:37:46 -0400

On 4/21/15 6:00 AM, Luigi Iannone wrote:
>>>>> would allow to avoid scenarios with excessive overhead,
>>>>> where the destination is a LISP EID and where (while the
>>>>> mapping is looked up) packets are forwarded over paths like 
>>> The example is correct, and the PITR in the example is an
>>> encapsulator. The ITR->PETR bit is encapsulated. The PETR->PITR
>>> bit is unencapsulated (probably BGP routed) internet traffic, and
>>> the PITR->ETR bit is encapsulated again.
>> 
>> source (native forward) -> ITR (encap) -> PETR (native forward) ->
>> PITR (encap) -> ETR (native forward) -> dest
> 
> I would suggest:
> 
> Because of the current status of the document (and as co-author) this
> can be done during the IESG review or right before forwarding it to
> the RFC queue if no other changes are required.

The EID-block draft is in IETF Last Call, so you could consider the
above discussion a LC comment on it.

Brian

> 
> ciao
> 
> L.
> 
> 
>> 
>> Dino
>> 
>>> 
>>> Cheers! Sander
>>> 
>> 
>> _______________________________________________ lisp mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/lisp
> 
> _______________________________________________ lisp mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 21 Apr 2015 16:26:15 +0200

> On 21 Apr 2015, at 14:37, Brian Haberman <[email-masked]> wrote:
> 
> 

[snip]
> above discussion a LC comment on it.

Thanks Brian,

actually that was the purpose of my message. :-)

L.

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 21 Apr 2015 15:36:28 +0000

Folks,

Given Dino's response in http://www.ietf.org/mail-archive/web/lisp/current/msg05945.html, shouldn't we remove the entire bullet item? As Dino says, "An ITR or PITR will encapsulate to a PETR, not when a cache miss happens but when the mapping system returns a "forward-native" action in a Null Map-Reply (one with no locator-set)."

                                                                                 Ron

> From: lisp [mailto:[email-masked]] On Behalf Of Brian Haberman
> Sent: Tuesday, April 21, 2015 8:38 AM
> To: [email-masked]
> Subject: Re: [lisp] EID-Block clarification [was: VPN Leaks]
> 
> 
> 
> >>>>> specifications.  The existence of a LISP specific EID block would
> >>>>> allow to avoid scenarios with excessive overhead, where the
> >>>>> destination is a LISP EID and where (while the mapping is looked
> >>>>> up) packets are forwarded over paths like
> >>> encapsulator. The ITR->PETR bit is encapsulated. The PETR->PITR bit
> >>> is unencapsulated (probably BGP routed) internet traffic, and the
> >>> PITR->ETR bit is encapsulated again.
> >>
> The EID-block draft is in IETF Last Call, so you could consider the above
> discussion a LC comment on it.
> 
> Brian
> 
> >
> > ciao
> >
> > L.
> >
> >
> >>
> >> Dino
> >>
> >>>
> >>> Cheers! Sander
> >>>
> >>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 21 Apr 2015 08:49:02 -0700

> On Apr 21, 2015, at 3:00 AM, Luigi Iannone <[email-masked]> wrote:
> 

There is no recap in the PETR. It simply strips a LISP header and forwards the packet. 

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 21 Apr 2015 19:09:33 +0200

> On 21 Apr 2015, at 17:49, Dino Farinacci <[email-masked]> wrote:
> 
> 
> 

You are right. It has to be “decap”.

L.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 21 Apr 2015 10:18:21 -0700

Right. 

Dino

> On Apr 21, 2015, at 10:09 AM, Luigi Iannone <[email-masked]> wrote:
> 
>