Home page logo

nanog logo nanog mailing list archives

Re: using IRR tools for BGP route filtering
From: bmanning () vacation karoshi com
Date: Wed, 21 Jun 2000 14:49:17 +0000 (UCT)

2. most large isps aren't going to be happy about config'ing their
routers off of another provider's registry. so, every provider would
in theory need to run their own registry. 

        A fine idea. If I may be  permitted to flog a dead horse,
        the "right" way is to encode RPSL data in the in-addr.arpa or
        ip6.int tree.


   a. the independant registries generally store a local copy of the
      other registries for config use. this was fine when there were
      a few [like ripe, mci, ans] but not so fine when N grows unbounded.
      co-ordination could very quickly become a nightmare.

        Not a real problem.  You manage the data in the prefixes that are
        delegated to you.  Coordination is managed as the DNS is managed.

   b. who "owns" the local registry/config generator in the ISP? [noc,
      install IS, neteng, security?] when its interfacing with customer
      databases, responsible for config'ing the entire network, affects
      peering, and is a publically accessible server, everyone is gonna
      want a piece of it. bureaucracy is great for insuring nothing gets
      done. thats assuming the resources [money, people, time] are
      available to create & maintain this database server anyway.

        The folks doing the DNS. Coordinating w/ the other interested
        parties in the company.

   c. uh, who is responsible for "bad" data? remember the
      object? [followup: why was it put in?] how is this any different
      than just announcing bad data? is someone going to verify by hand
      all of the data registered? since there is no authoritative 1 to 1
      mapping between ownership and routing, how can it truly be verified?

        Bad data should only occur if you intentionally spoof the DNS.
        "Interesting" data in the existing IRR came from a small handful
        of engineers who wanted to point out weaknesses in the RA policies.

        If you place the RPSL constructs in the delegation tree, its much
        easier to track the mapping of delegation & announcement.

        (There is no ownership here)

3. given variances in systems, theres going to be variances in
propgation. remember when ans only updated their router filters twice
a week? but mci was updating once a day? will your customers hold
_you_ responsible if joebob isp decides to only update once
a week? 


its much easier to attack this problem at the edge, as was pointed out
while i was composing this. verifying and changing filters per customer
is really much better than verifying and changing filters *per peer*.
[per week, day, hour, what?]

build in safegaurds in the peering agreements, if you must. at some point,
i believe it is cheaper [in terms of resources, politics, and network
flexibility] to trust peers to the extent one can [in either preventing
or resolving issues].

and if you can't trust 'em at all? maybe one shouldn't peer with them. 
oh, wait. that's another can of worms. but hey, the net changes so fast,
maybe they'll be bought, sold, or vanish next week.



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]