Originally, Xu Xiao-Hu wrote:
> In the current Internet, an ICP (e.g., google) could scatter a set of
> servers sharing the same FQDN (e.g., www.google.com ) worldwide or
> nationwide to provide load-balancing services in an anycast-like way. For
> example, if a client performs a DNS query for the A or records of ”
> www.google.com”, the DNS server could return the address of a server which
> is one of the nearest servers to the client, in the DNS response. Of course,
> the DNS server could also return all available A or records, then the
> client will choose one according to some policy. In this case, the FQDN
> plays a role of service ID, rather than host ID.
In the current Internet, as noted earlier by various folks,
Google (and MANY other content providers) use CNAME and/or SRV
records for the scenario above.
A feature of using DNS is that often the responding DNS server
can include all of the relevant information (beyond the strict
definition of the original query) in the its reply as "Additional
Data". This capability eliminates additional DNS round-trips,
and so is good for both DNS clients and for the DNS servers.
A real-world example for Google (below) shows this nice property
of DNS-based load balancing.
Here are actual DNS records returned a moment ago by using
dig(1) to query for www.google.com. The query was for
www.google.com's A record. The CNAME is returned, along
with the A records associated with the CNAME value.
EXAMPLE:
$ dig www.google.com
; <<>> DiG 9.6.0 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18428
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.google.com. IN A
;; ANSWER SECTION:
www.google.com. 213133 IN CNAME www.l.google.com.
www.l.google.com. 27 IN A 72.14.204.99
www.l.google.com. 27 IN A 72.14.204.103
www.l.google.com. 27 IN A 72.14.204.147
www.l.google.com. 27 IN A 72.14.204.104
In fact, DNS-oriented load-balancing works just fine with ILNP.
Much earlier, Tony Li wrote:
> ILNP uses an explicit numeric token as the identifier. The FQDN is not
> the identifier. The identifier can be found in the I record.
>
> On a forward reference, a FQDN is resolved into an I record and one or
> more L records.
Yes, with one edit:
...into one or more I records and one or more L records...
One does not expect a node to be using multiple IDs in the common
case, but it is permitted -- for example to enable folks who wish
to use "privacy" (sic) Identifiers generated (as per RFC-4941)
or use cryptographically-generated Identifiers (as per RFC-3972).
Later, Robin Whittle wrote:
> Just having a packet arrive with a particular Identifier and Locator
> doesn't establish reliably that the host with this Identifier can be
> reached with that Locator.
and later in the same note, he said:
> With today's naming model, the packet won't necessarily get to the
> host whose Identity is XYZ, because it may be lost. However, the
> routing system ensures that the packet won't go to a host which does
> not have Identity XYZ.
Several comments:
1) Given ordinary IPv4 or IPv6 (i.e. without IPsec, without SSL/TLS),
one has really no idea whether one is talking with the node one
thinks one is talking with. IP address forgery methods are both
well known and long-standing [CERT Advisory CA-1995-01 is over
15 years old; attacks beyond those described in 1995 are now known
to exist]. For both ordinary IPv4/IPv6 and ILNP, one only really
knows which node one is talking with if one is actually using some
plausibly secure form of cryptography (e.g. IP Security, TLS/SSL).
The IETF Security community has had unanimity about this for some
long while -- Steve Bellovin has noted this issue many many times,
for example.
2) Looking at the 2nd quote above, the routing system provides no such
guarantee. The routing system (or a single router) might forward
a packet from A to B via some adversary C -- and that adversary C
might do anything with the packet (e.g. drop it, employ a
man-in-the-middle attack on both A and B, modify the packet and then
send it to B, or a range of other bad things).
So the first quote above is meaningless, and the second
quote above is incorrect.
3) ILNP includes a Nonce value. Using the nonce, which is mandatory
as already documented, provides security properties equivalent
to using ordinary IPv4/IPv6 (i.e. without IPsec). Using the nonce
is orthogonal to IPsec, so one can use IPsec in addition if desired.
Earlier, someone wrote:
> By the way, as stated in the ILNP draft, "...the Locally unique Identifiers
> are unique within the context of their associated Locators...". Therefore,
> there SHOULD be some associa
