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 AAAA 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 AAAA 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 association between I records and L records of a given
> host.
Indeed there is an association:
A locally-unique ID is unique only within the context
of that node's locators.
This could be paraphrased as saying:
"No more than 1 node may use a given ID value on a given
IP subnetwork at a given time."
That constraint is true for existing IPv4, IPv6 (see IPv6 ND
for example), and hence isn't particularly new with ILNP.
As ILNPv6 recycles IPv6 ND without needing to change anything,
it is not surprising that the same IPv6 constraint remains.
> Unfortunately, there seems NO such association in the current ILNP
> specification.
That sentence is untrue. They have the association that
the document describes (and that I've summarised badly above).
In a different note, Robin Whittle wrote:
> I think these last two lines are incorrect. I think Ran did a copy
> and paste operation from the previous section, and forgot to modify
> them to be the LP record.
Indeed, that was a copy-and-paste error. With luck,
I'll fix that in the next editing pass for that document.
Separately, Xu Xiao-Hu wrote:
> ... multiple I records associated with a given FQDN
> CAN ONLY belong to a single host.
That is untrue as stated.
The trivial counter example is a set of servers that all reside
behind a load-balancer. All of the nodes behind the load-balancer
could share the same Identifier -- using technology widely deployed
today in commercial off-the-shelf load-balancer systems. (Kindly
recall that even SSL can be handled by those systems in that way,
and SSL has cryptographic bindings to identity.)
Also, Xu Xiao-Hu wrote:
> By the way, IMHO, maintaining the FQDN->ID mappings and ID->Locator mappings
> in two separate tables respectively is a better choice from the database
> design (e.g., table structure and the relationship between tables)
> perspective.
That is quite literally an implementation detail.
Some implementers will be more clever than others, no doubt.
(Begin Administrivia)
My apologies if I overlooked some message that wasn't already
responded to by someone else.
In other news, as the I* seem to have finally sorted through the
I-D boilerplate issues, there is some hope that I'll get revised
ILNP I-Ds online in the near future.
Regardless, folks who want to understand ILNP really ought to read
through the various published papers on ILNP -- beyond the I-Ds.
The ILNP I-Ds have a style closer to the BGP specification than
to the OSPF specification -- focused on packet formats and
required protocol exchanges. The papers are more descriptive,
and everything is online (some text, some PDF):
http://ilnp.cs.st-andrews.ac.uk
Yours,
Ran Atkinson
PS: ILNP is not something I do for my day job. So I am not able
to be as quick in responding as some other folks are able
to. Please be patient. :-)
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
