A short version of this message is:

   The easiest and most robust way to enable a network to enforce
   on its ETRs the rule that encapsulated packets from ITRs
   outside the network must not contain inner packets with
   a source address (SA) which matches one of the network's
   own prefixes is (along with some other requirements) to break
   with convention and require ITRs to tunnel the packet with the
   outer SA = the inner SA. That is, the packet sent by the ITR to
   the ETR has the same source address as the sending host.  This
   means that no-one or nothing in the destination network (or
   after the ITR), including the ETR itself, can find which ITR
   tunneled the packet - unless the encapsulation method carries
   extra data which includes the ITR's address, which is not the
   case with Ivip or with current LISP plans.

   The reason is that it is probably very difficult or perhaps
   impossible to make all ETRs inside the network filter the
   decapsulated packets to drop those which arrived from an
   external ITR and have the inner SA matching a local prefix
   (this would be a packet with a spoofed source address) - so
   it is better to achieve the same desired protection by:

   1 - Requiring all ITRs to set the outer SA = inner SA.

   2 - Let the border routers continue to drop packets arriving
       from outside the network with SA matching any one of the
       network's local prefixes.

   3 - Require all ETRs to drop all decapsulated packets with
       an SA (inner SA) which is not identical to the SA of the
       outer header (outer SA).

   Having the outer SA = inner SA also has the benefit that
   traceroute functions normally.  The current LISP 1 and 1.5
   definition has the SA = ETR's address, which means the
   sending host gets no traceroute results for any router between
   the ITR and the ETR - and perhaps not from the ETR either.

I also explore the idea for LISP or Ivip of there being a service
so the current and recent history of the database (multiple
databases perhaps, as is the case with Ivip) can be queried to see
when any mapping - of any EID (LISP) or DID (Ivip) address - has
been to a particular (RLOC) IP address.  This would be vital for
debugging problems with end-users setting the mapping incorrectly,
for determining why streams of encapsulated packets arrived in
some unwelcome fashion etc.  It would be impossible to prevent
this sort of analysis of the mapping data.


Hi Iljitsch,

I tend to agree with what you wrote:

> Oh wait, you mean source address. I don't think it's a good idea
> to have node Y send packets where the source address is X, both
> because this claims that the sender is different from his/her
> actual identity and because return traffic, such as ICMP
> messages, will then end up at (arguably) the wrong node.
>
> Knowing the address of the encapsulating TR is also useful if
> the decapsulating TR ever wants to get in touch with it.

However, I think there are some strong arguments for making the
outer SA = the inner SA, which is contrary to the conventional
sensible notion that any packet created by node Y should have its
SA = Node Y's address.

The general arrangement is:


  HA-----ITR~~~~~~~~~~~~~~~~~~ETR------HB

where HB has the LISP/Ivip-mapped address (maybe HA has such an
address too, but that doesn't matter).

The current LISP-01 I-D only describes LISP 1 and 1.5, so there's
no way of knowing whether with LISP 3.x the outer SA (Source
Address of the UDP packet which encapsulates data packets when the
ITR tunnels a data packet to an ETR) will be the original packet's
SA (HA's IP address) or the ITR's address.  In LISP 1 and 1.5 the
outer SA is definitely the ITR's address (see Definition of terms:
ITR).

In LISP 3.x I am not sure to what degree the ITR sends messages to
the ETR, or whether the ETR sends anything back to the ITR.

Dino's recent message:

  http://www1.ietf.org/mail-archive/web/ram/current/msg01703.html

indicates that the 3.x approaches using CONS or NERD do not
involve the ETR sending a Map-Reply message to the ITR and that
perhaps with APT there would be such messages.

So I am not sure whether some or all 3.x variants of LISP involve
no messages at all from the ETR to the ITR.  If there is no
requirement for such messages or information exchange, then maybe
the ETR doesn't need to get any information from the ITR in data
packets, or presumably by any other means.

In that case, the ETR wouldn't need to know the address of the one
or more ITRs which are tunneling packets to it.  In that case, it
may be possible for LISP to adopt the same "outer SA = inner SA"
approach I currently favor for Ivip.  As far as I can tell at
present, this would have the same benefits for LISP as for Ivip -
much greater ease of a network protecting itself from a particular
form of attack which I will call "internal source address
spoofing", and the retention of the sending host's ability to
fully traceroute the path taken by the packets it sends.

If LISP or Ivip uses the ITR's address for the outer SA then HA
will find that traceroute does not produce any results for any
routers between the ITR and ETR.  Whether or not it would produce
a response from the ETR depends on whether the ETR treats the
decapsulated packet just like any newly arrived packet or not.

I regard this as a substantial argument against using the original
packet's SA for the outer SA.


I am assuming in all this that both LISP and Ivip ITRs and ETRs
follow the principle that the ITR copies the TTL (Time to Live)
from the packet it is encapsulating to the header of the new
packet which contains it (the IP-UDP IP header for LISP and the
IP-in-IP IP header for Ivip).  Similarly, the ETR takes the TTL
from the outer IP header and copies it to the TTL field of the IP
header of the decapsulated packet.    (These operations are
specified for Ivip, but are not actually specified in LISP, except
for similar concepts with recursive or re-encapsulating tunneling.)


My previous message contained some detailed thoughts on why
requiring ITRs to make the outer SA = inner SA makes it much
easier for the network in which the ETR is located to ensure that
packets arriving from outside the network and being decapsulated
by its ETRs do not produce decapsulated packets with SAs from
local prefixes.

Here I develop this line of argument further - in support for the
initially unpalatable notion of having the ITR tunnel the packet
with outer SA = the packet's original SA (inner SA).  I then
examine what benefits and difficulties would result from following
convention and having the ITR use one of its own addresses as the
outer SA.

Ivip has no communication from ITR to ETR or from ETR to ITR.
There is no header, other than the outer header of IP-in-IP
encapsulation.  Ivip could be redefined to use the ITR's address
as the outer SA, but at present I think it is best not to. Ivip
could be redefined to use UDP encapsulation as is currently
defined for LISP 1 and 1.5 - then various other items such as the
ITR's address could be included in the encapsulated packet - but I
am trying to keep Ivip simple and see no reason to do this.

In this discussion, when I refer to "network" I mean any
Autonomous System network (provider or for an end-user) in which
ETRs are deployed.  I don't refer in this discussion to the edge
networks of a single-homed or multihomed end-user which relies
upon LISP-mapped or Ivip-mapped addresses.  Those edge networks
have different requirements for preventing "internal source
address spoofing", which I discuss in Note 1 at the end.


Here is a description of the particular security problem I am
concerned about:

.............                    ....................
    N1       .                  .       N2
             .                  .
             .                  .
H1---ETR1~~~BR1~~~~~~~~TR~~~~~~BR1~~~~~ETR1---MN1
             .                / . \       \
.............                /  .  \---H2  \--MN2
                            /   .   \
                           /    .    \-H3
                          /     .
   AT1~~~~~~~~~~~~~~~~~~~TR       ....................


N1 has a host H1 which is sending a packet to Mapped Node MN1.
Whether MN1 is a host with one or multiple IP addresses, or a link
to a router at a multihomed end-user's site, doesn't matter.  Nor
does it matter whether H1's address is Ivip-mapped or not.

Also, it probably doesn't matter whether the ETR gets the
decapsulated packet to MN1 via a direct link or via relying on
N2's internal routing system to forward the packets to MN1.  This
problem only concerns packets flowing left to right in this
diagram.  Howe MN1 gets packets to H1 is a separate matter and not
affected by the security problem.

I assume N2 has BR2 set up to drop any packet which arrives from
the outside world where the SA matches any of the one or more
prefixes N2 advertises to its BGP peers.  If N2 doesn't bother to
do this, there is no point in fussing over how the ETRs should
filter packets to achieve the same purpose.

I assume (for reasons discussed in my first message in this thread
and in Note 2 below) that all ETRs will drop any packet which has
a DA for any address other than the set of hosts/routers which it
knows it can deliver decapsulated packets to, with
LISP/Ivip-mapped addresses.  This means that if the ETR
decapsulates a packet and finds its DA is for H2, then it drops
the packet.  This also means that if it decapsulates a packet and
finds its DA is for some other LISP/Ivip-mapped address which it
can't deliver packets to (either directly or via support from the
local routing system) then this packet will be dropped too.

