Subject: Re: [rrg] Sundry ILNP confusions...

From: RJ Atkinson <[email-masked]>
Date: Wed, 3 Feb 2010 18:05:50 -0500

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. :-)

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 04 Feb 2010 11:02:57 +0800

<skiped>
> it is not surprising that the same IPv6 constraint remains.

My question is whether there is any association between I _records_ and L
_records_ in the _DNS_. This is the key point of these arguments. 

Xiaohu