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

[Robin Whittle <[e-mail]>]

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