The purpose of this "internal source address spoofing" protection
is to stop MN1 receiving a packet with SA matching any of N2's
BGP-advertised prefixes, for instance the address of H2.  Without
this protection, an attacker AT1 can easily create an encapsulated
packet, with outer DA = ETR1, inner DA = MN1 and inner SA = H2.

It is not the purpose of "internal source address spoofing" to
stop ETR1 from decapsulating and forwarding an inner packet to MN1
when its SA is any LISP/Ivip-mapped address, including some
address of another host/node MN2, which happens to be "within" N2
or potentially (multihomed link which may not be working)
connected to N2.

An attacker can already do this by sending a packet with a spoofed
SA to any ITR, or by generating its own encapsulated packet.

The only purpose is to prevent attackers spoofing source addresses
of the non-LISP/Ivip-mapped addresses within N2.

Attackers are assumed to be outside N2.  (It's all over if an
attacker is inside N2.)

I start with some further assumptions:

A1 - Whatever new architecture is adopted - LISP, Ivip etc. -
     the new architecture must not force a lower level of security
     than currently exists (RRG Design Goals 3.9) and should not
     make it significantly more difficult, costly or error-prone
     to ensure the same levels of security are maintained.

A2 - Therefore, for networks which protect against "internal
     source address spoofing" the new architecture must make it
     easy to maintain this protection for packets being
     decapsulated by ETRs.

A3 - That the ETR needs to decapsulate packets which were
     encapsulated by ITRs in this same network.  I argue in Note 2
     at the end of this message why this is a reasonable
     requirement.

A4 - We can't expect the border router to perform deep packet
     inspection on every incoming packet - for instance to find
     any packet which looks like it might be intended to be
     decapsulated by an ETR, and to then decapsulate it, and
     filter it according to the SA of its inner packet.


So we can assume that BR1 drops any packet arriving from outside
if the SA matches, for instance, H3's (ordinary, BGP reachable)
address.


Preventing SA spoofing when outer SA = inner SA
-----------------------------------------------

In the above framework, it becomes very easy to protect against
"internal source address spoofing" if all ITRs make their outer SA
equal to the source address of the sending host (the inner SA).

All that needs to be added is that ETRs drop any packet whose
inner SA does not match the outer SA.

This means that there are two classes of spoofed SA packets being
filtered:

1 - Those sent as ordinary packets, from outside.

    This is handled by the border router's existing filters.

2 - Those in inner packets with an outer header with DA =
    an ETR.  This is performed in two stages - by the border
    router and then by the ETR dropping packets where inner
    and outer SA do not match.

This seems to be a bullet-proof arrangement, and works fine with
encapsulated packets created by ITRs in the network.  These are
assumed not to arise from attackers, since attackers are defined
to be outside the network.


Preventing SA spoofing when outer SA = ITR's address
----------------------------------------------------

In this arrangement, the ETR can't drop packets with inner SA !=
outer SA.  So there is no way the ETR can use this simple
technique to extend the border router's filtering to the inner SA.

The only alternative is for the ETR to drop the inner packet
according to the following criteria:

     1 - If the inner SA matches any of the network's
         BGP advertised prefixes.

and  2 - The outer SA does not match any of these
         prefixes.

(So the packet arrived in encapsulated form from outside the
network while pretending to be sent from inside the network.)

Assuming the ETR needs to accept encapsulated packets from ITRs
inside the network (Note 2 below) then both these tests are required.

However, this is likely to be prohibitively difficult for an ETR
to perform.

