Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers

From: [email-masked] (Noel Chiappa)
Date: Mon, 21 Sep 2009 15:42:05 -0400 (EDT)

> From: Sam Hartman <[email-masked]>

    > The IETF already has other solutinos in that space with a lot more
    > successful deployment than LISP (6to4, Teredo, probably even 6rd).

If you're connected to a v4-only provider, and all you want is v6
connectivity, yeah, that's probably true. However, if you are connected like
that, and either i) have LISP already, or ii) want LISP for some of the
_other_ things LISP does (e.g. multihoming, etc), then it's a nice
side-benefit.

    > As I understand it, for interworking to be useful, we need to get to a
    > point where everyone using LISP either
    > A) Is on a link that can loosen URPF[,] or
    > B) has a PETR they can use.

Well, the term "everyone using LISP" might not be accurate, there...

If a site can't originate packets from its ITR to non-LISP destinations (i.e.
which will have to be non-wrapped, and therefore would have to have an EID
source address, which uRPF will block), and also don't have access to an ETR,
they _can't_ run LISP.

So merely the existence of ISPs which enforce uRPF is enough to 'prove' that
we needs PETRs, at least as far as the pure engineering assessment goes.

Whether there is a viable _business model_ to support them, well, we'll see.
However, to me, looking at the above, 'ISPs which enforce uRPF' + 'people who
want to run LISP (for whatever) reason' -> 'business opportunity for those
who can provide PETR service'.

    > I can see insentives for whomever is selling you your EID to make a
    > PETR available to you, but unless you are going to end up tied to a
    > single ISP

I don't know whether bundling will make the most sense or not. The market
will decide...

    > I don't see why they will be in a position to make a PETR available
    > close to you.

Your ISP, or your EID source, might not. But in that case, bearing in mind
that to run LISP you will need either i) a non-uRPF ISP, or ii) a PETR, then
if you're on an uRPF ISP, then _if you want to run LISP at all_, either i) you
provide your own PETR, or ii) you have to contract with someone else to
provide the functionality.

To me, it's quite simple: ISPs with uRPF (and I gather there are such)
guarantee that PETR functionality will need to exist. So I don't think we can
avoid specifying the functionality.

Time to turn to the engineering?

	Noel

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Sep 2009 17:41:08 -0400

>>>>> "Noel" == Noel Chiappa <[email-masked]> writes:

    Noel> If a site can't originate packets from its ITR to non-LISP
    Noel> destinations (i.e.  which will have to be non-wrapped, and
    Noel> therefore would have to have an EID source address, which
    Noel> uRPF will block), 

Depending on where LISP is going to be deployed, URPF may or may not
be an issue.  Since I still don't understand where we think LISP will
be used, I can't evaluate whether this is something we need to solve.

Obviously, based on what I'm doing with my implementation, I would not
at all be surprised if LISP is deployed in situations where URPF is an
issue.

    Noel> and also don't have access to an ETR, they
    Noel> _can't_ run LISP.

    Noel> So merely the existence of ISPs which enforce uRPF is enough
    Noel> to 'prove' that we needs PETRs, at least as far as the pure
    Noel> engineering assessment goes.

No, I don't think that follows.
I think it follows either that

1) You don't get end-to-end addressing talking to non-LISP sites (we probably all think that's not good as an only option)

2) Some box needs to source packets somewhere with your EID.

A PETR is more than just some boxes sourcing packets with your EID. It
has several properties:

* It uses the LISP data encapsulation
* It may not be connected with the person providing your EIDs
* It's topologically close to you
* It uses IP access lists for security

Also, I think that showing the engineering requirement for something
isn't good enough.  We've said that we want LISP to be deployable.  If
we can't identify deployment incentives for critical parts, that
raises a significant red flag in my mind.

I actually suspect that once we have a broader idea about LISP
deployment, coming up with incentives for PETRs won't be that
difficult.  However I agree with Robbin that it's a critical question
that I'd rather have answered before going down this path.

so, I'm finding that for me at least, PETRs are yet another thing that
blocks behind understanding security and deployment.  (I have not gone
into the reasons why I'm concerned about PETRs and security.
Basically I want to understand what our DOS prevention model is to
understand how much work we need to do to make sure PETRs are not used
in mounting DOS attacks.)