[RRG] Hosts modified so DNS lookup also gives mapping to ITR?

[Robin Whittle <rw@firstpr.com.au>]

Short version: (for those who have seen the movie "Repo Man")

               Host changes to get the mapping to the ITR as
               part of the initial DNS lookup?

               "You don't want to look in the trunk . . . "


Hi Xiaohu,

In "Re: [RRG] Are host-stack modifications allowed or disallowed ?"
you wrote about how a host's DNS lookup could return mapping
information for the IP address, which would be conveyed to the ITR
so there would be no delays.

>> A) Host changes
>> - The business model is difficult, because end system stack
>>   providers would not see an immediate benefit from
>>   implementing and pushing the changes.
>
> I don't think the business model is a big problem or there is no
> incentive for the end user to upgrade their hosts.  Provided the
> LISP-CONS/ALT is just looked as a transitional solution to the
> routing scalability issue, the non-upgraded host will suffer the
> initial packet loss/delay pain,

We can't force people to adopt the new kind of address space.  If it
doesn't work as well as traditional BGP managed PI space, then not
many people will adopt it.  Marshal Eubanks wrote about this:

  http://psg.com/lists/rrg/2008/msg00381.html

There's no way that we can get all host operating systems upgraded
before this new kind of space becomes available.  We can't expect
host changes to occur except very slowly, over years.

> on the contrary, once the host is upgraded to support EID-RLOC
> mapping query on behalf of the ITR, the end user will jump
> out of the pain.

I think you are suggesting something like this:

1 - Sending host has text name for destination host, and uses
    DNS to find its IP address.  Modified TCP/IP stack in host
    also requests from the DNS server the mapping information
    for this IP address.

2 - Modified sending host TCP/IP stack somehow transmits mapping
    info to ITR - unless you are assuming that the DNS reply
    comes through the ITR (it might not) and the ITR is doing
    deep packet inspection on all packets to look for such
    replies, whereupon it grabs the mapping info and is then
    ready to tunnel the traffic packet without any delay.

Leaving aside my earlier critique of not many people wanting a type
of address space which involves delayed initial packets, and leaving
aside the difficulties of upgrading host software, there are
still some difficulties.

Assuming the ITR has to find out explicitly from the sending host
what the mapping info is, how does the sending host convey this?
The sending host can't very well be configured with the address of
the ITR.

There could be multiple ITRs which the packet may go through, due to
various forwarding decisions upstream, including for load sharing
across ITRs.  So how does one packet emitted by the host get to the
correct ITR, which means every ITR the traffic packets could
conceivably pass through?

I think there are many problems with this.

How could the ITR authenticate the mapping it is being given?  It
has no clue about the sending host, which can't be trusted anyway.
It has no clue directly about the authoritative source of the
mapping.  Any device could send such a mapping info packet to the
ITR, pretending to be a host which will be sending it traffic
packets.  Source address spoofing etc. . . .   This is a totally
insecure way for the ITR to gain mapping information.

Ignoring this critique, and moving on as if it all worked:

Now we have conceptually two sources of mapping info: the ALT
network's one or more authoritative ETRs and the two or more
nameservers.

Changing the mapping now involves mucking around with two separate
nameservers, as well as the ETRs.

Considerable modifications would be required in the nameserver,
since asking about a text name could produce a number of IP
addresses, each with different mapping.  The mapping could be a
large body of information, with multiple ETR addresses, TE
instructions, priorities etc.  This would be too much to send back
in a single packet, especially if there were lots of IP addresses to
be returned for this text name.

The host stack would either send the whole lot to the ITR (since the
host stack could choose any of these IP addresses to send packets
to) - in which case the ITR would be chewing up its RAM and perhaps
FIB resources for a bunch of separate EIDs which are never going to
be used.

What if the ITR gets two conflicting sets of mapping information for
one EID?

Sending host A could do a DNS lookup on www.aaa.com and get IP
address X, and a bunch of mapping information for the EID which X is
a part of.

Sending host B could do the same for www.dodgy.com and get the same
IP address X, with a different bunch of mapping information.

For all the ITR knows, the mapping has changed.  Then, A's packets
to IP address X will be sent to wherever the DNS of dodgy.com says
they should go.


The organisation which runs the nameserver might not have anything
to do with the organisation which has the EID space in which the
server runs.

Company H is a hosting company.  It has a web server on IP address
A.  On that server are 20 virtual servers, for the sites of 20
companies.  When company H wants to change the mapping of the EID
space which contains address A, they have to notify and send a bunch
of information to the 20 companies whose nameservers are used by
clients to find the IP address A.

Even if a plan such as this somehow worked, it is of no help to
various applications which do not involve a DNS lookup by the
sending host.

Prime among these are P2P programs, which get their IP addresses
from a remote source.  Streaming P2P programs will constantly be
changing their IP addresses to send things to, and its not like a
slow Bittorrent file transfer in the background - peers all over the
world are relying on those packets so people can hear and see things
within that second or so.

P2P programs could be chopping and changing the IP addresses they
send packets to with arbitrary complexity.  If many of these involve
initial packets to each new address being delayed by much, this kind
of address space will genuinely suck and it will be very hard to get
anyone to adopt it.


> Besides, it will benefit the ISPs eventually since they do
> not need to afford the high-cost ITRs which should support full
> database ( > e.g. LISP-NERD), or which should support cache and
> this mechanism will become a target of DDoS attack.

There are other alternatives to ALT's full pull than NERD's full
push.  APT and Ivip are hybrid push-pull systems, and Ivip allows
arbitrary flexibility for operators to choose how far the full push
goes, and where the local query servers and caching ITRs begin.

  - Robin

   (In "Repo Man", the traffic cop does go round the back of the
    old Malibu and opens the trunk, not realising this is where
    the DEAD ALIENS are.  There's a blinding flash of light... )



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg