Subject: [RRG] a new (not few) draft towards convergence

From: Lixia Zhang <[email-masked]>
Date: Tue, 22 Jul 2008 09:56:06 -0700

> To contribute to the convergence effort, we made a first (drafty)  
> draft on the roles and differences of map&encap vs transport  
> multipath solutions.  a link to the draft is
>  http://www.cs.ucla.edu/~lixia/draft-efit-mapping-multipath-00.txt
>
> We are looking forward to your comments!
>
> Lixia

haste makes waste: I just noticed that the subject line of my ealrier  
posting was wrong--there is only one *new* draft, not a few :-)
(I looked the keyboard, f and n are pretty far apart, not sure how the  
typo was made)
in any case: a revised version has been posted (further clarified  
reasoning and discussions)

on behalf of the authors (Dan Jen, Michael, Dan Massey, Lan Wang,  
Beichuan Zhang)

--
to unsubscribe send a message to [email-masked] 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

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 24 Jul 2008 10:57:25 +0200

Hi Lixia,

  some comments on your draft:

Le 22-juil.-08 à 18:56, Lixia Zhang a écrit :

> haste makes waste: I just noticed that the subject line of my  
> ealrier posting was wrong--there is only one *new* draft, not a  
> few :-)
> (I looked the keyboard, f and n are pretty far apart, not sure how  
> the typo was made)

[snip]

> 1.  Introduction

[snip]

>    In addition, to solve the routing scalability via a transport level
>    solution, the effect will become significant only when a  
> significant
>    portion of edge sites deploy the new solution.  However since
>    Internet is made of millions of autonomous administrative parties,
>
>
>
> Jen, et al.             Expires January 22, 2009                 
> [Page 4]
> Internet-Draft            Mapping and Multipath                July  
> 2008
>
>
>    where each party acts on its own best interest, transport-based
>    solutions will be deployed by an edge site only when it recognizes
>    its own gain for doing so.  The routing system has no control over
>    edge site deployment of new solutions, but has its own technical  
> and
>    economical constraints.  Thus the routing system cannot solve  
> its own
>    scalability problem within a given time frame by counting on a
>    significant portion of edge sites to deploy the new solution.

 From the above paragraph sounds like, differently from transport  
level solution,
with the map-and-encap solution the benefits are significant from the  
beginning
of the deployment, which in my opinion is not true.

Both map-and-encap and transport solutions need to reach a "critical  
mass" before
providing any significant benefit. Of course the point where gains
start can be different for the two approaches.

[snip]

> 2.  Benefits of Separation via Map & Encap
>
>    Separating the transit core from the edge networks can provide the
>    following two major benefits:
>
>    1.  Protecting the core from edge growth and dynamics: a previous
>        study [eFIT] shows that removing edge-network prefixes from the
>        transit-core routing system can reduce the routing table  
> size and
>        routing churns by an order of magnitude.
>
>    2.  Improving routing infrastructure security: although separation
>        does not eliminate any specific security threat, it can help
>        raise the barrier against malicious attacks targeted at the
>        global routing infrastructure.

“Any problem in computer science can be solved
with another layer of indirection. But that usually will create  
another problem.”
—David Wheeler

My point is that even if separation can help in alleviating some kind  
of attacks,
it could open the door to new kinds of attacks.
We should be careful before stating that security is improved.

