Subject: Re: [RAM] DNS usage in NERD

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Jun 2007 13:45:59 +0200

On 2007-06-18 15:30, Robin Whittle wrote:

> Brian wrote:
> 
>> > Indeed, but how can you impose a constraint that DNS zone transfers
>> > etc do not in any way depend on NERD/LISP? That is where I am
>> > puzzled.
> 
> Wouldn't it be good enough that LISP/Ivip or whatever states in
> its architectural RFC that addresses which depend on this
> mapping scheme should not be used for certain purposes, including?:
> 
> 1 - BGP routers, including ITRs and ETRs - obviously.
> 
> 2 - Root and TLD nameservers.  Probably many second level
>     nameservers such as .com.au. too.  Probably including
>     any nameserver which does something under in-addr.arpa
>     on which anyone else's but the operator's addresses
>     depend upon for reverse mapping.
> 
> 3 - Any nameserver on which the mapping scheme depends.
> 
> 4 - Whatever central database servers control the mapping
>     system, including interfaces for user control of mapping
>     of their IP addresses, servers for all push and pull update
>     activities and any independent systems which monitor
>     where a mobile host is connecting, and automatically
>     initiate changes to the mapping database if the mobile
>     host's current link fails.
> 
> Then all the critical nameservers have ordinary BGP-accessible
> addresses, so their zone transfers go via ordinary BGP,
> irrespective of what the mapping system does.

I think I would prefer Eliot to comment on getting the circularity
out of NERD, but my reaction is that this list of constraints
may well be necessary and sufficient, but it's operationally
error-prone. So I want to remove all possible dependencies
for something so basic as bootstrapping the mapping database.

I'm sticking to my own suggestion: use well-known IP addresses
to bootstrap NERD, thereby avoiding any possible circular dependency
involving DNS by construction.

I certainly agree that enumerating the addresses that must never
be mapped, to avoid circularity, is a good thing.

     Brian

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 Jun 2007 18:26:13 +0200

> involving DNS by construction.

Why not?  You could even boost all the  NERDs and distribute them 
without any change to the existing spec.  All you need to do is 
advertise those addresses and have some method of scaling their use.
> be mapped, to avoid circularity, is a good thing.

Again, that's an easy check: anything in the NERD should not be used by 
infrastructure critical to LISP itself.  In fact, anyone could verify 
that this is true by stepping through the infrastructure itself and 
looking up associated IP addresses of web servers, name servers, etc.

Let's not confuse mechanism for resource.

Eliot

---

From: Robin Whittle <[email-masked]>
Date: Fri, 29 Jun 2007 10:59:19 +1000

> involving DNS by construction.

Assuming there will be a single LISP/Ivip, the new system will be a
centrally planned, permanent, piece of infrastructure.  I think it would
be feasible and desirable in terms of simplicity to reserve particular
IP addresses for particular functions which are in any way crucial to
LISP/Ivip.  This shouldn't mean a single point of failure, if UDP
communications to a set of anycast servers can perform the functions
required.  For TCP the separate servers idea wouldn't be so robust, so
it should be possible to use set of anycast routers with private network
tunnels to a central or distributed server farm.

Like the root nameservers, the router and servers at these addresses
would need to be able to withstand any botnet attack which is likely to
be launched.  That threat will grow with as more PCs have faster
upstream links, such as with fibre to the premises, as Verizon is now
having great success with.

> be mapped, to avoid circularity, is a good thing.

I agree.  It might be best to have a config file in every ITR for ranges
of addresses to which packets will never be tunneled.  This would remove
the danger of malicious or accidental database changes being received
which would, without the config file limits, would cause packets to be
tunneled to infrastructure-critical addresses.

  - Robin