Firstly, the FIB hardware of a proper router isn't necessarily
able to perform these gymnastics. (The decapsulation and "drop if
inner SA != outer SA is still tricky, but does not involve any
knowledge of the potentially numerous local prefixes.)

Secondly, the list of prefixes this network advertises could be
very large indeed.  This would make it perhaps impossible for FIBs
to cope with such a list.

Thirdly, we want to be able to do ETR functions in servers, not
just hardware-FIB "routers", including in the destination host (if
it has a BGP-reachable care-of address).  There is no way with
ordinary software of applying a huge list of rules to the inner SA
to decide if the packet should be dropped, and then applying the
same set of rules to the outer SA as well.

Finally, even if routers and software ETRs could do this, there
are serious problems with the network's control system finding all
these ETR functions ensuring they comply with these rules.

With my idea towards the end of Note 2 below - that ETRs should
know how to deliver packets directly to the destination host,
rather than use the internal routing system (which is compatible
with LISP-01 page 11 point 7: "attached destination host") - there
is no need for a general system to control all ETRs at once (as
would be required if every ETR was to decapsulate packets for any
host in the network with a LISP/Ivip-mapped address, relying on
the local routing system to get the packets there).


What is lost by making outer SA == inner SA?
--------------------------------------------

By defying convention and having ITRs send tunneled packets
without their own IP address in the SA of the outer header, we
lose certain things:

1 - We can't find directly which ITR tunneled the packet, once
    it left the ITR.

2 - Therefore, we can't get a message to that ITR, or two whoever
    runs it.

It is an uncomfortable thing to propose such an arrangement, but
here I explore exactly what would be lost.  (As with all this
stuff, I could be mistaken and be missing many important things -
so please let me know what I have missed.)

Ivip requires no communication from an ETR to an ITR, or
vice-versa, so nothing is lost with this arrangement.

Some variants of LISP do require this communication, so if this
"outer SA == inner SA" was adopted for LISP (for instance because
it seems to be the only practical or reasonable way of allowing a
destination network to maintain current security limits) then the
LISP header would need to contain the ITR's address.

I think the remaining reasons for wanting to know the ITR's
address are to do with coping with unwelcome packets.

Here is a possibly incomplete list of the scenarios which could
lead to the perception of unwelcome packets arriving from an ITR.

In the case of packets from an attacker, I will assume that the
outer SA (Ivip) or any "ITR address" in a LISP header contains a
bogus address, which may be part of the attack by encouraging
victim V1 (whoever's host gets the unwelcome packets) to send
messages to victim V2 who probably runs an ITR, or to V3 which is
whoever runs the LISP/Ivip database system, with possible negative
consequences for further victims who might use LISP/Ivip-mapped
addresses:

  a - The packets are sent to an ETR but have inner DAs for
      LISP/Ivip-mapped addresses which the ETR is not configured
      to deliver to a destination host.  This could include
      an address which is a BGP reachable address, or some other
      LISP/Ivip-mapped address other than the small subset of
      those addresses for which the current ETR can deliver
      packets.

  b - The packets are sent to an ETR and have inner DAs which
      is one the ETR is configured to deliver packets for -
      however the flow of packets is excessive in volume, is
      regarded by that host as irrelevant or unwelcome etc.

  c - The packets are sent to an address which is not an ETR -
      it may be of a host, an ordinary router or to some
      address which has no destination node.

In all these cases, if the encapsulated packets come direct from
an attacker (that is they have not been generated by a proper ITR)
then there is no point in looking at the outer DA.  That will
probably not lead to any clues about the location of the attacker.
 Any attempt to complain about an attack from that outer DA
address will probably cause V1 to drag other victims into the
attacker's ploy.

If the packets do come from one or more genuine ITRs, then I think
one of the following must be true:

  e - The one or more ITRs are functioning properly, with fully
      updated databases (an ITRD or an ITRC or ITFH with access to
      properly updated query servers, and getting notifications
      from those query servers in the event of a database change
      for some mapping information they cached).

  f - The one or more ITRs are not functioning correctly.  Maybe
      their FIB is broken and doesn't reflect their RIB (copy of
      database or cached mapping information).  Maybe they are
      not properly updated.  For this reason, ITRDs which for
      some reason are not getting updates or which have detected
      some corruption should probably stop forwarding packets.
      this is a tricky business I will write more about in the
      future.


