SSL/x.509 certificate infrastructure

After working with x.509 (SSL) certificates a bit, I think some changes in the infrastructure are needed. It's become obvious to me that the major CAs aren't entirely secure, there've been too many compromises of them. In addition they make it too costly to truly use certificates effectively.

For client certificates, StartSSL has the right idea: charging based on the cost of the verification, not per certificate. They'll give you a free SSL client certificate for your e-mail address, because it's all automated and they don't really incur any significant costs above normal operation doing it. If you want a certificate where actual identity's verified by checking passport etc., you pay for the verification when it's done. After that you don't pay anything for getting certificates issued unless/until issuing one requires a new verification. This needs to be the norm for client certificates. In addition we need ways for an organization to issue certificates for it's members. Your employer, for instance, is a much better source of a client certificate tied to your position as an employee because they know for certain who their employees are while a CA doesn't. Ditto my bank: if they issue me a client certificate saying I have such-and-such an account with them, that certificate should be more acceptable to financial sites than a CA-issued one because my bank knows for certain that I've got that account with them and they've followed the required-by-law checks on my identity before giving me that account. And we need to move certificate generation/issuing into mail clients as well as browsers. It's not that hard since most mail clients these days use a browser component to display HTML e-mail and fetch remote content. That component can be used to go through the same process as a browser would. The critical thing is that private key generation is done on the client side and that private key can never exist on the server at any point.

Server certificates are where the real costs come in. It's prohibitively expensive to get server certificates, that's one of the reasons many places haven't gone to strong SSL. It's also difficult to determine from the certificate whether the server really belongs to the organization, because the CA issuing the certificates doesn't know which servers really belong to the organization. I'd much rather see CAs verifying the identity of the organization and giving out a signing certificate that let the organization issue it's own server certificates, with that signing certificate restricted so only certificates claiming the servers belong to that organization are valid. Then companies could issue certificates without worrying about how much it was going to cost. It'd also facilitate issuing client certificates for employees and system-to-system communication. It's not like actually issuing certificates is hard, you can set up Web pages to do it automatically without much trouble and the database to hold all the needed information is fairly trivial if you only need to handle your organization instead of every organization in the world the way CAs have to. Yes, most organizations won't employ the high-level security measures the CAs do to protect the signing keys. OTOH, each organization would be a much less lucrative target because a compromise would only affect one organization's certificates. Because of the way most organizations operate, it'd actually be harder to get at the signing certificates because most of the time they could be on a USB drive in the sysadmin's desk drawer and while physical access might be easy it requires the attacker to be physically at that location and most of them won't be on the same continent as their target.

The above would also make it easier to validate Web sites from the user's end. When I set up access to my bank's Web site, for instance, my browser would ask me to verify the organization issuing certificate. If I said it was OK, the browser would then tie that certificate to a human-readable name for the organization and tie the site I'd visited to that certificate. When I visit a site again, if the organization certificate matches what I have on file the browser lets me in. If the site isn't tied to an organization certificate, it'd prompt me to check the one the site presented and tell it what identity I wanted it tied to. If it was another of my bank's sites (or servers), I'd just tell it "This site belongs to my bank." and it'd make the connection. If the site and the organization certificate didn't match (eg. I thought I was visiting my bank's site but it's not using my bank's organization certificate) I can tell it "No match." and it'd block access. And if I had a match on file but it didn't match what the server was presenting, I'd get a similar prompt but with a stronger warning so I can correct an error if I really need to (eg. the bank's changed things around and I need to change my stuff to match) but it's really likely something malicious is going on and I need to be really sure before I accept it.

All of this would destroy the current business model for certificate authorities, their revenue comes from issuing individual certificates and these changes would mean CAs wouldn't be issuing more than a single certificate per organization instead of dozens to thousands. But there are other opportunities. PGP introduced the idea of "network of trust", where no single signature identified a key as truly belonging to a given individual and you evaluated how many signatures it had and how trustworthy each signature was when making the decision whether the key belonged to who it claimed to or not. The same thing could be done with certificates. I go and get a client certificate from StartSSL. Then when my employer wants to issue me a client certificate I can at the same time submit my own certificate and have my employer sign that as well. When I open a bank account, I can have my bank sign my client certificate as well as issuing me a bank one, leaving my client certificate with 3 signatures on it. Now, suppose my employer's compromised and their signing keys are stolen. My company-issued certificate's invalid, obviously, but my own certificate's still good because StartSSL's and my bank's signatures are still trusted. Same with StartSSL, if they're compromised my own client certificate's still OK because I've got 2 other signatures on it from uncompromised entities. As long as I have at least one uncompromised signature, I can avoid catastrophic failure. This applies to organization and server certificates too, and CAs could replace their revenue stream with one based on cross-certifying certificates so that single compromises wouldn't be fatal to a large number of certificates.

