December 2007 - NANOG - lists.nanog.org

Re: looking for help for the statistics data on spoofing attack events on Internet
by Paul Ferguson 26 Dec '07

26 Dec '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- "yangyang. wang" <wyystar(a)gmail.com> wrote: >We have already found CAIDA's backscatter, MIT's spoofer project. Spoofer >project focuses on how much space in the Internet could be spoofable. It >is very helpful for our experiment. But we also want to know how often the >spoofing events(such spoofing IP attacks, spoofing route update) occurs, >or the degree of their activity in real world. Monitoring the Internet >widely is very difficult,so I hope to get some useful infomation by >surveying the related statistical data and report from organization. >currently, this way has no effective result. > As one of the co-authors to RFC2827/BCP38, I certainly understand your concerns. Which is why I encourage anyone who is interested to put their efforts into SAVA/SAVI work currently underway in the IETF. [SAVA: Source Address Validation Architecture] I personally think this is important work, but probably for different reasons than most people. ;-) - - ferg [1] http://www3.ietf.org/proceedings/07dec/minutes/savi.txt [2] https://datatracker.ietf.org/meeting/70/materials.html -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHcdDjq1pz9mNUZTMRArXRAKDpcxR12OA08jJxzpllaHBo46nVfwCdGTSI zhA1liWpRtcvZ+yupsb+AGc= =Gogs -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

looking for help for the statistics data on spoofing attack events on Internet
by yangyang. wang 26 Dec '07

26 Dec '07

We are conducting an experiment to evaluate IP source address spoofing attacks on Internet and want to collect some statistics data or report about it Which organization or research group could support some statistics data, report or hints on the spoofed IP source address attack events, DNS spoofing events, router forged update events on the whole Internet or regional network for research analysis? Best wishes!

2 2

Re: v6 subnet size for DSL & leased line customers
by Leigh Porter 26 Dec '07

26 Dec '07

LOL.. Yeah, I am on call today - thankfully nothing happened. Anyway, I hope you had a peaceful day! -- Leigh Crawford, Scott wrote: > Well, I guess he told you. :) > > Merry Christmas > Scotte > > -----Original Message----- > From: "Jeroen Massar" <jeroen(a)unfix.org> > To: "Leigh Porter" <leigh.porter(a)ukbroadband.com> > Cc: nanog(a)merit.edu > Sent: 07/12/25 11:48 AM > Subject: Re: v6 subnet size for DSL & leased line customers > > Leigh Porter wrote: > >> Wow, is this what you folks do at Christmas ? >> > > Clearly you yourself are affectionate about this thing called Christmas, > if you are so affectionate about it, then why are you making silly > comments which do not contribute at all to the topic at hand? > Must be very boring that Christmas of yours. > > > On a more operational topic: even during Christmas (that Coca Cola > induced commercialism party that gets attributed to some religion), > people are using the Internet, and stuff breaks on the Internet, as such > there will always be people who have to work on days like this. > > Greets, > Jeroen >

1 0

Re: Using RIR info to determine geographic location...
by Hank Nussbacher 24 Dec '07

24 Dec '07

At 08:44 PM 19-12-07 -0500, Drew Weaver wrote: I too would be interested to know how others feel about the various geo-location services available to speed things along. Three that come to mind are Akamai, Neustar/Ultradns and the "roll your own" Cisco GSS 4492R. How do they stack up? How good are the various Maxmind files? Thanks, Hank > Is this becoming a more common or less common practice as we > slide ourselves into the last week of 2007? The reason I am wondering is > we have noticed some 'issues' recently where correct info in the RIR > causes very inefficient and sometimes annoying interaction with some of > the world's largest online applications (such as Google) lets say for > example that a customer in India purchases dedicated server or > Co-Location hosting at a HSP in the United States [very common]. So the > RIR shows that the customer is in India, so when the customer interacts > with any google applications google automatically directs this traffic to > google.in (or the India version of whichever app).... > > More unfortunate than this fact, is the fact that it appears that > services and application providers such as google are caching RIR data > for an "unknown" amount of time. Which means that if a service provider > SWIPs an allocation to a customer (lets use the same example... again in > India) (say a /24) to a user, and then that user subsequently returns > that allocation and the service provider re-allocates in smaller blocks > to different customers in say /29, /28.. et cetera... the problems > related to this issue are compounded (30 customers being affected, > instead of one...) by this caching... > > Obviously providing RIR information is the responsibility of > service providers (it is even ARIN's policy) has anyone else in the > community ran into issues such as this and found solutions or workarounds? > >Happy holidays to all on NANOG :D > >Thanks, >-Drew

6 7

Re: v6 subnet size for DSL & leased line customers
by Brandon Butterworth 24 Dec '07

24 Dec '07

