ICANNWatch
 
  Inside ICANNWatch  
Submit Story
Home
Lost Password
Preferences
Site Messages
Top 10 Lists
Latest Comments
Search by topic

Our Mission
ICANN for Beginners
About Us
How To Use This Site
ICANNWatch FAQ
Slash Tech Info
Link to Us
Write to Us

  Useful ICANN sites  
  • ICANN itself
  • Bret Fausett's ICANN Blog
  • Internet Governance Project
  • UN Working Group on Internet Governance
  • Karl Auerbach web site
  • Müller-Maguhn home
  • UDRPinfo.com;
  • UDRPlaw.net;
  • CircleID;
  • LatinoamerICANN Project
  • ICB Tollfree News

  •   At Large Membership and Civil Society Participation in ICANN  
  • icannatlarge.com;
  • Noncommercial Users Constituency of ICANN
  • NAIS Project
  • ICANN At Large Study Committee Final Report
  • ICANN (non)Members page
  • ICANN Membership Election site

  • ICANN-Related Reading
    Browse ICANNWatch by Subject

    Ted Byfied
    - ICANN: Defending Our Precious Bodily Fluids
    - Ushering in Banality
    - ICANN! No U CANN't!
    - roving_reporter
    - DNS: A Short History and a Short Future

    David Farber
    - Overcoming ICANN (PFIR statement)

    A. Michael Froomkin
    - When We Say US™, We Mean It!
    - ICANN 2.0: Meet The New Boss
    - Habermas@ discourse.net: Toward a Critical Theory of Cyberspace
    - ICANN and Anti-Trust (with Mark Lemley)
    - Wrong Turn in Cyberspace: Using ICANN to Route Around the APA & the Constitution (html)
    - Form and Substance in Cyberspace
    - ICANN's "Uniform Dispute Resolution Policy"-- Causes and (Partial) Cures

    Milton Mueller
    - Ruling the Root
    - Success by Default: A New Profile of Domain Name Trademark Disputes under ICANN's UDRP
    - Dancing the Quango: ICANN as International Regulatory Regime
    - Goverments and Country Names: ICANN's Transformation into an Intergovernmental Regime
    - Competing DNS Roots: Creative Destruction or Just Plain Destruction?
    - Rough Justice: A Statistical Assessment of the UDRP
    - ICANN and Internet Governance

    David Post
    - Governing Cyberspace, or Where is James Madison When We Need Him?
    - The 'Unsettled Paradox': The Internet, the State, and the Consent of the Governed

    Jonathan Weinberg
    - Sitefinder and Internet Governance
    - ICANN, Internet Stability, and New Top Level Domains
    - Geeks and Greeks
    - ICANN and the Problem of Legitimacy

    Highlights of the ICANNWatch Archive
    (June 1999 - March 2001)


     
    This discussion has been archived. No new comments can be posted.
    Secret, Closed WHOIS Meeting Excludes Privacy Advocates | Log in/Create an Account | Top | 70 comments | Search Discussion
    Click this button to post a comment to this story
    The options below will change how the comments display
    Threshold:
    Check box to change your default comment view
    The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
    Decoupling WHOIS and DNS via Mesh Registry
    by Anonymous on Tuesday May 24 2005, @05:17AM (#15338)
    Decoupling WHOIS and DNS via Mesh Registry

    One of the major mistakes made in the last century
    was hooking DNS to WHOIS and allowing lawyers to
    blur the two into a regulatory regime.

    Mesh Registry technology will help to untable that
    .WEB [Yes, .WEB is the test TLD for the new Mesh
    Registry]

    The Mesh Registry is 100% distributed to small
    low-cost always-on nodes. There is no single
    disk drive that holds "the Registry". All of
    the nodes collectively keep track of the
    Registry entries. Each node of course has a
    NVRAM copy of its own data and has copies for
    7 other nodes. The 8 nodes are able to rebuild
    each other, with passwords and certs and a
    variety of other cross-verification methods.

    When a new name enters the name-space, the node
    it starts on finds 4 sponsors and agrees to
    sponsor 4 new nodes. That opens 4 slots for each
    new node entered. The sponsors make sure that
    the new name is unique. There is no central
    "registry". The ISOC/ICANN/ARIN gestapo would
    have to find and physically destroy a very large
    percentage of the nodes to destroy the TLD.

    Without having computers, imagine doing this with
    humans. Imagine 4 people start .WEB. Imagine
    they select the names Chris.WEB, Simon.WEB,
    Bill.WEB and Jon.WEB. Those 4 surely can remember
    the other 3 names. They can each go find 4 more
    people to sponsor and remember those names.
    There would then be 16 people in the mesh, 4
    founders and 4 affiliates per founder. Imagine
    they stop and synch up and all trade certs and
    other information. Imagine 8 of the people
    show up at various ISOC/ICANN/ARIN meetings and
    are faced with rebuilding the other 8 from
    scratch on new nodes when they hear that the
    other 8 have been destroyed by the thought
    police. Can the 8 remember all 16 names and
    information to rebuild the entire "registry" ?

    What if special sleeper nodes are added with
    ROMs that can not be changed. What if they
    are called on to provide historical data if
    requested. Can they assist in rebuilding the
    mesh ? Is it best to turn those on and when
    "full" turn them off and not allow anyone to
    have physical access, unless an emergency calls
    for their information?

    Is the old .WEB registry a sleeper node ?
    [ Reply to This | Parent ]
    Re:Decoupling WHOIS and DNS via Mesh Registry
    by Anonymous on Tuesday May 24 2005, @05:32AM (#15339)
    > i receive a bgp announcement from a new peer, but the announcement
    > was originated two weeks ago (shockers! a stable route); was the
    > asserted path to my new peer valid when the announcement was
    > originated two weeks ago? once your mind starts down such paranoid
    > paths, the void opens before one's eyes.

    Which is EXACTLY why we need to remember that we are NOT trying to come
    up with the perfect solution. We have operational issues *TODAY* that
    we are trying to address.

    - We have people (admittedly accidentally) advertising prefixes that
        they do not own and thereby overloading BGP. See the talk at the
        latest NANOG.

    - We have people intentionally out there forging /24's as an attack.

    - We have OTHER people out there flooding the networks with their /24's
        so that they are less vulnerable to attack by forged /24's, and
        thereby exacerbating the BGP overload problem.

    Almost any of the popular proposals (and some of the really old ones)
    will address all of these issues. But only if they are deployed. We,
    as responsible operators/architects/vendors/coders need to pick a
    solution and field it. It may well be an interim solution, but we MUST
    act, and soon. We are already seeing the stress patterns, without
    reinforcement it is only a matter of time before we see wholesale
    fractures. Given that any solution will have an implementation and
    deployment delay, we dare not wait much longer.
    [ Reply to This | Parent ]
    Re:Decoupling WHOIS and DNS via Mesh Registry
    by Anonymous on Tuesday May 24 2005, @05:35AM (#15340)
    > -- You must not rely on routing to secure routing.

    I would like to point out that this goal is unnecesary.

    First, we need to understand that for ANY solution to be deployable, it
    must be incrementally deployable. We do not get an Internet-wide flag
    day for BGP. The Internet must continue to function, regardless of the
    percentage of NLRI that are actually authenticated. For the forseeable
    future, we will need to have a path selection policy that rejects any
    information that clearly fails authentication, continues to use
    unauthenticated prefixes, and prefers authenticated vs. unauthenticated.

    Second, validating a certificate must be doable even if the router is
    using unauthenticated prefixes to do so. Remember that the crypto
    properties of a certificate must make it unforgeable, and that routers
    must have at least one reference point in the web of trust. If the
    route to the root of that web is spoofed, then the crypto will not be
    able to validate any other certificates in the web, but this is NOT an
    authentication failure -- the related NLRI are just unauthenticated, not
    unuseable.

    Obviously, authenticating the root certificate NLRI are our top
    priority, but the system MUST continue to operate even without this.
    This is the only way to truly address the chicken and egg problem. I
    think that this also highlights the need for multiple, diversely routed
    certificate authorities.
    [ Reply to This | Parent ]
    .LAN is the Test TLD for the New Mesh Registry
    by Anonymous on Tuesday May 24 2005, @05:51AM (#15341)
    .LAN is the Test TLD for the New Mesh Registry

    Look at the code.

    No one will go near .WEB for fear of being sued.

    .WEB is dead.
    [ Reply to This | Parent ]
    Your .ORG and .NET tax dollars at work.
    by Anonymous on Tuesday May 24 2005, @06:13AM (#15343)

    ICANN and the ISOC to the rescue with their NEW well-funded Software Company spin-offs ?

    Your .ORG and .NET tax dollars at work.

    o with sbgp, the assertion of the validity of asn A announcing
          prefix P to asn B is congruent with the bgp signaling itself,
          A merely signs the assertion in the bgp announcement.

      o with sobgp, the assertion is in an external database with
          issues such as
          - data correctness & completeness

    The database is built just like BGP routing information databases are built today. Each AS originates their piece, and every other AS puts the pieces together to form the whole. There is no centralized registry.

          - data consistency
          - update frequency

    These two are up to the originating AS'. If you update your certificates in real time, the same way you do your routes (and I can easily argue you don't actually update your routes in real time, actually), then you will get congruent, up to date information. Those AS' who do not update their certificates in real time will not have real time data in the database, just like BGP is today.

          - granularity (bgp is per-prefix, and this is used by real
              folk to do traffic eng etc). consider the mess of keeping
              this up to date and correct in a super irr.

    There is no "super irr." There is no centralized database in soBGP.
    [ Reply to This | Parent ]
    Re:Decoupling WHOIS and DNS via Mesh Registry
    by Anonymous on Wednesday May 25 2005, @05:28AM (#15350)
    Note: There are no Registrars. There is no Registry.

    Do you think Joe Sims and the DOC and DOJ understand that ?

    Quick, cash the checks, the revenue stream ends soon.
    [ Reply to This | Parent ]


    Search ICANNWatch.org:


    Privacy Policy: We will not knowingly give out your personal data -- other than identifying your postings in the way you direct by setting your configuration options -- without a court order. All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 by ICANNWatch.Org. This web site was made with Slashcode, a web portal system written in perl. Slashcode is Free Software released under the GNU/GPL license.
    You can syndicate our headlines in .rdf, .rss, or .xml. Domain registration services donated by DomainRegistry.com