Merchant charges

My American Express card number got "stolen" and used for a fraudulent transaction this morning (caught by fraud detection and declined after I was contacted). Last month it was my Visa debit card. What annoys me is that this doesn't have to be possible. Right now it's possible because our system expects me to give the merchant my account number and have them initiate a charge from my account. But why does it have to work that way?

Suppose instead it worked thusly:

• The merchant gives me a merchant account number, transaction code and amount.
• If I'm making a purchase on-line, I go to my bank/issuer's Web site and enter an order to send a payment for the amount in question to the merchant's account, referencing the transaction code.
• If I'm making a purchase in the store, I hit my bank/issuer's app on my cel phone and do the same thing.
• If they don't have an app, I use the phone's browser to go to their mobile Web site and do the same.
• If I don't have data/Web access from my phone, I call an automated phone line and do the same (phone number verified by the automated billing info on the call).
• The bank/issuer sends the payment to the merchant.
• The merchant verifies the payment was received, and gives me my merchandise.

Now it's all but impossible for a fraudster to use my card. Merchants don't need to know my card number, so there's nothing stored on their systems for anyone to steal. My bank/issuer site login information's stored on my systems, they're under my control so it's a lot easier to take steps to prevent compromise (and if they're compromised they were under my control so it's a lot easier from a legal standpoint to justify saying that I'm responsible for the problem, and I can change passwords in just one place so it's easier to fix any compromise). It doesn't even require any infrastructure, banks and credit-card companies already have the networks in place to do electronic funds transfer (it's how they already handle the daily settlement with merchants and how they handle charging your card). So why do we accept fraud and the attendant problems when there's an alternative available?

Of course, there's always the case where you don't have a phone or any other way of initiating a transaction. But we have physical cards, and identification. Standard swiped transactions can continue to work, although they'd be considered a higher-risk transaction. Just go back to where we were when I was starting out in the world: when you present a card the first thing the merchant asks is "Photo ID please.". That'll cut down on card-present fraud, it's harder to fake two forms of ID and the fraudster has to balance the cost of a good forged driver's license against the amount he can purchase without tripping red flags. And we're reaching the point where even kids have cel phones with data plans. That adds another layer: someone who normally does bank-initiated payments suddenly doing a card-present swipe is abnormal activity and a big red flag saying "Potential fraud! Contact the cardholder to verify.". That adds another hurdle for the fraudsters: they don't just have to fake the card and photo ID, they have to have a card that's regularly used for swiped transactions. Merchants don't have to store card information for swiped transactions, so it limits the fraudsters to skimmers or compromising merchant point-of-sale systems. In the process it also gives me, the account holder, the option of removing myself from any risk of compromise by getting a suitable cel-phone and avoiding swiped transactions entirely. I can still leave myself open to fraud, but it's my choice and I get to balance the cost vs. the risk instead of depending entirely on merchant security.

So why are we still open to card fraud?

Sony PSN compromise

We've all seen the news about Sony's PlayStation Network being compromised. It's bad enough the bad guys got personal information. It's worse that they got credit-card numbers. But it's downright unbelievable that they got passwords!

OK, first off: users are partly to blame. You shouldn't be sharing passwords between services. Whatever password you used for PSN shouldn't be used elsewhere.

