Subject: [lisp] Business models - PITRs, PETRs and EID-rental

From: Robin Whittle <[email-masked]>
Date: Tue, 22 Sep 2009 14:52:12 +1000

Short version:   I agree with my understanding of what Joel and Noel
                 wrote about discussion of "business models".

                 I am adopting the use of "PITR" (Proxy ITR) instead
                 of its current term "PTR" (Proxy Tunnel Router), as
                 suggested by Joel.  This term is needed now there is
                 a second LISP "proxy" network element - the Proxy
                 ETR.

                 I propose a business model for LISP PITRs, just like
                 for Ivip OITRDs.

                 I propose a business model for LISP PETRs, somewhat
                 like for TTRs - but this can only be made to work,
                 and some other problems of PETRs can only be solved,
                 if the ITR establishes a two-way tunnel to the PETR,
                 as the MN does to the TTR.

My desire to discuss "business models" is in accordance with what
Joel wrote and Noel agreed with, in "LISP Interworking:  Proxy Egress
Tunnel Routers":

> > The distinction I draw is between that and "a thorough set of
> > possible business models." We are not trying to explore the space
> > of business models ... I think we need to convince ourselves that
> > the business model has enough solidity that it may succeed. After
> > that, the experiments should help us tell who is interested, and
> > what the actual costs are, etc... Our initial evaluation needs to
> > look at overall incentives and overall costs, not details of
> > business models.
>
> Exactly.
>
> 	Noel

I don't think there needs to be any mention of these models in the
RFCs, except perhaps to explain what the WG anticipates regarding the
relationships between the organisations which run the various items
of networking equipment.

The separateness of these organisations, the levels of trust and
distrust between them and the need to allow for and support
competition will affect what sorts of protocols are required to make
the whole system work well.  Likewise how to protect against
unauthorised use of these network elements.

The RFCs wouldn't mandate any particular business arrangement for
owning and running particular network elements.  Its just that the
definition of these network elements, their responsibilities and the
protocols they use needs to support at least one business model which
we think is attractive enough that sufficient people will actually
create and run these things.

I think we need to allow for revenue generating business models in
some settings, such as for PITRs (Proxy Ingress Tunnel Routers) and
for PETRs - Proxy ETRs or whatever they are to be called.

In Ivip I envisage a revenue-generating business model for OITRDs
(Open ITRs in the DFZ ~= LISP PITRs). [1]  In the TTR mobility model
[2] (which can be applied to LISP, APT or Ivip), one of the roles of
the Translating Tunnel Routers is equivalent to the role proposed for
LISP Proxy ETRs.

I anticipate - indeed propose - revenue generating business models
for both OITRDs and TTRs, but they are different models.

Here I propose arrangements for LISP PITRs similar to those for
OITRDs and arrangements for PETRs similar to those for TTRs.

For both PITRs and PETRs, I am anticipating that these network
elements would be either owned and run by the organisations which
rent out (in LISP terminology) EID space, and/or that they would be
owned and run by some other organisations which rent out capacity to
the EID-renting organisations.  (Actually, these two could be
combined - a global network of PITRs or PETRs could be owned and run
by an EID-rental organisation who also rents out their capacity to other
EID-rental organisations.)

For LISP-PITRs I suggest the same as I anticipate for Ivip OITRDs:
The EID-rental organisations run (directly or pay for capacity on
someone else's system) a global network of PITRs which advertise in
the DFZ routes which encompass all the address space the EID-rental
company rents to its customers.  Without sufficient capacity in these
PITRs - and without these ITRs being widely dispersed, so as to
handle packets without excessive path-length stretch - their EID
space won't be very attractive for anyone to use.  (Because packets
sent from networks without ITRs will either not be tunneled to the
ETR, or will go via excessively long paths.)

There would be no access provisions for PITRs - all packets would be
accepted and tunneled to the correct ETR.  There would need to be a
revenue generation system such as sampling the PITR traffic to see
which customers the traffic was going to, and charging those
customers accordingly.  This is from the point of view of the
EID-rental organisation and its typically thousands or millions of
customers, each of whom rent one or more EID prefixes.

    (In message 01560, Joel wrote that "we get an increase in
     routing table size instead of a decrease."  But one such BGP
     advertised prefix covers the space used by potentially hundreds
     of thousands of end-user networks which are getting portability,
     multihoming and inbound traffic engineering.  Without LISP, or
     whatever the core-edge separation solution to the routing
     scaling problem is, each such end-user network would need to
     have its own advertisement in the global BGP routing table to
     have these benefits.)

So the EID-renters would pay rent on a yearly or monthly basis for
their EID address space and they would pay a separate fee for how
much capacity was used on the PITRs for traffic being sent to their
EID space.  (Maybe, for PITR usage lower than some level, there would
be no such second fee - that would be up to the EID-rental company.)

