Tony,

Please see attached an update to the IRON-RANGER rebuttal that
outlines the DoS prevention capabilities of the architecture.

Fred
fred.l.temp...@boeing.com



________________________________
From: Tony Li [mailto:tony...@tony.li]
Sent: Monday, February 22, 2010 11:45 AM
To: Templin, Fred L; 'RRG'
Subject: Re: IRON-RANGER rebuttal




On 2/11/10 1:29 PM, "Templin, Fred L" <fred.l.temp...@boeing.com> wrote:
Tony - please see attached for the IRON-RANGER rebuttal.

Received and incorporated.  Were you thinking of this as a global name change 
for your proposal?  If so, please unicast to me.

Thanks,
Tony
The Internet Routing Overlay Network (IRON)
[draft-templin-iron] is a scalable Internet routing architecture
that builds on the RANGER recursive enterprise network hierarchy
[RFC5720]. IRON bonds together participating RANGER networks
using VET [draft-templin-intarea-vet] and SEAL
[draft-templin-intarea-seal] to enable secure and scalable
routing through automatic tunneling within the Internet core.
The IRON-RANGER automatic tunneling abstraction views the
entire global Internet DFZ as a virtual NBMA link similar
to ISATAP [RFC5214].

IRON-RANGER is an example of a Core-Edge Separation (CES)
system. Instead of a classical mapping database, however,
IRON-RANGER uses a hybrid combination of a proactive dynamic
routing protocol for distributing highly aggregated Virtual
Prefixes (VPs) and an on-demand data driven protocol for
distributing more-specific Provider Independent (PI) prefixes
derived from the VPs.

The IRON-RANGER hierarchy consists of recursively-nested
RANGER enterprise networks joined together by IRON routers
that participate in a global BGP instance. The IRON BGP
instance is maintained separately from the current Internet
BGP Routing LOCator (RLOC) address space (i.e., the set of
all public IPv4 prefixes in the Internet). Instead, the IRON
BGP instance maintains VPs taken from Endpoint Interface
iDentifier (EID) address space, e.g., the IPv6 global unicast
address space. To accommodate scaling, only O(10k) - O(100k)
VPs are allocated e.g., using /20 or shorter IPv6 prefixes.

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.
IRON routers therefore keep track of only their customer base
via the FIB entries and keep track of only the Internet-wide
VP database in the RIB.

IRON routers propagate more-specific prefixes using secure
redirection to update router FIBs. Prefix redirection is
driven by the data plane and does not affect the control
plane. Redirected prefixes are not injected into the RIB,
but rather are maintained as FIB soft state that is purged
after expiration or route failure. Neighbor unreachability
detection is used to detect failure.

Secure prefix registrations and redirections are accommodated
through the mechanisms of SEAL. Tunnel endpoints using SEAL
synchronize sequence numbers, and can therefore discard any
packets they receive that are outside of the current sequence
number window. Hence, off-path attacks are defeated. These
synchronized tunnel endpoints can therefore exchange prefixes
with signed certificates that prove prefix ownership in such
a way that DoS vectors that attack crypto calculation overhead
are eliminated due to the prevention of off-path attacks.

CEs can move from old RANGER networks and re-inject their PI
prefixes into new RANGER networks. This would be accommodated
by IRON-RANGER as a site multihoming event while host mobility
and true locator-ID separation is accommodated via HIP [5201].
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg

Reply via email to