CSC424-C/ECE524-C: Communication and Security

News and Announcements for CSC424 Communication, Distribution and Security.

Tue 18 April:

Project 6 posted.

Wed 13 April:

change Slack session time to 6pm (proposal).

Wed 12 April:

Slack session (a.k.a. the tutorial) Friday, April 14, at 7pm.

Sat 8 April:

add slackchat @: https://csc424miami.slack.com/signup.

Sun 19 Mar:

Grades for Project 3 posted.

Wed 25 Feb:

Grades for quiz 5 and 6 posted.

Wed 22 Feb:

Quiz 6 posted.

Mon 20 Feb:

Grades for quiz 1-4 and proj1 posted.

Mon 20 Feb:

Project 3 posted.

Wed 15 Feb:

Quiz 5 posted.

Wed 8 Feb:

Project 2 posted.

Wed 8 Feb:

Quiz 4 posted.

Wed 1 Feb:

Quiz 3 posted.

Mon 30 Jan:

Project 1 posted.

Wed 25 Jan:

Quiz 2 posted.

Welcome:

Class calendar:

Wed 3 - Wed 10 May:

Finals

Fri 28 Apr:

Classes End

Mon 13 - Fri 17 Mar:

Spring Break

Tue 17 Jan:

Semester begins. Welcome!

Syllabus for CSC424 Communication, Distribution and Security.

This is a course in:

• The standard communication protocols of computers, including TCP/IP,
• and the security concerns consequent to those protocols;
• The craft of highly skilled coding in C, following specifications,
• and understanding and countering sophisticated attacks against system security.

• Readings:
  • Computer Networks, Fifth Edition: A Systems Approach
    (The Morgan Kaufmann Series in Networking) 5th Edition,
    Other editions might be acceptable.
    by Larry L. Peterson (Author), Bruce S. Davie (Author).
    ((Amazon))
  • Security Engineering: A Guide to Building Dependable Distributed Systems,
    2nd Edition,
    by Ross J. Anderson.
    ((Amazon))
• New Media:
  • The class Twitter is http://twitter.com/csc524. Please follow it.
  • The class blog is http://blog.cs.miami.edu/burt/category/csc524/.
• Work:
  • Quizzes: Generally one per week. Out on Monday after class, due the next Wednesday by the end of class.
  • Projects: A series projects, assigned from a Monday to the second following Monday. However, this might vary according to pace and vacation schedule.
  • Project grading: Projects are generally scored on a 0 to 5 scale, with 5 being reserved for excellent projects.
  • Grade depends on completeness, correctness, and presentation.
  • Use of Subversion, Makefiles and file and folder names as requested are a must.
  • Lateness: Three days grace automatic on projects. One additional point off each week late, up to four points. No lateness for quizzes.
  • All work to be done by the last day of class.
  • Class grading: After normalizations, 60% projects, 40% quizzes.
• Computers:
  • You should have an Ubuntu virtual image on running on Virtual Box (or similar), on your own computer or computers.
  • You will have a csc424 lab account, with the lab machines similar to csc220.
  • We will make extensive use of subversion, a source code control system, to distribute your work across machines, and to submit assignments.
• Contact:
  • The TA is Sam Mittelhaeuser, sammittelhaeuser _at_ gmail _dot_ com.
  • My Office hours: by appointment.
• Writing credit: optionally the student may elect for wiring credit.
  • Writing credit for courses not marked W is no longer available.

Class notes for CSC424 Communications and Security.

Packet communications and the Internet

• Introduction
  • Tools of the trade and network etiquette.
  • The OSI ISO model (image)
  • Discussion: Why layers? Why not layers?
  • Peer-to-peer responsibilities vs. SAP (service access points)
  • Encapsulation, headers and payload, demultiplexing (unpacking) (image)
  • Implementation and standards, for the Internet/WAN (image) and for the LAN (image)
• Basic concepts
  • Packet versus connection.
  • Broadcast versus routed.
  • Common and point-to-point mediums.
  • LAN versus WAN, and an internet.
• Sockets
  • File I/O
  • Socket operations
  • BSD Socket interface: Beej's Guide to Network Programming
• Enough networking to be dangerous
  • command line tools:
    ping
    • traceroute
    • ifconfig
    • tcpdump
  • Header formats
    • L2 frame contains an IP packet with an IP header
    • The IP packet can contain an UDP packet that starts with an UDP header
    • ICMP
• The wizard behind the curtain
  • Undersea cables map
  • telia (Looking Glass)
  • FL Lambda Rail
  • Bundled, Buried and Behind Closed Doors.

Adresses and Names

• What's in a name
  • The MAC address is "just a name", and it pretty useless "far away" from the destination.
  • Names, such as www.miami.edu, are non-entities in TCP-UDP/IP. Only numbers count.
  • The role of DNS to turn names into numbers, before the networking game starts.
• L2: MAC address (OUI),
• L3: IP
  • The IP address gives the network name for the endpoint, and contains routing information in the prefix.
  • IP space map.
  • Classfull addressing
  • CIDR introduce in RFC 1518 and RFC 1519 in September 1993.
  • Private local addresses (private address)
  • NAT and PAT (various flavors)
• L4: Ports (well-known and ephemeral)
  • Well Known Ports (a.k.a. Reserved),
  • Registered ports
  • Ephemeral ports (a.k.a. dynamic)

Routing

• Autonomous systems (AS), interior and exterior routing
• Local delivery vs. routing; known route vs. default route
• Distance vector Notes
• counting to infinity; split horizon and poison reverse
• RIP
• Link State Protocols

Core UDP Services and protocol considerations

• Domain Name Service (DNS). See RFC 1034 and RFC 1035.
• Dynamic Host Configuration Protocol (DHCP) RFC 2131
• Trivial File Transfer Protocol (TFTP)
• RIP, BGP, OSPF
• Conclusions concerning protocol design

TCP/IP

• IP details: Fragments, TTL
• IPv6
• Notes on TCP
• TCP Trace using tcpdump

Network Authentication

• Authentication primer
• Passwords and entropy measurements
• Dictionary attacks; hashing
• Skimmers, sniffers, and Trojans
• One-time-passords and multi-factor authentication: e.g. sKey, SecureID
• Challenge response: e.g. NTLM
• Indirect Authentication: e.g. RADIUS
• Needham-Schroeder and Kerberos
• Authentication Providers and Single-signon: e.g. Central Authentication Service (CAS)
• Proxy walk through
• SSL & TLS
  • SSL Tutorial
  • Public Key Infrastructure and digital signatures

Comon Services

• email
  • Simple Mail Transfer Protocol (SNMP)
  • Post Office Protocol (POP)
  • Internet Mail Access Protocol (IMAP)
  • Overview of architecture and protocols
  • Example of spam defense
  • Sender Policy Framework
  • DKIM (wiki)
• HTTP
  • The Form
  • POST trace
  • caching, proxies
  • redirects
  • cookies and Sessions
• Distributed Coordinating Processes
  • Javascript, AJAX and JSON
  • REST
  • XML and SOAP
  • RPC and RMI (Java)

Local Area Networks

• Carrier Sense Multiple Access / Collision Detect (exponential backoff)
• Data signaling
  • 10Base-5: manchester encoded half-duplex 10Mbs
  • 10Base-T: Manchester Encoding full duplex over 4-pair unshielded twisted pair.
  • 100Base-TX:, MLT-3 and 4B5B line encoding.
  • 1000Base-T: 8B10B symbol encoding with PAM-5 line encoding, over 4 pairs simultaneously (256 symbols), with Trellis Forward Error Correction
  • 1000Base-SX: optical short distance, -LX long distance optical
• Ethernet frames
  • Preamble and SFD
  • Ether Type 0x0600 and up, ex 0x0800 IP and 802.1Q tag 0x8100
  • Length (0x5ff and down) and the SNAP
  • Frame Check Sequence
• MAC addresses
• Broadcast, and multicast; the broadcast domain
• WiFi
  • Class blog about WiFi.
  • Javvin documentation
  • BSS and infrastructure
  • Associations
  • Protocol: RTS, CTS, NAV and positive acknowledgment
  • Frame structure, relay addressing
  • Routing, bridging, and switching
  • Other: the beacon, and power-down buffering
• Switches, bridges, and hubs
  • bridge transparency
  • Learning bridges
  • Bridge Spanning Tree Protocol (IEEE 802.1D)
• AT&T Achives: The step by step switch

Quizzes for CSC424 Communications and Security.

See my subversion tutorial for getting a start with Subversion.

Quiz 1:

Email me your c-number and email address.
Due Friday, January 20, midnight.

Quiz 2:

See [repo]/class/quiz/quiz2.txt; submit as [repo]/[username]/quiz/quiz2.txt.
Due Friday, January 27, by end of class.

Quiz 3:

See [repo]/class/quiz/quiz3.txt; submit as [repo]/[username]/quiz/quiz3.txt and your public key.
Due Friday, February 3, by end of class.

Quiz 4:

See [repo]/class/quiz/quiz4.txt; submit as [repo]/[username]/quiz/quiz4.txt.
Due Friday, February 10, by end of class.

Quiz 5:

See [repo]/class/quiz/quiz5.txt; submit as [repo]/[username]/quiz/quiz5.txt.
Due Friday, February 17, by end of class.

Quiz 6:

See [repo]/class/quiz/quiz6.txt; submit as described in that file.
Due Friday, February 24, by end of class.

Projects for CSC424 Communications and Security.

Assignments:

• Project 1: Simplex Talk
  • Detailed instructions for the Simplex Talk Project.
  • See Beej's Guide to Network Programming.
  • Due: Wednesday, Feb 8.
• Project 2: Packet Pass Around
  • Detailed instructions for the Packet Pass Around Project.
  • Due: Wednesday, Feb 22 Friday, Feb 24.
• Project 3: Truly Trivial File Transfer Protocol
  • Detailed instructions for the TTFTP project.
  • Due: Wednesday, March 8.
• Project 4: Truly Trivial File Transfer Protocol — Resend Timer Option
  • Detailed instructions for the project.
  • Due: Wednesday, March 23 Friday, March 25.
• Project 5: A Mini-Radius server
  • Detailed instructions for the project.
  • Due: Wednesday, April 19.
• Project 6: A Mini-Radius OTP protocol
  • Detailed instructions for the project.
  • Due: Friday, April 28.

General Requirements:

• Projects are programming projects, done in C on Unix.
• All reasonable effort shall be made to make your code platform independent. However, there are differences between platforms, and for the purposes of this class your code is working if it works on Ubuntu 16.04.01 server version, 32-bit (i386).
• You will share and submit your projects using the departmental subversion site, svn.cs.miami.edu.
• Please refer to my subversion tutorial and the Subversion red book for information about subversion.
• You will use Makefiles so that the graders and assistants can build your projects from source, and are guided through your test suites.
• You will given some test suites. The performance of your code on these test suits define a basic level of correctness.
• You will make additional test suites for your code, and your code maybe be tested on reasonably considered correctness criteria, beyond those implied in the given test suites. It is expected that you will anticipate these reasonably considered correctness criteria, and your test suites will address those.

Coding style:

• Your name and date must be in comments at the top of all files. I consider this your promise to me that this is your own work, or you have explained the source of the code otherwise.
• Use only lower-case in filenames, with exceptions for strong historical precedence: Makefile, README.TXT, maybe a few others. Never distinguish a file by case, and always refer to the file by the chosen case.
• Do not declare variables in the middle of a block. Reject this C99 feature. A variable's scope and lifetime should be a block, end of story. Coding is hard enough.
• Do not use Variable Length Arrays (VLA). Reject this C99 feature. They turn sizeof from a keyword into a function call, sometimes, and you now have run-time type errors as well as run-time allocation errors. Coding is hard enough without turning your back on the compiler's assistance in memory layout and type computation.
• You can use // style comments.
• I'm conflicted on the use of zero-length arrays. Harbison and Steele tells me I'm an outlaw, but I can't seem to care. Your choice.
• Comment what isn't obvious. Comment what confused you when you wrote this code.
• Comment assumptions on parameters at the top of the function block.
• I prefer writing subroutines more basic first, so I don't need forward declarations. I consider this a huge hint to debuggers about what depends on what. I recommend not doing forward declarations unnecessarily.
• Use header files. Consider them as declaring your API. What's in the .h file explains what you intend to be the stable functions and types, as opposed to helper functions that might change.

Lab Accounts

1. A lab account as been set up for you, with username abcd424, if abcd is your subversion username. The lab account has the same initial password as the password to your subversion account. You can change the password on the lab account, but it won't change it on the subversion account.
2. You can work on the lab machines either in Ungar 426 or remotely. In general, you will have to log into lee.cs.miami.edu and from there log into a lab machine. The lab machines are not directly accessible to the internet. You are requested not to run you code on lee. It is a small machine but will happily act as a ssh gateway.
3. From lee, you can log into any of the machines in the lab. Your home directory on every lab machine is the same. For instance, if you edit a file in your home directory on antietam, those changes will show up on the same file in shiloh.
4. Using the public key feature of ssh, if you access the lab from your own computer without having to type a password. This also allows scp to work without a password, so file copy between local files and the lab works if it were a local copy. Public key authentication is more flexible and more secure than password authentication, although it only works from a trusted machine that stores your private key.
5. Also, you can set up your .ssh/config file for transparent login from lee to a lab machine. See the this blog post to walk you through the setup. You will want to log in to multiple lab machines at the same time, so that you are really truly running your code over a network of machines.

Ubuntu and Virtual Box

1. Install Virtual Box, or similar, on your own machine to develop code locally on your own machine, if you are not running Ubuntu 16.04 LTS.
2. Download the ISO file for Ubuntu 16.04 LTS.
3. For the operating systems course, 32-bit server version is a graceful survivor of all the damage we do to the operating system. For OS, use that version.
4. For the networking course, you can take the default 64-bit desktop, if you wish the advantages of a desktop. We are kind citizens and do not abuse our OS in the networking course.
5. Launch Virtual Box and create a new virtual machine: 2G mem, 32G disk, dynamic disk allocation, VDI format.
6. When it boots, it will ask for a disk. Browse to your ISO image (downloaded in step 2 above).
7. You might select LVM in the panel asking about the installation type.
8. Insert the Guest Additions from the Devices pull-down menu item, install and reboot.
9. Once booted again, open the terminal and "sudo apt-get update ; sudo apt-get upgrade" to bring your system up to date, the reboot. (Do this every so often, particularly if there are security related updates.)
10. Install the subversion client with "sudo apt-get install subversion". This is all I needed to get proj1 to build. The grader suggests "sudo apt-get install build-essential". I've done this in the past as well, when curses or make is not default installed. Keep it in mind if some buildtool doesn't seem to be installed.

MAC OSX

1. Install XCode on your Mac. It is available in the App Store for free.
2. After installation, take the additional step to install the command line tools. Last time I did this, it was accomplished using "xcode-select --install" in a terminal window. However, xcode->open developer tools->more developer tools will open an Apple Developer login; register and login, and d/l the command line package and install.
3. Mac's ship with subversion. I dont' even think you need XCode for that.
4. Mac's ship with ssh. You can set up your ~/.ssh/config file, and make public keys, to make it easy to login and scp files.
5. On a Mac, d/l and install TextWrangler, http://www.barebones.com/products/textwrangler/. This is my preferred WYSIWYG code editor. It allows you to edit a file remotely through SFTP. Set this up by including in .ssh/config a Host stanza and public key credentials so that authentication is automatic. See Nerderati.

Windows

1. For Windows local developement, I recommend installing cygwin, https://www.cygwin.com/. In my experience, Visual Studio is powerful, but limited by being Microsoft-centric and lacking a command line development style. Meanwhile, several other important command line tools are missing from Windows. Install Cygwin and develop in a Unix-like environment in Windows.

References for CSC424 Communications and Security.

• AT&T Archives: Switchboards, Old and New
• The Life of a Telephone Operator in 1969
• Training For Service, 1926 — AT&T Archives — Telephone Operator recruiting