In the case of 'e', there is no point in knowing which one or more
ITR is tunneling the packets, because there is nothing wrong with
these or any other ITR - and similar problems can be expected with
packets being tunneled by any of the world's hundreds of thousands
 of ITRs (or millions, with ITFHs widely deployed).  The problem
is  either with the contents of the mapping database(s) or with
the behavior of sending hosts.  In Note 3 I discuss how to resolve
the
first problem.  The second problem has nothing to do with the LISP
or Ivip system, although perhaps changing the mapping to "drop" or
pointing it to some other ETR could resolve some problems.

In the case of 'f', it would be good to find the ITR which is
sending the packets which are considered unfriendly.  Ivip as I am
currently proposing it would prevent anyone from finding out which
one or more broken or out-of-synch ITRs are causing the trouble.

This problem is similar to having some router out in the Net
malfunction, forwarding packets to some place they don't belong.
Generally, the packets wouldn't get to an ETR or a host, because
not even a malfunction in a local router could do this (unless the
victim host was on a single link, rather than a LAN, from the
errant router.

The broken ITR is not generating the packet, but it is tunneling a
packet which should be tunneled to some ETR which would be happy
 about it to some other address where the packets are not welcome.


If the outer SA was the ITR's address, then victim V1 could
potentially find who runs this ITR and complain - but it could be
tricky finding out who to complain to, unless there was some
global register of ITRs, which won't include the hundreds of
millions of ITFHs on host computers if Ivip is widely implemented
in the future.

There is something lost by not being able to identify the genuine
ITR which mistakenly tunneled the packets.  However, if the ITR
was functioning properly, there is no point in finding out its
address or who owns it - the problem is not with the ITR but can
only be resolved by either changing the mapping information or by
altering the behaviour of sending hosts - which is no different
from the situation with unwelcome packets today without LISP or Ivip.

Even if it was possible to identify the genuine ITR which tunneled
the unwelcome packets, why should the operator of that ITR shut it
down just because V1 complains about it?  Who is to say that the
complaint is not the work of an attacker?

There does need to be is a way of V1 finding out the recent
history of its IP address being involved in the mapping database.
 I write more about this in Note 3 below.

 - Robin



Note 1 - Edge networks and "internal source address spoofing"
-------------------------------------------------------------

A single-homed or multihomed "edge network" which uses purely
LISP-mapped or Ivip-mapped addresses has a very different set of
conditions in which it might protect against "internal source
address spoofing".

Firstly, it has no BGP connections to the Internet. It only
receives incoming packets via one or more links to provider
networks.   Here, I assume that it relies upon ETRs in those
provider networks (see Figure 3 in the Ivip I-D).

These ETRs feed the inner packets (that is the packets with DA =
some LISP/Ivip-mapped address, where this is one of the edge
network's address range, such as the address of IH9 in Figure 3)
directly to the edge-network's router, Ethernet switch or whatever.

However, if the edge network gets from each of its one or more
providers one or a few of the provider's PA addresses, on which it
runs its own ETRs, and then routes only the inner packets produced
by these ETRs to the rest of the edge network, then similar
principles apply.

The edge network does not contain any ETRs, because ETRs do not
reside on addresses which are LISP/Ivip-mapped.

Therefore, the edge network doesn't need to worry about packets
emerging from ETRs within its own network.

I can think of two scenarios which require different approaches to
protecting against an attacker (implicitly any host outside this
edge network) from sending packets with spoofed local addresses -
meaning addresses within the range of LISP-Ivip-mapped addresses
of this edge network.

1 - The edge network has no ITRs - including any ITFHs - which
    might be tricky to establish if ITFHs became a common part
    of operating systems . . . but then an ITFH will always
    send queries to some Query Server, so if there was a way
    of preventing this from succeeding at the network's router,
    then this would prevent any ITFH function working.

    In this case, the edge network relies on its internal routing
    system to forward packets from its hosts to its hosts.

    In this case, raw packets with DA matching a LISP or
    Ivip-mapped address range will be forwarded directly to
    the correct host if that is their DA, or to the router and
    out one of the links to the provider network if they don't
    match one of the edge network's addresses.  There they will
    soon be encapsulated by one or a series of ITRCs, ITRD etc.

    Protection against packets from the outside with spoofed local
    SAs must be done by the edge network's router - it must drop
    any incoming packet with a SA which matches one of the edge
    network's LISP/Ivip-mapped addresses.


2 - The edge network has its own ITRD, ITRC and/or ITFH functions
    - and these may encapsulate packets which were addressed to
    one of the edge network's LISP/Ivip-mapped addresses.

    This is probably a bad idea, since it makes it much more
    difficult, or impossible, to protect against "internal source
    address spoofing".  There are various reasons I won't explore
    here why this is a messy arrangement to be avoided, but for
    instance how can the edge network's router know whether
    decapsulated packets from an ETR originated in its own
    network or were decapsulated from a packet of an attacker?

3 - Probably some other scenarios I can't think of now.


Note 2 - ETRs must handle packets from ITRs in the same network
---------------------------------------------------------------

(See assumption A3 above.)

In a large network, for scaling purposes, there needs to be lots
of ITRs.  We can't make all the ITR functionality be in the border
routers.

Also, at least with Ivip, it would be advantageous to allow and
encourage caching ITR functions in sending hosts (both those on
ordinary BGP reachable IP addresses and those with Ivip-mapped
addresses).  This is an ITFH function.  It needs to send queries
to QSD or QSC query servers, and it doesn't necessarily have to
tunnel every packet - because those it doesn't tunnel will (in a
well designed network) be forwarded (or perhaps explicitly
tunneled to) one or more ITRCs or an ITRD which can encapsulate
it.  The ITFH greatly reduces the load on ITRCs and ITRDs, without
any cost to anyone and with the path taken by the packets to the
ETR being entirely optimal, since they never need to go via an
ITRC or ITRD.   (ITRCs and ITFHs may not tunnel all packets, so
they need a backup of some other ITRCs or ideally an ITRD to
handle these.)

I assume ITFHs can't easily be detected (except by detecting or
blocking their requests to query servers - maybe the autodiscovery
system returns a message "ITFHs not supported here", which may be
as simple as an empty list of Query Servers) and that they can't
be highly managed, at least in terms of rapid changes to their
behavior.  For instance there could be thousands or hundred of
thousands of ITFHs in a large network, in many hosts or in DSL
modem NAT functions (I call this "function in host" because the
"router" is just a CPU and software, with no FIB hardware etc.).
Nonetheless, I expect there to be autodiscovery arrangements for
an ITRC or ITFH to find where to send queries to and perhaps where
to tunnel packets it doesn't encapsulate for some reason, but
which should be - for instance because it doesn't have mapping
information for that packet's DA.

