Robin, > -----Original Message----- > From: Robin Whittle [mailto:r...@firstpr.com.au] > Sent: Monday, March 08, 2010 10:15 AM > To: RRG > Cc: Templin, Fred L > Subject: IRON-RANGER scalability and support for packets from > non-upgradednetworks > > Hi Fred, > > In "Re: [rrg] Recommendation and what happens next", you wrote: > > > Hi Robin, > > > > About IRON-RANGER below: > > ... > > >> That leaves four CES architectures: > >> > >> IRON-RANGER > >> Ivip > >> LISP > >> TIDR > >> > >> TIDR can't solve the routing scaling problem because its "mapping" is > >> almost identical to advertising individual end-user network prefixes > >> in the DFZ. I have argued that IRON-RANGER is not yet sufficiently > >> developed to understand its security and scaling challenges - and > > > > The points on security and scaling have been addressed > > in my latest rebuttal; see: > > > > http://www.ietf.org/mail-archive/web/rrg/current/msg06158.html > > I don't understand the mechanisms by which potentially very large > numbers of IRON routers repeatedly and continually register with > potentially multiple VP routers. These IRON routers could be > anywhere and so could the VP routers. In that message, the most I > can discern about this mechanism is: > > IRON routers lease portions of their VPs as Provider > Independent (PI) prefixes for customer equipment (CEs), > thereby creating a sustaining business model. CEs that lease > PI prefixes propagate address mapping(s) throughout their > attached RANGER networks and up to VP-owning IRON router(s) > through periodic transmission of "bubbles" with authenticating > and PI prefix information. Routers in RANGER networks and IRON > routers that receive and forward the bubbles securely install > PI prefixes in their FIBs, but do not inject them into the RIB. > > I have a rough idea of what you are trying to achieve with this > mechanism, but I have no idea what the mechanism is - "bubbles" > doesn't give me any understanding of exactly how the IRON routers > would do this securely. Only when I understand exactly how they > would do this could I estimate the scaling and security problems > which are no-doubt involved.
I have been using the term "bubbles" to keep this at a high level and to avoid getting bound up into talking about specific mechanisms. But, it sounds like you want to know more about the specifics, so I can tell you that a "bubble" is actually an IPv6 Router Advertisement (or moral equivalent) using the RFC3971, Section 6.1 authorization model. In this model, routers are given certificates from a trust anchor which authorizes them to act as routers and to advertise a certain set of subnet prefixes. Other routers in RANGER use the certificates to verify authorization. The scalability part is addressed in the new text I have added to the rebuttal. What we really need to avoid is having off-path attackers injecting lots of bogus RAs that cause IRON routers to have to perform lots of unnecessary crypto. By shutting down off-path spoofing, IRON-RANGER ensures that end sites that act with integrity will not overload correspondents with crypto-busting DoS attacks. End sites that do NOT act with integrity on the other hand will be easy to detect and can safely be blacklisted. > >> there's no apparent method of supporting packets sent from > >> non-upgraded networks. > > > > Non-upgraded IPv4 networks will continue to work as they > > always have. Do you mean non-upgraded IPv6 networks? > > I mean when you start installing IRON routers, these will collect > packets addressed to "edge" addresses (or whatever the new subset of > "EID" space is called in I-R) Virtual Prefixes (VPs) - but, VPs cover what IRON-RANGER calls Endpoint Interface iDentifier (EID) prefixes. > from the ISP networks they are > installed in. Packets sent by hosts in those networks will be > handled according to I-R principles and the recipient networks of > those packets will get the benefits (portability, multihoming and > inbound TE) for those packets. > > But what of packets sent from hosts without IRON routers? AFAIK, > there's no equivalent in I-R to Ivip's DITRs or LISP's PTRs. Considering for now only IPv6 as EID space, an IPv6 host will be connected to a network that is ultimately served either by an IRON VP or a "native" IPv6 prefix. If an IRON VP, then routing is naturally via the IRON. If a "native" IPv6 prefix (e.g., a 2001::/ derivative), packets will follow default or more-specific routes as usual but will encounter an IRON VP router if the destination is covered by a VP. > > Assuming the latter, let's consider that today we have > > two separate BGP instances - the IPv4 BGP instance and > > the IPv6 BGP instance. The IPv6 BGP instance carries a > > set of IPv6 prefixes (e.g., 2001:: derivatives) that are > > routed in the IPv6 Internet in the "traditional" sense. > > What IRON-RANGER is doing is essentially creating a > > *third* BGP instance - one that carries a new set of > > IPv6 Virtual Prefixes (VPs) that are distinct from the > > prefixes carried in the traditional IPv6 BGP instance. > > > > Due to routing scaling issues, IRON-RANGER expects that > > growth of this new third BGP instance will flourish while > > growth of the traditional IPv6 BGP instance will level > > off. In order to support what I think you mean by > > non-upgraded networks then, it only requires that IPv6 > > routers connected to the IRON also participate in the > > traditional IPv6 BGP instance. For that matter, not all > > IRON routers need to participate, but at least some must. > > > >> As far as I know, there have been no > >> substantial counter-arguments to these critiques. > > > > Do the above points address your concerns? > > It is 5AM here, and I can't clearly translate what you wrote into an > answer to the concern I mentioned above. But that doesn't mean it > doesn't address it. > > > Hmm, maybe these two IPv6 BGP instances I alluded to don't > > even need to be kept separate - as long as Virtual Prefixes > > can be kept distinct from non-virtual ones. This I think is > > the key point, and would greatly reduce the complexity. > > I am definitely not going to think about this until I get some sleep! OK; rest well. Fred fred.l.temp...@boeing.com > - Robin > _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
