Internet2 Network Security SIG

["Dale W. Carder" <>]

Hey Steve,

I'd be pretty curious what on-campus services would still actually work.
For example there's all sorts of web things that require cloud-hosted
javascript libraries, browsers still doing OSCP validation will hang,
etc.  I think this would be testable by configuring a client with an ACL
that blocks all off-campus resources.

Though, there is still the user perception issue.  If even email is
down, to many users that might mean the "network" is down such that they 
might not even bother to access campus resources.

Dale

Thus spake Steven Wallace 
()
 on Thu, Nov 02, 2017 at 11:00:26AM -0400:
> For the last year I’ve been investigating approaches to mitigate the 
> effects of a university-wide Internet outage. Like many universities, IU 
> has systems hosted locally, as well as in the cloud. Sometimes these 
> systems are interdependent. For example, our web single sign-on is hosted 
> locally, however it’s require to access cloud-based applications (e.g., 
> box, canvas, etc.). During an Internet outage, students/faculty/staff 
> wouldn’t be able to access canvas from their home Internet connections, as 
> they wouldn’t be able to access their campus-based web sign-on. On campus, 
> canvas would also be inaccessible, as it’s hosted in the cloud.
> 
> I’ve categorized mitigation approaches into two broad use cases: providing  
> access to critical applications for users off-campus, and access to 
> applications on-campus.
> 
> Delivering cloud-based applications to on-campus users during an Internet 
> outage seems straightforward: establish a dedicated/isolated/direct 
> connection to critical cloud providers such as AWS (AWS hosts canvas). 
> On-campus access to canvas fixed!.....not so much. Canvas’s domain is 
> instructure.com. The campus DNS resolver will provide an answer from its 
> cached entry for a while, perhaps an hour, but afterwards the resolver is 
> going to need to actually recursively query instructure.com. That might 
> work for a while...but it get worse.
> 
> At some point the resolver is going to want to query the TLD server for 
> .com, and ultimately a DNS root server. If the university only has access 
> to AWS (remember all Internet access is down), unless the university is 
> hosting a local root and .TLD (which is an option), the dedicated 
> connection to AWS is going to become useless.
> 
> It’s going to get better. BIND 9.12 (currently in beta, GA due out end of 
> year?) supports “serve stale” (see: 
> https://tools.ietf.org/html/draft-tale-dnsop-serve-stale-02 
> <https://tools.ietf.org/html/draft-tale-dnsop-serve-stale-02>). Serving 
> Stale Data to Improve DNS Resiliency - does what you’d expect. If the 
> resolver can’t update a cached entry, it responsed with the its current 
> cached entry. BTW, this would have mitigated the October Dyn outage, which 
> left many in the community without access to Box, PayPal, etc., despite the 
> fact that we had working network paths to these service providers.
> 
> 
> I’m interested to hear if/how others are planning for prolonged Internet 
> disruptions. Would a working group be useful?
> 
> Thanks,
> 
> steve
> 
> 
> 
>