It is probably much more robust and easier to plaster ITRs all
over the network and to encourage the adoption of ITFHs in many
hosts and DSL etc. modem-routers - than to try to ban ITFHs and
centralise all ITRs in a few places where their activities can be
carefully controlled.  If all the ITRs in a network could be
carefully controlled, then it would be possible to ensure that the
local routing system took precedence over encapsulation, so that
if a host H3 wanted to send a packet to MN1, then the packet would
be sent via the local routing system to MN1, and not encapsulated
and tunneled to ETR1.  However this is unlikely to be practical,
because it could be difficult or impossible to immediately change
the internal routing system and all local ITR behaviour to reflect
the fact that MN1's one or more LISP/Ivip-mapped addresses have
just become reachable inside this network, or have just become
unreachable.

If the local routing system forwards packets to MN1 - this must be
stopped the moment MN1 is no longer reachable - such as if MN1 has
moved and changed its mapping to some other ETR or another
network's ETR.

Even if the local routing system forwards packets to MN1, then it
would still be best if any packet which is encapsulated by an ITR
anywhere will be delivered properly.

Generally, I think there should be no exception to the rule "if
the raw packet finds its way to an ITR which encapsulates it
according to the current state of the database(s), then it
definitely will be delivered to the currently selected ETR".  A
local routing system which attempts to get the packet to the
destination host might be acceptable, provided it changed its
behavior very rapidly to reflect the contents of the mapping database.

