One thing I've heard several times now is "yes, I share an unrestricted IGP with some set of customers and so my net could be victimized by this trash, but we filter on egress to our BGP peers so we could not be a conduit." This is new and useful information for me -- it may mean that only a multinational network could get one of these prefixes into enough end systems to matter, and MOST (hint, hint, nudge, nudge) multinationals are doing static ingress. This problem may be solvable with small deltas in only a few bad spots. (You know who you are, we'll talk in Alburqurque.) The other thing I've learned from this escapade is that when folks think they can talk on NANOG without anyone flaming them by name afterward, some folks talk who normally don't. This may say something bad about the way we treat each other -- not everybody whose participation I value has thick enough skin to put up with my manners, much less those of some folks here I could name. ------- Forwarded Messages I am not replying to provide any sage input. I have none. I'm pretty new to BGP in general. I'm replying mainly to say thanks for directing a discussion that, to me, is fascinating, and from which I hope to learn a great deal. [ well, i'm not a real routing guy but i'm glad to help illuminate a topic. --vix ] I'm one of those newbies who is having to come up to speed in a hurry. I began contracting with XYZZY on a somewhat unrelated network upgrade project. Basically, for the time being, I've inherited the future of the network. I've done lots of IP networking, just not on this high a level, until now. I'm lurking. It's a tough crowd out there on NANOG. :-) My goal is to make/keep XYZZY a responsible networking outfit while learning enough to keep myself employed. :-) I won't take anymore of your time. I have included below a belated response to your earlier query.
My conclusions so are are: (1) most people know the importance of and the procedure for strict controls over end-system routes they inject, even if not everybody does it;
I think so. We announce static routes only for those CIDR blocks allocated to us.
(2) degree of enforcement of (1) is probably going to be a term of most peering agreements by this time next year;
OK, I promise to bring it up when we next agree to a peering arrangement
(3) enough folks are enough opposed to the RADB that intermediate-system route control probably won't come that way;
I'm a newbie. I'm still working on understanding all the inner workings of RADB. I know what it does, but not how it works. [ so far it has run aground on the old prescriptive/descriptive debate, and some significant large providers have not joined the party. needless to say, it won't solve THIS problem until EVERYBODY uses it. --vix ] I believe the following three responses re true of our network as well
Subquestion 1: if the spammer is your customer.
While the route would propogate to my ibgp network in some cases, it would not be announced to the internet. I would be spammed, but my peers would not hear the announcements. [my net] filters its announcements to peers at the AS and IP address level. Only known-valid addresses of our customers are propogated to our peers.
subquestion 2: if the spammer is a customer of one of your BGP peers.
I would accept it in all cases.
subquestion 3: if the spamemr is a customer of a distant BGP-connected AS.
I would accept it it all cases. ------- Message 2 1. Currently, we filter what is advertised to our upstream providers so it would not get advertised to the Internet at large, but it would be propagated through our IBGP mesh and to our BGP peers/customers. So, I guess this is a "mostly" no. [ this is sometimes called "unintended transit" and it's a large enough problem that it's probably worth solving for operational reasons even apart from the security issues. you should filter on egress to your BGP neighbors no matter what. you should filter on ingress where possible, and use static ingress with any single homed customer. --vix ] 2. We do not filter inbound announcements from BGPpeers/customers/upstreams, so yes. We do plan to generate filters from IRR for the smaller ones in the near future (once they keep their information up to date), but it seems infeasible to do so for upstreams such as MCI, UUNet, etc. given the size of the resulting filters. [ yes, i worry about the large ones too, but way down below i'll waffle. using the IRR wherever possible makes sense unless you have high BGP wizardry on your staff in which case you'd want all the knobs to yourself. --vix ] 3. Yes, and I don't see a practical way to do it given current technology. When you talk about fixing the problems by changing BGP, I am curious what design you would propose to fix this. As I see it, the only practical way to validate advertised routes automatically is using digital signatures of address delegations, and validating the chain of delegations back to a root (configurable in the router). [ yes, that's my thinking, and it's also what i've heard from the security folks. --vix ] One problem with this is that the bandwidth required to exchange routing information will increase dramatically, as well as the memory required to store the routing information (since a peer will have to be able to pass on the certificate of a received route object). Do you see another solution to the problem? [ here's the promised waffle. routers have been getting bigger, and despite the lamentations of the "i want a routing table i can count on one hand" crowd, they are going to keep getting bigger. if IOS were still scalable, cisco would be selling MasPar-like RP's with a gigabyte of ram (expandable). then we have bgp itself, which is a delta protocol based on reliable TCP for its statekeeping, so other than at startup or during heavy route flap, the bandwidth consumed by BGP is microscopic compared to, say, DNS or SMTP. (note, i'm not comparing it to HTTP, next to which anything is microscopic.) finally, security engineering is all about tradeoffs. some balance will be found between the size of the keys and signatures, the complexity of the algorythms, and the economic realities of the market. i see a big overlap. --vix ] ------- Message 3 subquestion 1: if the spammer is your customer. They couldn't inject the route unless they registered with us first and that process should disallow it if it's unregistered. Using the IP address wouldn't get caught yet, we are waiting for Cengiz to add ingress filtering to RtConfig so we can build the filters out of the policy info stored at RADB. subquestion 2: if the spammer is a customer of one of your BGP peers. We only check that the route is tagged with an AS path that we are expecting to see from the peer so if they get it past the peer then we will believe it. subquestion 3: if the spamemr is a customer of a distant BGP-connected AS. We lose here since we believe what we get from our provider. ------- Message 4
routing core allow it? subquestion 1: if the spammer is your customer.
no. customers are considered dangerous when armed with BGP. they are AS and prefix fitlered.
subquestion 2: if the spammer is a customer of one of your BGP peers.
Only if they're ASpath is valid by RA registries. We are not [yet! in my copious spare time we will be!] prefix filtering on peers.
subquestion 3: if the spamemr is a customer of a distant BGP-connected AS.
n/a, if I read the question right. ------- Message 5
routing core allow it?
Yup, mostly. :(
subquestion 1: if the spammer is your customer.
"No", but then we don't have any BGP customers either. We're in the process of creating a BGP service for those customers that want it. I'll be collecting this thread from NANOG as part of the argument to make sure we "do it right" and get the resources to make sure the answer to this question will remain "no". Of course, if the customer was multihomed we might still learn the route via the method in subquestion 3 because it would be a false assumption to apply the same filters to what we learn via their other upstreams as to what they announce to us. (Hmm. but we could make it a true assumption by writing the contract carefully... "tell us all routes you expect to originate in your AS even if you don't plan to announce them to us because we will filter you on our other borders too" ;) [ this is pretty common. no potential customer is going to choose a different provider based on this restriction -- or if they do, you're better off. --vix ]
subquestion 2: if the spammer is a customer of one of your BGP peers.
"yes, unless RFC1918 addresses". I'm hoping to overbudget for the above so that we can change this to a "no" as well. That would probably rely on IRR data, which is also open to fakery, but the filter reloads wouldn't be realtime so it should still block 5 minute announcements.
subquestion 3: if the spamemr is a customer of a distant BGP-connected AS.
"yes, unless RFC1918 addresses". I notice that some of our "big" transit providers trust whatever some of the other "big" backbone carriers feed to them. It's interesting to see networks belonging to peering LANs at various IXPs show up from time to time. I'm not sure that this can be easily fixed. Maybe the solution is similar to the IP filtering one, in that it only works when everyone filters at all the 'little' BGP sessions so that we can then 'trust' what our backbones feed us.
i've sent reply-to to myself. i will summarize responses back to the list.
Thanks for making me think. Do you realise that you accidentally posted something of operational content and interest to NANOG ? [ i didn't mean to. it was the only audience i could think of for my question. i don't think i'm part of a trend of any kind, though. --vix ] ------- Message 6
up before now. I guess spamming was the first natural application for it.
If we required all mail relayers to have valid in-addr.arpa DNS, this would be a non-issue. Unfortunately, when I used sendmail rules to enforce that, too many valid (but clueless) sites were prevented from passing mail into FDT, and I had to back down. [ the in-addr.arpa tree was never really populated at all the way it is now until uunet.uu.net, then the net's largest ftp server in the days before the web or even gopher, started requiring forward/reverse matches for all inbound anonftp connections. i think the progress we collectively made then is about all we can expect for the remainder of the experiment. --vix ]
(5) to the extent that abusers of unallocated space are spammers, the MAPS RBL is the only short term hope i have of controlling this.
How impractical would it be to put all unallocated space in the RBL?? [ i did that today, but it's somewhat hopeless since i'm advertising /8's and the address thieves only need to offer something longer. it's time to hack on gated some and get it to automatically warn me when a more-specific comes in and occludes a particularly-tagged static. --vix ] It's hard to believe spam providers have stooped to this level...but assuming they have, I suppose the next step would be temporary theft of address space, though that would probably generate a lot more heat for them. The run of the mill small ISP or business on the net might not even notice a 5 minute interruption of routing, and would certainly lack the ability to track down those responsible. [ indeed. while this has been done from time to time it was always with the intent of doing harm to the network's owner, not just to steal their identity for various purposes. next april 1 we should see some demon- strations of this concept in hopefully friendly ways. --vix ] ------- Message 7 ***SEE the end re 7777:x communities for your BGP announcments***
routing core allow it?
In to us from the world? YES Out from us? We ingress filter most but not quite all customer traffic, so NO
subquestion 1: if the spammer is your customer.
regular customer, NO (see above), BGP speaking customer (i provide transit for) YES - they are FEW and trusted. I may be using terms differently... I am using "BGP peer" as a peering point NO TRANSIT either way connection.
subquestion 2: if the spammer is a customer of one of your BGP peers.
I'd use his routes internally, but would not propagate them.
subquestion 3: if the spamemr is a customer of a distant BGP-connected AS.
We would pass it all like any other traffic. BUT, I was delighted to see you have now decided to blackhole them but have a problem perhaps you can help with! We are subscribed to your BGP blackhole system but are not currently using it internally because we had objections from downstream ISPs that hate spam but also are leary of censorship. I need to work out a scheme where I can selectively apply the blackholing routes for the rest of my customers, probably right into my 2501 at each of their sites! [ i think you should just use the DNS access method in that case. --vix ] However I would LOVE to immediately use the ones you send for unassigned blocks - all the /8s you listed in other email. PLEASE decide on a community or whatever to tag them with so I and others can selectively use this subset of the blackhole system, and skip the others for now. And, while you are at it, perhaps there are some other subtle subdivisions that also could benefit from having their own community. I assume the most logical community conventions would be 7777:x and x would be on a published list of special tags. Some thought might be made to more complex situations where a route might have multiple communities and could be tested for appropriately if it were known that that possibility existed. [ the gated version i'm using doesn't support communities at all. when it does, i will do what you said. --vix ] Also on your /8 announcements, won't the tighter masks of spammer 5 minute announcements override your /8 or am I missing something? [ yes. but i felt that the symbolic gesture was better than nothing. actually i think the IANA ought to be advertising real routes for these, blackholed of course, just to keep somebody else from camping on "by accident" as happens every year or two. --vix ] ------- End of Forwarded Messages