Deaggregation Disease

On 21-Jul-2006, at 11:20, Saku Ytti wrote:

> On (2006-07-21 10:48 -0400), Joe Abley wrote:
>
>> As it happens, Tony Li, Rex Fernando and I wrote up
a proposal for a
>> new attribute which might help in some of these
situations. (It's a
>> crude mechanism, but not as crude as NO_EXPORT).
>>
>>    http://www.ietf.org/internet-drafts/draft-ietf-idr-as-
>> pathlimit-02.txt
>
>  I'm sure I'm not first one to to think about 'TTL'
to AS hops
> (http://www.merit.edu/mail.archives/nanog/2002-10/m
sg00394.html),
> of course different reason at that time . Other
thing I was thinking
> about was ability to have include/exclude AS#'s
community/attribute.

That seems to me like another perfectly valid approach, and
one that  
already exists to some extent (e.g. by pre-poisoning AS_PATH
 
attributes with AS numbers of remote networks that you
don't want to  
accept particular routes). I'm told that IDRP has inclusion
and  
exclusion lists which provide more exhaustive implementation
of this  
kind of idea, too.

However, for some applications those mechanisms rely on
knowing the  
topology one or more AS hops away from your network;
AS_PATHLIMIT  
doesn't. To my eye the two approaches seem complementary.

[To be clear, incidentally, Tomy, Rex and I made no claim to
be the  
original authors of the idea we were documenting in this
draft:

8.  Acknowledgements

    The editors would like to acknowledge that they are not
the original
    initiators of this concept.  Over the years, many
similar proposals
    have come our way, and we had hoped that self-discipline
would cause
    this type of mechanism to be unnecessary.  We were
overly  
optimistic.

    The names of those who originally proposed this are now
lost to the
    mists of time.  This should rightfully be their
document.  We would
    like to thank them for the opportunity to steward their
concept to
    fruition.]


Joe

On (2006-07-21 11:38 -0400), Joe Abley wrote:
 
> That seems to me like another perfectly valid approach,
and one that  
> already exists to some extent (e.g. by pre-poisoning
AS_PATH  
> attributes with AS numbers of remote networks that you
don't want to  
> accept particular routes). I'm told that IDRP has
inclusion and  
> exclusion lists which provide more exhaustive
implementation of this  
> kind of idea, too.

Oh, cool idea, indeed 'as exclude' mechanism is there, but
I'm sure I'd be
frowned upon advertising such routes today. 'as include'
otoh. is not there.

> However, for some applications those mechanisms rely on
knowing the  
> topology one or more AS hops away from your network;
AS_PATHLIMIT  
> doesn't. To my eye the two approaches seem
complementary.

Absolutely complementary. The 'original' problem I was
thinking, really
needed both, as point was to find how 'deep' in Internet
your
DoS sources are, then as you've indentified the depth, you
have
smaller subset of AS#'s that you could iterate with
include/exclude
to pinpoint source of certain traffic, even if they were
spoofing.
But that idea has several problems that might make it
unfeasible,
nevertheless the traffic engineering applications remain. 

> [To be clear, incidentally, Tomy, Rex and I made no
claim to be the  
> original authors of the idea we were documenting in
this draft:

ACK, I did notice that, I'm sure most people have thought
about it at one
point or another in their networking career . 

I hope it'll be implemented. Thanks,
-- 
  ++ytti