There's no way of charging the senders of the packets which the PITRs
need to encapsulate - and it can't be paid for by some global pool of
money, collected from all LISP users or from all the EID-rental
customers of a single EID-rental company.  This is because a single
such customer, with a single IPv4 EID address (or IPv6 /64) could
have massive amounts of traffic coming to that address, much or all
of it from networks without ITRs.  There is no way the cost of that
burden on the PITRs should be paid for by other LISP users.

The actual usage of PITRs would vary enormously.  Some LISP-users
might have a very large amount of traffic coming into their sites,
but none, or little of it, may arise from networks without ITRs.

One fundamental problem with this business model is that it could be
used as an extra economic lever by attackers doing what is now termed
a Distributed Denial of Service flooding attack: typically thousands
of hacked Windows PCs all firing packets at some IP address.  In
addition to clogging up the final link which receives all that
traffic, or without overloading it at all, the attackers would cause
financial costs for the renter of the EID, with them having to pay
money to their EID-rental company for all this traffic.

I can't think of any solution for this nasty problem.

However, I can't think of any way of deploying the PITRs or OITRDs
which are absolutely needed without some kind of usage-based
revenue-generating business model.

"EID-rental" is probably a novel term in the LISP field, though Sam
recently mentioned "whomever is selling you your EID" (msg01529).

After two and a half years of LISP discussion, I still have no clear
idea of what the LISP team thinks will be the business models by
which LISP users (end-user networks adopting LISP-mapped EID
addresses) obtain their EID address space, or a clear idea of what
sorts of networks these will be.

For PETRs, as with TTRs, I suggest that they only accept packets from
authorised sources.  That is easy with the TTR, since they only
accept packets via a tunnel - typically encrypted, maybe with
compression, definitely with packet resend facilities - which are
established, with appropriate authentication, from the Mobile Nodes.

I have no idea how this can be done with the current PETR proposal -
which involves standard LISP encapsulation for the traffic packets.

Without such controls, the PETR can be used by anyone to forward
packets as if they came from any EID address, and as if they were
sent from any ITR.

I suggest that the ITRs do for PETRs as I propose MNs do for TTRs:
establish a tunnel from the ITR to the PETR, with appropriate
authentication.  Then there can be no unauthorised usage of PITRs.

A major additional benefit of this is that the tunnel protocol can
be specifically designed to handle the PMTUD problems and the
resending of packets and packet fragments which do not arrive at the
PETR.

Another benefit of a suitably designed tunnel is that it could handle
IPv6 over an IPv4 tunnel and vice-versa.  (This is a LISP-specific
suggestion, it it not currently part of the TTR model.)

A third benefit is that when the ITR establishes the tunnel, this
means the ITR can be behind one or more layers of NAT.

    (There are many things about having an ITR behind NAT which
     are at odds with the original conception of LISP.  LISP could
     be redesigned so that the LISP-site communicates with the
     outside world, in some respects at least, via this two-way
     tunnel to the thing we are currently referring to as a PETR.
     PETRs are on stable global unicast addresses and so with
     appropriate protocols, the ITR which is behind NAT might be
     able to be publicly accessible via a port at the PETR.

I still have no idea what why LISP networks would be behind NAT,
 except to support a level of portability and connectivity
flexibility which resembles that provided by the TTR mobility
approach.  The TTR model does support MNs behind one or more layers
of NAT.

PETRs would be owned and run by EID-rental companies, or by some
other company for them.  The EID-rental companies would charge their
EID-renting customers (LISP-adopting end-user networks - AKA
"LISP-users") for the traffic each such customer sends to the PETRs.

To successfully run an EID rental business, a company would need to
ensure the customer could use their EID space equally well in any
portion of the Earth.  (This is an ideal, maybe there are substantial
markets for EIDs for customers who would only need to use them in
North America, or in China, or in some other restricted area.)

To do this, they will definitely need a widely dispersed set of
PITRs.  These should be close to whatever ISPs their EID-renting
customers may have their sites at.  This means they need to be pretty
much all over the Net.

Likewise, they need a set of PETRs - with similar or identical
location requirements.  So it would make sense to co-locate the PITR
and PETR functions, including putting them in the same box.

Both the PITR and PETR functions would record traffic, at least on a
sampling basis, for billing purposes.

The PITR would accept all packets and encapsulate them.

The PETR would only accept packets from tunnels from authorised ITRs.

  - Robin

[1]  http://www.ops.ietf.org/lists/rrg/2008/msg01158.html
     http://www.mail-archive.com/[email-masked]/msg02448.html

[2]  http://www.firstpr.com.au/ip/ivip/#mobile
     (This site will be back online in the next day or so.)