But that doesn't excuse Sony. The passwords should never have been stored on the servers. Unix has handled that for years. It doesn't store your password, it stores a one-way cryptographic hash of your password. Remember that it doesn't need to know your password, it only needs to confirm that you know your password. So instead of storing your password it runs it through a cryptographic hash algorithm and stores the result. When you enter your password, it runs what you entered through the same algorithm and compares the result to the stored value. If you entered the right password, the two will match. If they don't, you didn't enter the right password. If you chose a strong algorithm it won't be feasible to take the stored hash value and reverse the process to get the original password, and there's no reason not to choose a strong (SHA-1 or better) algorithm since there's plenty of easy-to-use cryptography libraries out there (many of the best don't even cost money).

And credit-card numbers? In this day and age we should be able to do better verification of credit cards. Check ID for in-store purchases, for instance. But most fraud is on-line, you say? We can still do better. Requiring the CVV2 for all non-recurring purchases, for instance. Or linking your cel phone number to your credit card and using text messages to confirm the purchase. When a non-CVV2 charge is attempted, you get a text from the card issuer with details. You then have to text a charge ID code plus an authorization code (CVV2 or other set value) back to confirm the charge. No confirmation = charge declined. Now to make a fraudulent charge the bad guys not only need to get your card number, they need to clone your cel phone which means they need to know your cel phone number, SIM serial number and IMEI and they have to set up actual hardware. These guys operate wholesale, adding the time to do that work makes an 80-90% dent in the number of transactions they can run which pretty much hoses their business model.

Or better yet, for recurring payments go to a "push" or customer-originated payment system. So for PSN, instead of giving them your credit-card number and letting them initiate charges, PSN gives you a merchant account ID and transaction code. You go to your bank (or more likely to their Web site) and set up a payment to that merchant account for the amount required, using the transaction code as a reference number. Your bank then sends the money to PSN's account. End of most existing types of credit-card fraud, because merchants don't need to know any payment information anymore. The only thing you'd need a normal merchant-initiated charge for is over-the-phone purchases, and even then if you've got a cel phone the verification process above's possible.

So why are we still doing things the old-fashioned, fraud-prone way?

PS3 root signing key revealed

Apparently GeoHot has found and published the root key used by the Playstation 3 to sign and verify games. Not just the public key used for verification, mind you, which is the easy part. They've published the private key used to sign the game executables. With the private key, you can sign your own executables and they'll be accepted by the PS3 without needing any hacks, kludges or bug exploits. This is a big deal because the key's pretty firmly embedded in the hardware itself. A simple new firmware update can't change it. And if new hardware doesn't accept the old key, then all existing games simply won't play on the new hardware.

Frankly I don't see why the console makers are so bent on keeping anything but their approved software from running on the consoles. It makes no sense. Someone who wants to run, say, Linux on the PS3 still has to buy the full-blown PS3 console, there's no way around paying Sony for that. They may not buy any games if all they're interested in is running Linux, but then if they couldn't run Linux they wouldn't be buying those games either, nor would they be buying the PS3. They might use this ability to cheat at single-player games, but what's that hurt? They're still buying the PS3 and still buying the games, and there's nobody else to be affected by their cheating. Multi-player games... hacked games might be an issue, except that those games already have lots of ways of detecting cheating on the server side where it's safe from user intervention. For instance, to prevent target hacks simply don't send the client information about objects it can't see. Not even the best hack can target what doesn't exist.

DNS root zone is now signed

The DNS root zone is now signed via DNSSEC. The idea behind DNSSEC is that the owner of a zone (roughly a domain) generates a public key and their DNS servers will digitally sign the records they serve up. Intermediate DNS servers will preserve those signatures, allowing querying machines to determine whether the records have been altered from what the authoritative nameserver sent. This makes it a lot harder to do a man-in-the-middle attack against DNS, hijacking a caching nameserver (say one belonging to an ISP) in order to re-route traffic to an attacker's servers. Not impossible, but it's a lot more involved. That's because the public key needed to verify a signature is returned from the zone above the signed zone and is signed by that zone, eg. the public key for silverglass.org's records is returned from the .org zone's server and the key for the .org zone is returned by the root nameservers. So for an attacker to forge silverglass.org records, he has to subvert the entire chain back to the root. Each verifying machine has the single key for the root zone pre-loaded (and presumably verified out-of-band to make sure it's valid), so it's infeasible to fake signatures on records for the TLDs (eg. .com, .org, .us). If I can control the records returned for .org queries I can substitute my key for silverglass.org's, allowing me to forge signatures on silverglass.org records. But since I can't substitute my key for the root key I can't fake signatures of the .org records containing the silverglass.org key, and any verifying server will detect my forgery.

