Re: [RRG] Taxonomy: 25 questions

["William Herrin" <bill@herrin.us>]

Hi Robin,

Good list of questions. Here are some updates with respect to TRRP's fit.

On Tue, Apr 1, 2008 at 8:04 PM, Robin Whittle <rw@firstpr.com.au> wrote:
>  [Q02]
>  For the proposals for which the Q01 answer was No, do they aim to
>  provide a mechanism by which there is no loss of connectivity for
>  any hosts, as the system is deployed, including for communications
>  to and from networks with no upgrades?
>
>   TRRP            Yes, but I can't recall exactly how at present.

The answer is indeed yes, but the how is a little complex. BGP never
actually goes away with TRRP. TRRP starts by extending PI from BGP's
/24 boundary down into micronets (longer than /24) and announcing
covering routes into BGP which lead to an ITR for folks who haven't
yet deployed their own ITR. Once deployment begins to get wide, the
boundary between routes allowed into BGP and maps delivered by TRRP
starts to shift so that BGP stops carrying most /24's, /23's, etc.
This shift continues until it reaches the optimal equilibrium between
full-push BGP and cached-pull TRRP as determined by the network
operators and their customers.

This is accomplished in lots of little steps. At each step it never
takes more than a cheap, simple action to stay connected. The most
disruptive part of the transition comes when the the first few folks
in the core want to drop the /24's from BGP. At that point, some folks
will have to deploy a machine that can host a GRE endpoint and DNS
entries that point to it.



>  [Q04]
>  How fast can an end-user's mapping change be sent to all ITRs?
>
>   TRRP       As for LISP-ALT, since both use a global query
>              server network.  TRRP doesn't have a workable
>              Notify system.  It has a limited cache invalidation
>              system where an unreachable ETR leads to an ICMP
>              message to an ITR, which can then issue a new
>              mapping request.

TRRP has a notification system: http://bill.herrin.us/network/trrp-preempt.html

Notification is an optional component. The system is designed to work
acceptably without it but work faster with it.

Without notifications, the maximum effective change rate per map is
about once every 10 seconds. That interval has enough overhead that
folks who are just doing multihoming service restoration will normally
back it off further. For every communication where notification is
supported at both the ITR and map server, TRRP can in the average case
switch to the new map within a fraction of a second after the map is
published.




>  [Q06]
>  Does the end-user have to pay for traffic directed to their micronet
>  / EID prefix?
>
>   TRRP       ?

I expect the answer is yes, but it's not formal part of the
architecture. The most accurate answer is that the end-user can do
whatever he wants to do. If he gets acceptable connectivity without
paying someone to reroute traffic his direction from a BGP supernet
route then the answer is no. If he doesn't, then something like
http://bill.herrin.us/network/trrp-aapip.html or
http://lists.arin.net/pipermail/ppml/2008-March/010475.html comes in
to play and he'll  pay the aggregator.



>  [Q08]
>
>  Therefore, what functionality is required in the ITR and ETR?
>
>   Ivip       No reachability functionality, except as a by-product
>              of Ivip's inbuilt PMTUD and fragmentation management
>              system (yet to be finalised, but see my PMTUD-frag
>              page).
>
>   APT        } ITRs must individually determine reachability
>   LISP-NERD  } of each ETR and whether the ETR can reach the
>   LISP-ALT   } destination.  Also, I think in LISP, the ETR
>   TRRP       } may, or must, somehow tell ITRs about reachability
>                of other ETRs which are in the mapping.  (But
>                how does the ETR know exactly what mapping the
>                ITR has??)

For TRRP, the ETR need only be a dumb GRE endpoint with an acl
specifying the destination addresses which are allowed to use it. It
may do more than that and you can get better results if it does, but
dumb GRE endpoint is the base requirement. The ITR is responsible for
finding currently valid ETRs in a timely manner (primarily by looking
them up from the map server) and engaging in much of the complex
activity.


>  [Q09]
>
>  Therefore, is the system a monolithic approach, permanently
>  integrating reachability and multihoming service restoration
>  decision-making functions in the map-encap scheme, or enabling and
>  requiring end-users to supply their own reachability and
>  decision-making systems?
>
>   APT        } Monolithic system.  Since all these do not
>   LISP-NERD  } get end-user mapping changes to all ITRs
>   LISP-ALT   } quickly, the map-encap system must do all
>   TRRP       } reachability testing and make all decisions.
>                ITRs and ETRs must do this, using relatively simple
>                mechanisms and mapping data which are hardwired into
>                the entire map-encap system.  This will not
>                satisfy all needs of end-users, since it is
>                impossible to anticipate all the ways end-users might
>                want to test reachability and since it is impossible
>                to define exceedingly complex or extensible
>                arrangements into the map-encap scheme itself.
>                Also, ITRs acting alone are a poorly scalable and
>                inefficient mechanism for testing reachability and
>                for making decisions.

This is not an accurate description for TRRP. TRRP requires end-users
to supply their own reachability and decision-making systems. The ITRs
have some flexibility based on local knowledge but they're not
expected to be able to be able to make complete routing decisions on
their own.

The workings of the decision-making systems are intentionally not a
part of TRRP's specification. I foresee them starting as simple
pingers and advancing to something akamai-like.


>  [Q10]
>
>  Does the proposal tackle the PMTU and Fragmentation problem?
>
>   TRRP       No.

Yes, it does. See http://bill.herrin.us/network/trrp.html subheading
"Fragmentation."


>  [Q13]
>
>  Does the system aspire to support mobility, and if so, how?
>   TRRP       } have not yet been explored in detail.

Yes as described in http://www.ops.ietf.org/lists/rrg/2008/msg00766.html



