Re: [rrg] IRON-RANGER scalability and support for packets from non-upgradednetworks

["Templin, Fred L" <[e-mail]>]

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
[e-mail]

> -----Original Message-----
> From: Robin Whittle [mailto:[e-mail]]
> 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
>