Subject: [RRG] TRRP's micronet length specification?

From: Robin Whittle <[email-masked]>
Date: Mon, 25 Feb 2008 20:07:05 +1100

Hi Bill,

It has been a while since I read your TRRP material, but I thought,
perhaps incorrectly, that when the ITR queries the authoritative
nameserver about some IP address X, it gets a response not just for
X, but for the entire micronet of which X is a part.  (That micronet
could just be for X, but for the purposes of this discussion, I am
assuming it covers 2, 4 . . 256, 512 etc. addresses as a prefix.)

In your explanation of Waypoint Routers the ITR receives packets for
these destinations in this order:

  1   199.33.225.1    Sends request for this

  2   199.33.225.1

  3   199.33.225.2    Sends request for this

  4   199.33.225.1

Ignoring the Waypoint Router stuff, the responses arrive after these
four packets are sent.

The first response would contain the initial question, so the ITR
finds out for its mapping request regarding 199.33.225.1:

   80,g4,10.0.0.1

   (BTW, I found it confusing that the global DNS would return as
    an ETR address a private network address - maybe it would be
    better to have a public address in place of this.)

The second response has the same information, but is for the request
regarding 199.33.225.1:

   80,g4,10.0.0.1

Assuming for example that you have a micronet:

   199.33.225.0/20

with all 16 addresses therefore mapped to the one ETR (10.0.0.1 in
this example), isn't there a way a single mapping response can tell
the ITR that the address it asked for is part of a larger micronet,
with the one set of mapping information?

Then, the ITR doesn't have to delay packets, bother Waypoint Routers
or bug the authoritative nameserver when it wants to send packets to
any other address in this micronet.

LISP mapping replies do include the full micronet details (EID
starting point and prefix length).

  - Robin

--
to unsubscribe send a message to [email-masked] 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

---

From: "William Herrin" <[email-masked]>
Date: Mon, 25 Feb 2008 15:00:14 -0500

>  assuming it covers 2, 4 . . 256, 512 etc. addresses as a prefix.)

Hi Robin,

TRRP returns information about the single EID IP address that the ITR
is dealing with. The optional Netmask (NM) and Zone Transfer (ZT)
features allow the ITR to expand that knowledge to cover a whole CIDR
block if it finds that it is dealing with more than one included IP
address.

The reason TRRP doesn't immediately act on netmask information
contained in the EID response is that the ITR can't authenticate the
netmask without an additional query. This lesson was learned from a
Bind "cache poisoning" problem in the late '90s where a hacker's DNS
server would return "additional" records for which it was not
authoritative and the caching resolver would accept those records
uncritically.

Regards,
Bill Herrin

-- 
William D. Herrin                  [email-masked]  [email-masked]
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Robin Whittle <[email-masked]>
Date: Wed, 27 Feb 2008 15:22:09 +1100

Hi Bill,

Thanks for explaining why in TRRP the initial map request only
returns the ETR for that destination address, not any further
information about the micronet of adjacent addresses which might
have the same mapping information.

You wrote:

> contained in the EID response is that the ITR can't authenticate
> the netmask without an additional query. This lesson was learned
> from a Bind "cache poisoning" problem in the late '90s where a
> hacker's DNS server would return "additional" records for which
> it was not authoritative and the caching resolver would accept
> those records uncritically.

This would make sense to me if the nameserver which was
authoritative for the micronet was sometimes or always different
from the nameserver which is authoritative for a single IP address
within that micronet.

However, I don't see a reason why this would be the case.

Let's say end-user E has been assigned a prefix of space, which I
call a User Address Block (UAB) - 11.22.33.16/28.  They can do what
they like with the mapping of this space, including dividing it into
as many micronets as they like, right down to 16 micronets, each of
a single IP address.

A micronet is a contiguous range of address space with the same
mapping information.  In Ivip, neither the UAB or micronet need be
prefixes, but in this example they are, because I understand this is
the case with TRRP.

Here we see a little of nearby UABs of other end-users.

            End-user Micronet

  11.22.33.14  D     ] Some micronet of D's.
  11.22.33.15  D     ]

  11.22.33.16  E        ] E's micronet X.
  11.22.33.17  E        ]
  11.22.33.18  E        ]
  11.22.33.19  E        ]

  11.22.33.20  E           ] E's micronet Y.
  11.22.33.21  E           ]
  11.22.33.22  E           ]
  11.22.33.23  E           ]

  11.22.33.24  E              ] E's micronet Z.
  11.22.33.24  E              ]
  11.22.33.26  E              ]
  11.22.33.27  E              ]

  11.22.33.28  E              ]
  11.22.33.29  E              ]
  11.22.33.30  E              ]
  11.22.33.31  E              ]

  11.22.33.32  F     ]  Some micronet of F's.
  11.22.33.33  F     ]

I think it is reasonable to assume that E would use the one
authoritiative nameserver for its whole UAB - all 16 IP addresses.
However, maybe there would be some reason not to do this.

I can't imagine a reason the end-user could not be required to run
the same nameserver for all the addresses of any micronet they define.

An ITR queries the mapping for 11.22.33.27.  In LISP-ALT, as I
recall, the answer comes back with some one or more ETR addresses
and a specification that this mapping applies for the entire EID
prefix 11.22.33.24/29.

Isn't it reasonable to require end-users to use a single mameserver
for each micronet they define?  If so, then I think you can build
your TRRP protocol so the initial mapping response also returns the
full details of the micronet, as does LISP.

   - Robin

---

From: "William Herrin" <[email-masked]>
Date: Wed, 27 Feb 2008 17:38:03 -0500

On Tue, Feb 26, 2008 at 11:22 PM, Robin Whittle <[email-masked]> wrote:
>  > the netmask without an additional query.
>

Hmm. That's a good insight.

If the request for 1.224.33.199.v4.trrp.arpa comes from the server
authoritative for 224.33.199.v4.trrp.arpa, the /25 netmask entry at
25.0.nm.224.33.199.v4.trrp.arpa is in the same authority scope. A
TRRP-aware DNS server could reasonably return the netmask entry in the
"additional" section of the response.

On the other hand, you couldn't return the /23 entry:
23.224.nm.33.199.v4.trrp.arpa is outside the authority of the server
for 224.33.199.v4.trrp.arpa. Unless of course you were assigned the
whole /16 so that your DNS server's scope of authority was
33.199.v4.trrp.arpa.

I considered breaking up the IPv4 TRRP hierarchy the same way the IPv6
hierarchy is broken up: by 4-bit nibble. I decided against it because
it breaks the dotted-quad mental model for IPv4 and isn't strictly
necessary for delegation. You've just offered an excellent
counterpoint: breaking it up by nibble significantly increases the
likelihood that the nm entry will fall within the server's authority
allowing it to be delivered to the ITR in the first query.

This also recommends permitting more than one netmask entry: an nm
entry at the scope of authority boundary and a second one larger than
the authority boundary which covers the whole mask but is only
available with a second lookup.

Ideally we'd break up the authority by each bit in the address, but
that would require a either new protocol other than DNS (a consequence
I'm trying to avoid) or a much longer name which squeezes the amount
of information that can be carried in the 512 byte response (a
consequence I'm also trying to avoid). The nibble-based breakup, as it
turns out, uses no more space than the worst-case dotted-quad name so
it's only cost is the dotted-quad mental model.

What do you think Robin? Is it more valuable to keep the dotted-quad
mental model or is it more valuable to increase the probability that
the netmask entry is available in the EID lookup's scope of authority?

>  the same nameserver for all the addresses of any micronet they define.

Here's the tricky part:

So E's micronet is 199.33.224.128/28. Let's pick an address from that:
199.33.224.131.
The TRRP entry for that EID can come from any of the following scopes
of authority:

131.224.33.199.v4.trrp.arpa.
224.33.199.v4.trrp.arpa.
33.199.v4.trrp.arpa.
199.v4.trrp.arpa.

Practically speaking, this means that E either goes in with everybody
else in 199.33.224.0/24 and uses the same DNS server, or else E has 16
delegations from 224.33.199.v4.trrp.arpa, each exactly one EID large.

That's why the netmask entry for 199.33.224.128/28 is at
28.128.nm.224.33.199.v4.trrp.arpa instead of
28.nm.128.224.33.199.v4.trrp.arpa. The latter would allow cache
poisoning because E's authority at 128.224.33.199.v4.trrp.arpa could
return an entry for 25.nm.128.224.33.199.v4.trrp.arpa allowing him to
pirate the latter half of the /24.

>  full details of the micronet, as does LISP.

Unfortunately, no. This bumps up against one of the limitations of
using DNS as the vehicle for map distribution. To guarantee that extra
bump in performance, TRRP would have to abandon DNS.

The good news is that in some configurations the performance bump is
possible. This means that operators may make a conscious decision to
deploy TRRP in a way that gains the performance bump if they find it
to be sufficiently valuable.

Regards,
Bill Herrin