> I thought we were all trying to discourage NAT in IPv6. Clearly, NAT > solves the problem ... while introducing 1000 new ones. :-/ Clearly some have been trying to discourage NAT in IPv6 ensuring there'll be a 1000 problems if anyone tries. > I mean, yeah, it'd be great if we could mandate /48 ... but I just can't > see it as likely to happen. If people are supposed to have a /48 then the allocation rules should say that's what they will get. It may be xmas but it's not wise to rely on the benevolence of ISPs brandon

1 0

Re: v6 subnet size for DSL & leased line customers
by Daniel Hagerty 23 Dec '07

23 Dec '07

Ross Vandegrift <ross(a)kallisti.us> writes: > Ahhh, thanks - that is the only thing I have ever seen that gives any > reason for the /64 prefix. Sadly, the document contains no > compelling technical reasons for it - looks like it's done just so > things are easy when generating interface IDs from ethernet addresses. One good guess for the rationale is to preserve the possibility of splitting the host and network identifier namespaces, like XNS and some others do. Should it be deemed the way forward, the current policy makes it slightly more of a possibility to decouple them after the fact.

1 0

Re: v6 subnet size for DSL & leased line customers
by Scott Weeks 22 Dec '07

22 Dec '07

--- nanog(a)85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: From: Mark Smith <nanog(a)85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> I'd also be interested to know what you'd *want* if you were asked how you'd like to structure IPv6 addressing, if you didn't have any history of having to be conservative with IPv4 addressing. IOW, imagine IPv4 didn't exist, and therefore your thinking about IPv6 isn't influenced by your history with IPv4. -------------------------------------------------------------------------- If I wasn't worried about routing table size (you said "if you didn't have any history...imagine IPv4 didn't exist") I wouldn't give household and SOHO networks billions of addresses. scott

5 6

RE: IPv4 BGP Table Reduction Analysis - Prefixes Filter by RIRs Minimum Allocations Boundaries
by Jon Lewis 21 Dec '07

21 Dec '07

On Sat, 22 Dec 2007, Greenhalgh, John wrote: > throughout the satellite industry. So if we didn't deaggregate RIR > blocks, we'd have at least one RIR allocation per discontiguous network > and so would be contributing the same number of prefixes to the global > table. True, but I've seen enough networks that deaggregate because they just don't know any better. If we were to make an exception for every network that had reasonable cause to deaggregate, that probably wouldn't scale. Relaxing the filters by a few bits might work. I'll have to run a few tests to see what happens to the route savings if I filter on APINC RIR+1 bit, RIR+2 bits, etc. The worst abusers are the ones to whom their RIR allocations are "collections of class C's" so it may be that there's enough savings at RIR+2 to make that worth using as a compromise. >> I just filtered you (before >> seeing your message) as we're now filtering APNIC on "RIR Minimums". > > The timing of my mail was pure coincidence. I am assuming that unless > our immediate Tier 1 upstreams start filtering, we won't see any > significant degredation as people start implementing these filters. We don't normally point default anywhere (other than null0), but I knew I'd have to before adding the route filter...so you're still reachable as long as the networks between us aren't filtering. For anyone interested, the filter I'm using is the APNIC section of the ISP-Ingress-In-Strict filter posted to nanog a few months ago, plus around 10 additional deny rules that we'd normally have via an input distribute-list...since IOS doesn't seem to allow both an input distribute-list and input prefix-list on the same BGP peer. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

1 0

RE: IPv4 BGP Table Reduction Analysis - Prefixes Filter by RIRs Minimum Allocations Boundaries
by Jon Lewis 21 Dec '07

21 Dec '07

On Fri, 21 Dec 2007, Greenhalgh, John wrote: > For example, we have a /19 allocated from APNIC and announce this from > our Hong Kong network. Within that /19 we have assigned a /21 to our > Australia site which is discontiguous from Hong Kong. This /21 is > announced upstream to two ASes, and being in the 210/7 block would be > filtered. > > We have several discontiguous networks around the world and when these > sites started it could not be justified to use a min RIR allocation for > the site. That's unfortunate, but your problem doesn't scale. If every network got an RIR allocation, and then subnetted it among several discontiguous POPs and polluted the global route table with those subnets, the routing table would be even worse than what we have today. How much are you willing to pay every other network to carry your deaggregates? What makes your deaggregates special and more worthy of a free ride than any other deaggregating network? With the holiday and new years fast approaching, and our upgrade kits not quite fully assembled (much less tested), I just filtered you (before seeing your message) as we're now filtering APNIC on "RIR Minimums". We were just 2399 routes away from our Sup2s doing bad things. Now we're 20306 routes away...which leaves a much more comfortable margin of safety. Looking forward to seeing your routes early next year...after we've upgraded. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

1 0

Re: v6 subnet size for DSL & leased line customers
by Lou Katz 21 Dec '07

21 Dec '07

I am having trouble understanding why I cannot get an allocation of any size, only an assignment. Unless I didn't read the documentation correctly, there seems to be no way in hell that I can get PI v6 space of any size, which of course leads me to be disinterested in v6. -- -=[L]=- Water coloring -- it's better than it looks.

2 1