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

["William Herrin" <bill@herrin.us>]

On Tue, Feb 26, 2008 at 11:22 PM, Robin Whittle <rw@firstpr.com.au> wrote:
>  > 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 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.

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?


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

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.


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

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


-- 
William D. Herrin herrin@dirtside.com bill@herrin.us
3005 Crane Dr. Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
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