That's great for security, but it poses a problem for some (IMO unethical) ISPs and DNS providers like Network Solutions. That's because they've been playing a game: when someone asks for a domain that doesn't exist, instead of returning NXDOMAIN (non-existent domain) for the query they've returned a valid result for the name pointing at their servers which serve up advertising, search results and the like. Essentially they take ownership of every single invalid domain and slap their advertisements on it. But as soon as downstream DNS servers (eg. the ones in every home router) start verifying DNSSEC signatures, the gravy train ends because those ISPs and DNS providers have no way of forging valid signatures. The only exception is that the registry operator can forge results for completely unowned domains within it's scope, and the most common DNS software around has a flag to stop that (TLD servers are expected to only delegate to 2LD servers, they should never return actual results so any results they try to return must be faked and should be treated as NXDOMAIN).

Cloud storage-as-a-service

Triggered by an article by Phil Jaenke.

You probably saw the announcement about EMC's Atmos Online shutting down. ArsTechnica had an article about it too. The short and sweet: if you were using Atmos Online directly, they aren't guaranteeing anything (including you being able to get your data back out). If you're an enterprise thinking about cloud storage as an alternative to maintaining expensive disk and/or tape in-house to hold all your archival data, this gives you something to think about.

Now, frankly, you should've been thinking about this anyway from the moment you started thinking about contracting with a vendor to store your data. Putting the magic word "cloud" in the name doesn't change the basic fact: you're putting your data in someone else's hands. When you do that you always, always account for things like "How do I get my data back from them?", "What happens if their facilities suffer damage?" and "What happens if they decide to shut down?". And you don't depend entirely on contract terms and penalties. Knowing that you can take your vendor to court and force them to pay up eventually, maybe, assuming they haven't declared bankruptcy, doesn't get you the archival data you need, and the IRS and the financial auditors and the rest won't really care whose fault it is that you can't get at data you're legally required to have available because it's your responsibility regardless.

There's also another question: how about security and privacy? Yes, against hackers attacking your supplier's network, but not just against them. What happens when your supplier gets served with a court order demanding they turn over your data to the other party in a lawsuit you're involved in? Some of that data might be e-mails between you and your legal department or outside attorneys, and reasonably subject to attorney-client privilege. But your attorneys won't get a chance to review anything before it's turned over, because you won't know it's been turned over until after the fact. How does your supplier handle this kind of situation? What steps are you taking to insure that you can't be bypassed when it comes to getting at your data?

So when IT or management asks about cloud storage, make them answer those sorts of questions first. Or at least make them think about those sorts of questions.

Oh, and the service Phil wrote about? Notice that it uses standard NAS protocols to talk to it's device, and standard formats for the stored data. That makes the question of "How do I get my data back?" a lot easier to answer.

Verizon using mail submission port 587

Verizon is moving to using port 587 for mail submission, requiring encryption and authentication to send mail. That alone won't stop the spam originating from their networks, but it's a start. My thought is that there should be 3 ports for 3 different purposes:

• Port 25, no encryption or authentication required, is for server-to-server mail transfer. Relaying shouldn't be allowed, all e-mail arriving should be addressed to an in-network domain. Anything else should be rejected. This means no relaying. Messages should not be modified except for adding an appropriate Received header.
  
• Port 587, encryption and authentication required, is for end-user mail submission only. Mail submitted to it should have the Sender header stripped and replaced with one based on the authenticated username.
• Port 465, encryption required and authentication allowed, is a hybrid. If the session isn't authenticated, it should act per the rules for port 25. Authenticated sessions should be allowed to relay. If relaying, authentication information should be added to the Received header and if no Sender header is present one should be added based on the authentication information. Messages should not be otherwise altered.

One thing many ISPs ignore (often, I suspect, willfully) is customers who do not use their ISP as their mail provider. I'm an example. I get my Internet connection from Cox, but XMission in Utah host my domain and handle my e-mail.

Security vulnerabilities and disclosure

Triggered by this SecurityFocus column. I've always been a proponent of full disclosure: releasing not just a general description of a vulnerability but the details on how it works and how to exploit it. I considered that neccesary because vendors are prone to saying "There's no practical exploit there." and stalling on fixing it, and the only way to prove there is a practical exploit is to actually produce the code to exploit the vulnerability. It also removes any question about whether you're right or wrong about the vulnerability. There's the code, anybody can verify your claims for themselves. But I've also always been a proponent of telling the vendor first, and giving them the opportunity to close the hole themselves before the rest of the world gets the details. General public disclosure was, in my view, the last resort, the stick to wave at the vendor that you'd employ only if they didn't act with reasonable dispatch to actually fix the problem.