>  [Q14]
>
>  What is the granularity of address management?
>
>   APT        } Not yet clear, but I think they can all support
>   LISP-NERD  } EID prefixes starting at any IPv4 address or
>   LISP-ALT   } IPv6 /64, in CIDR prefix format and therefore
>   TRRP       } powers of two lengths on binary boundaries.

TRRP: primary granularity is one IP address. Administrative grouping
can be arbitrary; its an implementation detail in the map server.
Efficiencies are gained at power-of-two boundaries, 4-bit boundaries
and 8-bit boundaries.


>  [Q17]
>  Where are ITRs placed?
>   TRRP       I am not sure - I guess in provider and perhaps
>              end-user networks.

"Anywhere." The ITR can be on any originating host (or nat gateway)
with a public IP address, way deep in the core, around the other side
being fed by a supernet route or anywhere in between. It's more cost
effective to place them close enough to the edge that they only deal
with sub-gigabit traffic flows, but not mandatory.


>  [Q18]
>  Where are ETRs placed?
>
>   TRRP       I am not sure - I guess in provider and perhaps
>              end-user networks.

The ETR can be anywhere that can natively reach the tunneled
destinations via a direct connection or an IGP.


>  [Q19]
>
>  Does the internal routing system of ISP networks need to know about
>  each end-user network's micronet (EID prefix)?  In other words, can
>  an ETR in an ISP network put out raw, decapsulated, traffic packets
>  it receives from an ITR and expect the internal routing system to
>  take these packets to the proper destination?
>
>   TRRP       ? I guess so.

In part, it depends on the ETR placement. The ISP only needs to know a
route if the ETR is at the ISP. If the ETR is deployed at the customer
premise then the ISP doesn't need an IGP route to it.

The ISP will need to know not to drop packets with the micronet's
source addresses.


>  [Q20]
>
>  Does every packet addressed to a micronet (EID prefix) have to go
>  through an ITR and an ETR?  If the answer is No to this question,
>  then it means that the proposal expects packets to be delivered to
>  the correct ETR not just by the map-encap scheme, but also by the
>  local routing system of any ISP network which is configured to have
>  the end-user's prefix in its local routing system.  Where two ISP
>  networks have ETRs for the one end-user network, and they rely on
>  the internal routing system to deliver raw decapsulated packets from
>  the ETR to the proper point which links to the end-user network,
>  then each such ISP must have the micronet / EID of the end-user's
>  network in its internal routing system.  For consistent operation,
>  this means the internal routing system needs to perform the same
>  functions as an ITR, including deciding whether this ETR is
>  reachable and has a connection to the end-user network (and if not
>  so, then tunneling the packet to another ISP's network and its ETR,
>  which requires an ITR function).
>
>   TRRP       ?

As with Q19.



>  [Q22]
>
>  Following the above answers, can the sending host traceroute through
>  the tunnel?
>
>   Ivip       Yes, with a somewhat modified traceroute program.  This
>              would also be able to identify the ITR and ETR.
>
>   APT        } No, unless the ITR did heroics to convert the ICMP
>   LISP-NERD  } messages it receives into ICMP messages with the
>   LISP-ALT   } correct data for a standard or modified traceroute
>   TRRP       } program on the sending host to recognise.

Note #1: as the originating host may function as a TRRP ITR, a
modified traceroute would also work for TRRP. TRRP's traceroute issues
are noted here: http://bill.herrin.us/network/trrp-breaks.html

Note #2: ICMP unreachables as commonly implemented include enough of
the original packet that the ITR can translate it into valid
unreachable for the source with no particular heroics. Not every case
to be sure and the standards don't require it, but when I looked at
the packets they usually had enough data.


>  [Q23]
>
>  Following the answer about outer source address, how can an ETR
>  perform the same filtering on packets it decapsulates as an ISP
>  border router might perform on packets coming into the ISP network -
>  specifically, rejecting any packets from outside the ISP network
>  which have source addresses matching any internal prefix of that
>  network?  See note below my signature for more on this.
>
>   APT        } The ETR would need to do a complete, expensive,
>   LISP-NERD  } filter operation on the inner source address
>   LISP-ALT   } against whatever list of prefixes the ISP's
>   TRRP       } border routers use - which could be huge in a
>                large ISP network.

With TRRP, the ETR need only filter for the addresses which it serves.
This could be an ISP's entire border list but it could also be a
customer's single micronet or anything in between depending on where
you place the ETR.



>  Even if the end-user runs their own ETR, the ISP - or ISPs - who
>  provide connectivity are likely to want to ensure there is some
>  source address filtering on the decapsulated packets.
>
>  An attacker could send a packet from anywhere to the ETR and the
>  decapsulated packet could have the source address of any host in the
>  ISP's network.  This is likely to be a security concern, if only
>  because an attacker could prompt the destination host to send
>  packets to the host at that spoofed address.

I think this concern fits in a different location than you think.

Addresses used within an end-user's network are out-of-scope for the
ISP and always have been. A user can generate bad packets just as
easily now as they can after deploying an ETR.

The ISP needs to assure that the source addresses on packets reaching
them from the user may legitimately do so. That's not so problematic
at the ETR but it becomes a problem in two other locations:

1. The ITR. The tunnel packet's source may be valid but the
encapsulated packet's source may not be. I gather this doesn't apply
to Ivip but it certainly applies to all the rest.

2. The ISP border with his upstream. Filtering for the ISP's 10
prefixes that change once a year is not so problematic. Filtering for
the hundreds of downstream micronets that change weekly is. This
problem will appear with any solution that attempts to restore
provider-independent addresses to the masses, not just map-encap.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin@dirtside.com bill@herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg