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

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

Robin,

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

>   - Robin
>