Overall, I think it will be best if:

1 - One or more ETRs have some explicit tunnel system for getting
    decapsulated packets to the destination host, rather than
    relying on the local routing system.

2 - Hosts inside the same network should rely on ITRs (and
    perhaps their own ITFH function) to deliver the packets,
    in accordance with the current state of the database(s) -
    and not have this interfered with by the local routing
    system trying to take packets directly to the destination
    host.

3 - We don't want to concentrate all the ITR functions in border
    routers.  To maintain optimal path lengths within the network,
    we want the packets to encounter an ITR ASAP, including in the
    sending host's own ITFH function.

4 - Therefore, we need ITRs all over the network, and these
    ITRs will be encapsulating packets to be sent to ETRs in the
    network, which will directly get the decapsulated packets
    to the proper destination.

All this only applies to Autonomous System networks - not the
end-user networks which consist only of LISP/Ivip-mapped addresses.



Note 3 - A "search-mapping" service to debug LISP/Ivip mapping
--------------------------------------------------------------

This proposal would work with Ivip as currently defined - and
perhaps with some forms of LISP.  I think there really needs to be
some kind of service like this, for LISP or Ivip.

There are some security and privacy implications of such a service
being open to anyone to query about any IP address, but there is
absolutely no way of preventing such a service being created, so
there is no point in trying to prohibit misuse of such a service.

This service could be implemented as part of the main Ivip system,
but there is no need for this to be done, since one or more
separate companies, organisations or individuals could set up
their own system to do the same job.

The service has a server which gets a full feed of the update
stream - "US-Complete" in the current Ivip I-D.  It can also
download the IMAB-DBD periodic dumps of the complete set of
mapping databases.  It is absolutely required that this
information be freely available to anyone, so anyone can set up
their own ITRD and QSD-QSC-ITRC-ITFH systems.  No practical
measures could prevent anyone from gaining access to this information.


The service analyses the data and stores a copy of its analysis in
some database, covering the last few weeks of activity.  Then, the
service is able to definitively answer queries such as:

  What is the history of RLOC (LISP) or TELOC (Ivip) mapping of
  this particular EID (LISP) or DID (Ivip) address?

  What is the history of the RLOC/TELOC mapping of any EID/DID
  over the past minutes, weeks etc. which involved the ITRs being
  told to tunnel packets to this particular IP address?

This means that if the unwelcome packets resulted from something
in the mapping system, now or in the past, that V1 could find out
for sure which one or more EID/DID addresses was involved.  Then,
it could quickly establish which RUAS (Ivip Root Update
Authorisation System) the update was made through.  If that RUAS
considered the complaint to be genuine, it could try to resolve it
with the end-user who it authorises (directly or via one or more
branch and leave UASes) to control the mapping of this IP address.

Spies, dodgy detectives and the security authorities will be
watching the changes in the database, so anyone with something to
hide (which includes ordinary folk who are targeted by nosey
authorities and those with malicious intent) need to consider how
changes to their mapping might leak information to others.


BTW, future generations will want to know why LISP, Ivip or
whatever was foisted on the Internet - because it is certain to
add to the difficulty of understanding and managing the system,
with its own set of gotchas and security problems.  They will
hopefully realise that BGP couldn't be asked to do much more and
that IPv6 wasn't ready for mass adoption, and doesn't solve the
major problems anyway.


_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram