Wiki: Advanced ccTLD Workshop Planning: Emails

Email Responses to Planning Notes

From: Phil Regnauld <regnauld at x0 dot dk> To: Hervey Allen <hervey at nsrc dot org> Cc: Mirjam Kuehne <mir at isoc dot org>, Lucy Lynch <llynch at civil-tongue dot net>, Jacob Malthouse <jacob dot malthouse at icann dot org>, John Crain <crain at icann dot org>, "Steven G. Huter" <sghuter at nsrc dot org> Date: Fri, 16 Mar 2007 11:32:35 +0100 Subject: Re: Advanced ccTLD workshop ideas Hervey Allen (hervey) writes: > > Hello Everyone: > > > > Mirjam asked that I try and put something together from the notes we > > made while in Guyana and the notes she, John and Lucy put together > > last year at IETF. > > > > I've melded the two sets of ideas and come up with one possible > > outline. As usual we have way more material than we could every hope > > to teach in a 5-day workshop. So, I made some choices. My comments below, interspersed. > > I boiled down the notes to the following ideas: > > > > * Basic OS and Security (Get folks on track) aka platform hardering, which John talked mentioned. > > * Basic DNS (get folks on the same page) ... and not-so-basic DNS -- I would say: refresher on RFC1912 and BCPs ? > > * Creating a NOC > > * Monitoring your network > > * Helpdesk and ticketing requests I would wrap this under "Network management", which includes NOC, planning, monitoring and troubleshooting, i.e.: * Network Management - Network Operation Center - Monitoring for capacity planning, troubleshooting and SLAs - Helpdesk, ticketing systems and problem workflows (escalations) - Change management > > * Mitigating damage from attacks, involves: > > - Building a NOC > > - Building admin servers > > - Several DNS boxes > > - Splitting class in to two networks ... proper network design should be in there somewhere, including separation of service from server networks (i.e.: IP aliases and eventual physically distinct networks). > > - Attacking the setup > > * Scripting and automation > > * Debugging tools > > * Programmatic interfaces to DNS: > > - whois > > - registry tools > > - revision control ... revision control falls in under change management, under network management. > > - databases > > > > * How to make it all scale (can be a theme throughout the workshop) #define scalability ("how easy it is to grow performance without affecting design or complexity"). > > * Disaster recovery: > > - Logs > > - Backups > > - Archiving queries > > > > Phew! Please feel free to disagree, but I nixed the idea of creating > > two networks, attacking them, and mitigating the attack. I nixed > > this because I don't think that we, realistically, have the time to > > properly create workshop materials to do this, and because teaching > > this workshop would require much more planning and coordination. Could be -- at least it makes the network setup more complicated. > > Instead I tried to come up with something where we can > > compartmentalize the work among ourselves. Finally, I foresee the > > potential for a bunch of students to end up sitting around and "not > > getting it" while others are deeply involved in the setup and attack > > mitigation. If we keep our format to 2 students to a box, then we > > can continue to get most everyone involved. And mixing different levels, so we don't end up with newbies and l33t dud3s each on their side of the room (of course we wouldn't get newbies, since our selection process is infaillible). > > That's my take. I can be talked out of this :-) /me looks for rum. > > I've created a wiki we can all use here: > > > > ************************ > > http://ws.edu.isoc.org/ > > *********************** > > > > I've included the Guyana notes, Mirjam's notes, and this potential > > outline on the wiki. That way you can look at what's here, refer to > > the wiki and comment, make change, etc... Ok, so far I won't touch it until we agree on the line to follow. > > If we think it would be useful I can create an advanced-cctld > > mailing list as well. Let's keep this as a Cc: list for now (IMHO). > > Notes > > ----- > > * Executive decision. Machines are pre-built with FreeBSD and/or > > Linux flavor and appropriate software installed. Software packages > > will be installed by students as is appropriate. Yes, rather spend time after install showing them how to harden an existing installation (eventually talk to them about default package selections for different platforms, and how to always go for "minimal"). > > * We'll start Day 1 with a session to give folks basics of the OS we > > are using (structure, commands, package installation, start and stop > > services). Ok, at the most... (imho). Re. the day planning, I won't comment on that until we finalize the outline above. [...] > > In addition - Pleaes give feedback. Replace sections. Suggest other > > tools. Feedback on time required based on your experiences. Etc. I > > figure this can get us talking and planning. Done :)