But, as this column points out, these days the vendor's most likely to respond not by trying to fix the problem but by hauling you into court to try and silence or even jail you for having the temerity to tell them they've got a problem in thier software. Which is leading me to believe that responsible disclosure, while preferrable, simply isn't viable anymore. The only safe thing to do, the only effective way to get vendors to respond to problems, is to dump all the details including working exploit code out into public view so the vendor can't ignore it, and to do it anonymously (making sure to cover your tracks thoroughly and leave no trail leading back to you) so the vendor doesn't have a target to go after. That's the only way to avoid months if not years of legal hassles and courtroom appearances, all for you having the temerity to try and tell the vendor privately that they had a problem. IMO this is a sad state of affairs, but it also seems to be the way the vendors want it to be.

It's either this, or fight for court rulings saying that vendors have no legal right to hound researchers who try to disclose privately to the vendor. In fact, we need legal rulings saying that a vendor who tries to silence the reporters of a vulnerability instead of fixing the vulnerability make themselves legally liable for the results of that vulnerability. Short of that, researchers have to protect themselves.

My network layout

For those interested, this is how I lay out my network.

The center of the network is the gateway/router box. It's got three network interfaces on it. eth0 connects to the wired LAN, network 192.168.171.0/24. Off the gateway is an 8-port switch that handles the computer room, with a run out to the living room and a 5-port switch for the game console and my laptop when I'm out on the couch or I've run a cable outside to sit on the walkway. It's all 100-megabit Ethernet, I'm planning on upgrading to gigabit at some point. Outgoing connections/flows from this network are relatively unrestricted. The only blocks are for DNS, it's only permitted to the gateway box.

eth1 on the gateway connects to a 5-port switch where the wireless access points are attached on network 192.168.217.0/24. This network is considered untrusted, forwarding from it to other networks isn't permitted at the router so machines on it can only talk to each other or the router. In addition the router blocks incoming traffic on that interface except for DHCP and IPSec. This limits what a rogue machine on that network can do. The access points don't have WEP/WPA enabled, but they do do MAC filtering. When I upgrade to a faster AP I may enable WPA using authentication just to annoy the kiddies. The primary use for this network is to carry the IPSec VPN traffic on the 192.168.33.0/24 network. This network is considered trusted, and has the same outbound restrictions as the wired LAN segment. Forwarding between the wired LAN and VPN segments is unrestricted and un-NATed.

eth2 on the gateway is connected to the cable modem and gets it's address via DHCP from Cox. Traffic from the wired LAN and VPN going out this interface is NATed. Incoming new connections are generally blocked, with specific holes opened for connection to services on the gateway machine (ssh, Apache on a high port, the DHCP client). The outside world is considered untrusted. Outgoing traffic has a few restrictions to prevent un-NATed addresses from escaping.

Most security is based on limited physical access to the hard-wired network. The wireless network that can be reached from outside the apartment is treated the same as any network I don't control. Laptops on it should be firewalled as if operating on a hostile network, and use IPSec to make a VPN connection to the rest of my network. This avoids my having to rely on hardware I don't completely control for security.

DNSChanger malware

The Washington Post's security blog is reporting on the DNSChanger malware. This stuff isn't new. It does two things: changes your computer's DNS resolver settings so it uses DNS servers belonging to the bad guys instead of the servers your ISP provides, and activates a DHCP server so that other computers (say ones attaching to your wireless network) will take addresses and settings (including DNS server settings) from the malware instead of the legitimate server. The result is that everything you do, and everything those machines do, gets funneled through the bad guys' systems along the way. It's hard for security software to detect this, there's no mismatches and no spoofing to spot as a clue there's something wrong.

On my network, this won't work. The DHCP server part might, within limits. But my wireless access point is on a seperate physical network from the hard-wired machines and the firewall blocks the DHCP protocol between the networks. With the VPN active, that limits the damage the rogue DHCP server can do. And my firewall also blocks the DNS protocol at the edge of my network. While on my network you simply can't use any DNS server except the one I provide. If you try, your query packets will get rejected by the firewall when they try to leave my network. That means if you do get infected by DNSChanger, your DNS will simply stop working completely on my network until the problem's fixed. And my gateway machine, the one machine on my network that gets to do DNS queries to the outside world, doesn't run Windows, isn't used for Web browsing and isn't very susceptible to infection by malware.

The Srizbi botnet

After being taken down when McColo was shut down, then resurrecting itself, the Srizbi botnet has been taken down once again. It won't last, though, the botnet will start searching domain names trying to reestablish contact with it's command-and-control network, and it's operators will probably succeed We need new tactics:

1. Instead of trying to block the botnet when it searches for a new C&C network, intercept it. Put something up at the next few domains it'll try that will respond correctly and take control of the botnet. Once you've got control, use that control to have the botnet download a new module that'll remove the botnet software from the computer, then shut down the computer until the user reinstalls Windows.
2. Start sanctioning users who allow their computers to become infected. Right now there's no significant penalty assessed against the people who continue to allow their computers to be used by the botnet month after month after month. Start penalizing them. If they get infected, their Internet access gets suspended until they can provide evidence to their ISP that they've cleaned their machine up. Second offense, they get a 3-month suspension. Third offense, they get permanently disconnected. It's the Information Superhighway, and just like the real road system if you accumulate too many points we take away your driver's license.

Keeping a computer secure takes some effort and thought, especially if you're running Windows which was designed to be vulnerable. If there aren't noticeable penalties for being insecure, users just won't put forth that effort.

Browser process models

Everyone's praising IE8 for it's new one-process-per-tab model. It's got many advantages over the threaded model used by most browsers, including the fact that a crash of one tab can't take other tabs or the browser down. What most people don't seem to get is that the multiple-process model isn't new with IE8, and in fact the threaded model was one adopted only over the strenuous objections of everybody else. You see, threads exist for one reason and one reason only: on VMS and Windows (which was designed in part by the guy responsible for designing VMS), creating a process is expensive. You need threads in those OSes because you can't create a lot of processes quickly. But Unix had cheap process creation from day one. You needed another thread in Unix, you forked off another process. Threads weren't needed. But everybody in the Windows community kept braying about needing threads and why didn't Unix have them, oblivious to the fact that they already had what threads did in the fork() call. So Unix finally, reluctantly, adopted threads with all their pitfalls. And programmers used them heavily when processes would've been more appropriate. Until the pitfalls finally became too much to live with, when they went from just driving programmers nuts to causing problems for the very users who demanded them in the first place. So now we're back to where Unix was 25 years ago, forking a new process when you need a new thread of execution.

Google session vulnerability

At DefCon there was a presentation on a way to hijack a Google Mail session. Google's implemented a new option to counter it, the option to always use SSL. Now, important point: the attack is not the one that sniffs your session cookie if you're using an unencrypted link. That attack can be prevented merely by using SSL all the time. This attack will work even if you use SSL for everything. It works by inserting code on a non-GMail page that'll cause a request to the non-SSL GMail pages, and the browser will send the session cookie in that unencrypted request without you being aware of it. When you use Google's fix, setting your account to always use HTTPS, Google does more than just force you to an "https:" URL. It also wipes your existing session cookie and creates a new one with a flag on it to tell the browser to only send this cookie in secure (HTTPS) requests. This prevents the cookie from being sent in the clear ever.

DNS vulnerability

There's a few things that need to be done to completely fix the DNS cache-poisoning vulnerability Dan Kaminsky discovered.

First, filter additional response data (glue records) aggressively. In delegation responses, the only acceptable glue should be A records for the names given in the responsive NS records. In non-delegation responses only additional records for the exact name being queried should be accepted, records for other names should be discarded. If you're going to cache additional records, only records passing this filter should be cached. Ideally no additional records should be cached.

Second, implement DNSSEC across the board. It shouldn't be that hard, it just requires people to do the work. Signed data makes it impossible for an attacker to successfully get forged responses accepted (barring someone breaking the major public-key encryption algorithms).

Third, network operators near the edge of the network should implement ingress/egress filtering and require it of networks connecting to them. Towards the backbone there's too many netblocks on each interface to filter, but at the edges it's feasible to identify all the netblocks that should be sending packets across a given link. No network should ever permit a packet to go upstream unless it's source address is in a netblock belonging to that network or to a downstream network. No network should accept a packet from a downstream network unless it's sourced from a netblock attached downstream of that interface. That makes forging the source address (needed for the DNS cache-poisoning attack) nearly impossible.