http://www.cidr-report.org/#General_Status
+2500 last night. It seems that the origin of this disease is in France.
... quoting myself:
Valdis.Kletnieks@vt.edu schrieb:
It's not, people are just lazy and since "nobody owns the internet
man", or maybe "it's all a bunch of tubes" there's nobody to force people
to be good actors. Perhaps it's time to bring back the old /19
filters that were started by sprint & such.
Just to make it clear: AS4151 was 9 month ago. Now we see history again
with new actors. (I guess the actual increase was done by various ASN of
RENATER).
I'm curious how you reach the conclusion that RENATER has contributed
to many of the prefixes over the last week. They do seem to have
announced a bunch of prefixes that could be aggregated, but look at
the following report:
http://www.cidr-report.org/as-prefixes.txt
There seem to be a whole load of ASNs that have deaggregated. AS5416,
AS5639, AS6140, AS9121, AS13049, AS16130, AS17849, AS18049 (that's as
far as I got before getting bored). Some of these are advertising the
covering prefix too, so they're certainly aware of how to aggregate.
Rob
Rob Evans schrieb:
Just to make it clear: AS4151 was 9 month ago. Now we see history
again with new actors. (I guess the actual increase was done by
various ASN of RENATER).I'm curious how you reach the conclusion that RENATER has contributed
to many of the prefixes over the last week.
Actually I thought this morning I've read RENATER several times at
http://www.cidr-report.org/ - but I might be wrong (it's 34 degrees in
Switzerland, just too hot to make assumptions).
However the prefixes are gone again:
http://www.cidr-report.org/#General_Status
and we see 189980 in our LG as before.
F.
Sometimes this is done intentionally -- the long-prefix (covered) prefixes might be TE routes designed to draw traffic to particular sinks through specific external providers.
People have been known to stamp NO_EXPORT on those and get some measure of TE without polluting the global table, but if the AS whose exit you're trying to influence isn't adjacent that doesn't work.
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
Under that proposal you could stamp an AS_PATHLIMIT=2 or AS_PATHLIMIT=3 on TE routes and have them automatically dropped by routers when the AS_PATH length exceeded 2 or 3. For some people this would work (for others, for whom 90% of the Internet is less than 2 or 3 hops away it wouldn't do much).
It would help immensely with getting that document published if people could read that draft, and let me know if it looks like something they would implement if it was implemented. Private mail would be great.
Joe
Uh, "something they would deploy if it was implemented". Fridays. Words.
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/msg00394.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
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,