Robin, In catch-up mode, your suggestion of a need for more discussion of scaling properties is a good one, and something I think that can be accommodated in the next IRON update.
Thanks - Fred fred.l.temp...@boeing.com > -----Original Message----- > From: Robin Whittle [mailto:r...@firstpr.com.au] > Sent: Tuesday, March 09, 2010 6:18 PM > To: RRG > Cc: Templin, Fred L > Subject: Re: [rrg] IRON-RANGER scalability and support for packets from > non-upgradednetworks > > Hi Fred, > > You wrote: > > >> 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. > > I wasn't even thinking about attackers. I don't know anything in > detail about RFC 3971 and I don't think you should require readers to > interpret a document such as this, which has nothing to do with I-R, > in the context of what little they know about I-R - and then to > figure out enough detail about how it would work to convince > themselves that this is scalable. > > To improve on this section of the I-R description, I suggest you > nominate some target numbers for the maximum number of IRON routers > there will ever be, how many individual prefixes of end-user network > "edge" space there could be in total, the maximum number of these > that any one IRON router might need to handle, how many VPs there > would be, how many individual "edge" prefixes there might be in a VP, > how many VP routers there might be per VP prefix, how often each IRON > router will register each of its "edge" prefixes with the one or move > VP routers . . . and then describe in detail how the system works, > with one or more examples. This would enable people to understand in > good physical detail how your system works, without having to read > RFC 3971 and imagine how you would use it in I-R. The reader needs > to be able to estimate the number of packets flowing in the various > roles, the length of the packets, the computational resources > required at each router, the security measures as you mentioned - but > in greater detail - and then to figure out who is paying for all this > and why they would do so. They would also want to see the whole > thing works OK when individual routers fail, become unreachable, are > rebooted etc. > > The only way I could develop my partial understanding if I-R was to > do a lot of imagining, then ask detailed questions, and then have you > provide answers - in a recursive process until I thought I had a good > enough understanding of the proposal. I don't have time to do this > for I-R or other proposals now. However, if you have a clear idea of > how it would work, and what your targets are, you should be able to > write a description which anyone can read and understand, without > having to imagine anything or ask too many further questions. > > There may well be a way of doing it - and I think for anyone involved > in CES architectures, I think I-R certainly is worth understanding. > All I am saying now is that the current state of the proposal leaves > important scaling problems unanswered. Its actually more than that - > it doesn't explain this registration process in anything like > sufficient detail for people to understand how it would work. > > > >>>> 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. > > So do the VP routers act like Ivip's DITRs and LISP's PTRs? To make > this work without unreasonably extending the path between the sending > host and the IRON router which connects to the destination network, > you would need multiple VP routers - say 10 or 20 or so, depending on > how keen you were to minimise path lengths. This number needs to be > part of the explanation regarding operation and scaling properties I > suggested above. > > > >> 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. > > OK - this confirms what I assumed above, about the VP router(s) > acting as DITR(s) or PTR(s). > > I recall that the VP router advertises its VP in the IRON overlay > network. Does it advertise the VP in the DFZ too? It would need to > if it were to receive packets sent from hosts in non-upgraded networks. > > > >>> 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. > > Sorry, I still can't follow this and I don't have time to ask more > about it. > > - Robin > _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