>  First, one can easily trace back
>        offensive packets despite souce address spoofing by end hosts,
>        because each encapsulated packet carries its ITR's IP address.
>        Second, ITRs allow end hosts to send packets through the  
> transit
>        core, but can disable any end host from addressing a packet to
>        any device inside the transit core.  Attackers can still use
>        compromised hosts within an end-site to DDoS the local border
>        routers, but such attacks only make a local impact and are
>
>
>
> Jen, et al.             Expires January 22, 2009                 
> [Page 5]
> Internet-Draft            Mapping and Multipath                July  
> 2008
>
>
>        relatively easy to deal with.  Attackers may also try to use
>        compromised hosts from multiple end-sites (e.g., a botnet) to
>        DDoS the routing infrastructure by flooding packets to some
>        remote end-sites.  However, given the transit core topology is
>        opaque to end users, attempting to DDoS any specific  
> component in
>        the transit core becomes more difficult.
>
>    A Map & Encap based solution can also be deployed incrementally  
> on an
>    AS-by-AS basis, bringing immediate benefit to first movers.  
> [[ref to
>    MARCH'08 APT incremental talk?]]

I remeber the talk and actually I was not convinced. But if you have  
made any progress
and you have a pointer, I am interested.

>    Furthermore, the Map & Encap approach allows new functions to latch
>    onto the mapping layer, providing architectural flexibility and
>    extensibility.  We give three examples below to show how the  
> mapping
>    layer can be used to address major problems in the Internet.
>
> 2.1.  Accommodate path selection and path diversity

We did some work on this subject:

http://inl.info.ucl.ac.be/publications/evaluating-benefits- 
locatoridentifier

[snip]
>
> 3.  Benefits of Transport Multipath Approach
>

[snip]

>    A more fundamental distinction between a transport multipath  
> solution
>    and SHIM6 is that the former utilizes multiple paths in parallel,
>    rather than using one at a time as the case in SHIM6.  Besides
>    potentially improved performance, the simultaneous use of multiple
>    paths easily tolerates the loss of any single path, hence it  
> becomes
>    less important to keep track the status of any individual paths.
>
The use of multiple path is resilient to single path failure. Yet,  
somewhere
you have to keep track of the individual paths. Otherwise you risk
to assume the existence of something that in reality is not available  
anymore (path).

>
>
> Jen, et al.             Expires January 22, 2009                 
> [Page 8]
> Internet-Draft            Mapping and Multipath                July  
> 2008
>
>
>    This last point makes it feasible for network providers to  
> aggregate
>    PA addresses.  The aggregated prefixes will no longer track the
>    status of individual subprefixes, hence suppress edge connectivity
>    dynamics from propagating to the core.  Instead, transport  
> protocols
>    will track the status of individual paths and make adjustment
>    accordingly.

Here I'm confused. In the previous paragraph you claim the contrary.

[snip]

>
> 4.  Elimination or Separation
>

[snip]

>    However, multipath routing at the transport layer does not directly
>    solve the scalability problem.  It simply allows for routing
>    scalability to be improved via another method: ELIMINATION of non-
>    aggregatable prefixes.  This method is in contrast to the  
> SEPARATION
>    method we propose.  Unless and until one can get majority, if not
>    all, of edge sites to act in harmony in adoping a new transport
>    multipath solution, hence to achieve the goal of (most) ELIMINATING
>    non-aggregatable prefixes from the transit core, otherwise it  
> cannot
>    be an effective solution.
>

I really do not understand that.

By SEPARATION I assume you mean loc/ID split. This, allows you
to get rid of IDs in the core network. Since IDs can be PI addresses,  
this
leads to ELIMINATION  of non-aggregatable prefixes.

So, can you clarify the difference?

[snip]

Cheers

Luigi Iannone

[email-masked]

---

From: Dan Jen <[email-masked]>
Date: Thu, 24 Jul 2008 18:58:53 -0700

Luigi,

Thanks for your comments.  Here is a reply.

> 
> From the above paragraph sounds like, differently from transport level
> solution, with the map-and-encap solution the benefits are significant
> from the beginning of the deployment, which in my opinion is not 
> true. 

Actually, a transit network can receive scalability benefits immediately
after deploying the new map&encap solution.  APT is one solution where
this is true.  An exerpt: 

"  APT islands configure their border routers as "tunnel
   routers" (TRs) so that their customers' data packets will be
   encapsulated and decapsulated as they enter and exit the AS.  An APT
   island can then remove all customer edge prefixes from their BGP
   routing tables. "

See www.cs.ucla.edu/~meisel/draft-apt-incremental-00.txt for full
details.

> 
> if separation can help in alleviating some kind of attacks, 

Yes, I agree we should be careful. 

> >    A Map & Encap based solution can be deployed incrementally on an
> >    [[ref to MARCH'08 APT incremental talk?]]
> > 
> 
> I remeber the talk and I was not convinced. If you made any progress 

Can you tell us specifically why you were not convinced?  We would love
your feedback.   
 
> > We give three examples below to show how the mapping
http://inl.info.ucl.ac.be/publications/evaluating-benefits-locatoridentifier

Great, thanks.  We'll reference your data in future work.  We are also
working on quantifying some of the benefits of map&encap.

> >    This last point makes it feasible for providers to aggregate
> >    status of individual subprefixes, suppressing edge connectivity
> >    dynamics from propagating to the core.  Transport protocols

Really?  This paragraph claims that PA prefixes are aggregatable by
network providers in the core, and once these edge prefixes are
aggregated, reachability status of these edges no longer result in
updates to the global routing table, leaving reachability tracking to
the transport layer.  I don't see where we claim the contrary.  Can you
show us?

> >    Multipath routing at the transport layer does not directly
> >    scalability to be improved via ELIMINATION of non-
> >    aggregatable prefixes.  This is in contrast to the SEPARATION
> >    multipath solution, hence achieving the goal of ELIMINATING
> >    non-aggregatable prefixes from the transit core, or it cannot
> to get rid of IDs in core network. Since IDs can be PI addresses, this

Ahh, we should probably reword this a bit.  Our point is that under the
map&encap approach, we remove the PI prefixes from the core, but they
still exist, as they are used by the edge sites.  Since they still
exist, we call it separation rather than elimination.  This is in
contrast to the transport scheme, where edge sites actually stop using
PI prefixes in exchange for PA prefixes from their providers.  Thus the
PI prefix is eliminated from use.

Sorry about the confusion.  We'll try to clear that up in our next
revision.

Dan Jen

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 25 Jul 2008 09:52:37 +0200

Hi Dan,

  thanks for the reply,

> See www.cs.ucla.edu/~meisel/draft-apt-incremental-00.txt for full

Thanks for the pointer.

>>>   Transport protocols

Here you say transport protocols will track status of individual  
paths....
While previously you state...

>>> Besides

.. and this statement sounds like you do not need to keep track of  
individual paths.

> PI prefix is eliminated from use.

Much more clearer in this way, thanks.

Cheers

Luigi

Luigi Iannone

---

From: Dan Jen <[email-masked]>
Date: Fri, 25 Jul 2008 01:15:44 -0700

> .. and this statement sounds like you do not need to keep track of

Oh, okay, another problem with the writing.  What we meant to say was
that it is less important for TRANSIT NETWORKS to keep track of the
status of any individual paths, since the transport layer can use
multiple paths.  We'll fix it up in later editions. Thanks for calling
us out on it.

We'd still be interested in hearing why you were unconvinced with the
talk Lixia gave about incremental deployment of map&encap schemes(APT in
particular).  

Thanks again,

Dan Jen