Valdis.Kletnieks@vt.edu schrieb:
On Fri, 21 Jul 2006 09:51:33 +0200, Fredy Kuenzler said:
Prefixes Change ASnum AS Description 3263 0->3263 AS4151 USDA-1 - USDA so I wonder what's wrong with them.
I'm not sure which is more weird - a jump of over 3K routes, or the fact that the starting point is zero....
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 wonder why aggregating is that difficult. F.
On Fri, Jul 21, 2006 at 02:42:04PM +0200, Fredy Kuenzler wrote:
Valdis.Kletnieks@vt.edu schrieb:
On Fri, 21 Jul 2006 09:51:33 +0200, Fredy Kuenzler said:
Prefixes Change ASnum AS Description 3263 0->3263 AS4151 USDA-1 - USDA so I wonder what's wrong with them.
I'm not sure which is more weird - a jump of over 3K routes, or the fact that the starting point is zero....
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 wonder why aggregating is that difficult.
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. -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
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.
On 21-Jul-2006, at 09:17, Rob Evans wrote:
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.
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
On 21-Jul-2006, at 10:48, Joe Abley wrote:
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.
Uh, "something they would deploy if it was implemented". Fridays. Words.
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/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. -- ++ytti
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/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
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
participants (5)
-
Fredy Kuenzler -
Jared Mauch -
Joe Abley -
Rob Evans -
Saku Ytti