Assignment 3
Posted by Ooi Wei Tsang in assignment on April 2, 2013
Here is your third and final assignment. You may download the PDF version of Assignment 3 here and the packet dump here. You have two weeks to complete this assignment individually. The assignment is due on 15 April, 2013, 6pm. You may hand in a hardcopy to me before the deadline. Some words of advice:
- Start early.
- Do not copy from each other.
DIY Exercise 4
Posted by Ooi Wei Tsang in diy exercise on April 1, 2013
Here is your forth DIY exercise. This is an ungraded exercise, but completing the exercise should deepen you understanding of the materials covered in class. You are encouraged to ask questions and discuss your results online on the blog.
Lecture 10: LAN and WiFi
Posted by Ooi Wei Tsang in lecture on March 30, 2013
1 April, 2013.
This week we will take a look at another multiple access protocol, CSMA/CA for WiFi, and discuss the roles of hubs, switch, and routers in forming a LAN. ARP will be discussed as well.
Slides: PDF
Please read the following sections in the textbook.
- 5.4 Switched Local Area Network (exclude 5.4.4)
- 6.3.1 The 802.11 Architecture
- 6.3.2 The 802.11 MAC Protocol
Problem Set 7
Posted by Ooi Wei Tsang in tutorial on March 30, 2013
Download the PDF version of Problem Set 7 here. Please attempt the questions before coming to class, and be prepared to present your solutions.
CS2105 in the News: How the Spamhaus Attack Work
Posted by Ooi Wei Tsang in in the news on March 28, 2013
The DDoS hits, which are thought to have ranged from 75Gbps up to 300Gbps in power, came from what is known as DNS reflection – a way to amplify traffic to swamp servers and take websites offline. These attacks rely on what are known as “open recursive resolvers”, used in the DNS process, where URLs are translated to IP addresses, so people can access websites by typing in names (e.g. Google.com) rather than numbers (e.g. 216.239.51.99).
Attackers spoof themselves an IP address – the one belonging to their target. They then make a large number of requests for DNS zone files – which contain mappings between domain names and IP addresses - to open DNS resolvers. The resolvers respond and send back a load of traffic to the victim, clogging up their pipes and taking them offline.
Assignment 2: Common Misconceptions and Questions
Posted by Ooi Wei Tsang in assignment on March 27, 2013
We received many questions about the following points:
- Should I call send( ) of RDTSender or UDTSender when I retransmit?
Note that when you retransmit, you are not sure if retransmission will be received or not — in other words, retransmission is done UNreliably. If you call send( ) of RDTSender to retransmit, this could work as well, but since this leads to recursion, it is less straightforward and bug prone. Unless you really know what you are doing, I would recommend the most straight forward method.
- What should I return if RDT’s recv( ) / send( ) did not receive the expected DataPacket or AckPacket?
This is an invalid question. RDTSender’s send( ) should send the given data reliably. It should not return until it ensures that the given data is received by the receiver. Similarly, RDTReceiver’s recv( ) should return the next chunk of data. It should not return until it can deliver the next chunk of data.
- Why did I get XYZ Exception and how should I handle it?
If you get an exception related to object streams, this is very likely caused by having multiple timers active at the same time or multiple send( ) at the same time. Check that you have only one timer at a time, and there is no possibility that two send( ) is called at the same time.
If you get an exception at the sender due to receiver closing of connection after the receiver receives the final packet, this is excepted. You should just catch the exception, clean-up the sender, and return.
If you get a null pointer exception, figure out which pointer is null. Then check that the variable is initialized properly and the variable is accessible within the correct scope. We can’t help much with this one since, unlike the above, this exception is a general programming bug rather than protocol bug.
Lecture 9: Link Layer
Posted by Ooi Wei Tsang in lecture on March 24, 2013
25 March, 2013.
This week we continue our venture down the protocol stack, and look at the link layer. We will review the services provided by the link layer, how error detection/correction is done, how shared medium are accessed, and finish up with a discussion on Ethernet frame format.
Slides: PDF
Please read the following sections in the textbook.
Reading: Chapter 5
- 5.1 Introduction to the Link Layer
- 5.2 Error-Detection and -Correction Techniques
- 5.3 Multiple Access Links and Protocols (skip efficiency analysis in 5.3.2)
- 5.4.2 Ethernet – Ethernet Frame Structure (page 497 – 499)
Assignment 2: Tricky Synchronization Bug Warning and Fix
Posted by Ooi Wei Tsang in announcement, assignment on March 22, 2013
There is a tricky thread synchronization bug, discovered by Junliang, that could manifest if you create your timer first before sending your DataPacket. The bug causes an IllegalClassException when the receiver reads the DataPacket.
To prevent this bug from biting, you need to either (i) send the DataPacket before setting the timer, and ensure that only one timer is active at a time, or (ii) add the keyword “synchronized” in the send() method of UDTSender as follows:
/**
* Given a data packet from RDTSender, this method sends
* the packet to the receiver by writing it into the
* object output stream.
*/
synchronized void send(DataPacket p) throws IOException
{
System.out.println("S: send " + p.seq);
oos.writeObject(p);
oos.flush();
}
You can add this keyword yourself, or copy a new version of UDTSender:
cp ~sadm/a2/UDTSender.java ~/a2
(after making sure that your local copy of UDTSender.java is writable)
If you are familiar with thread synchronization issues, and would like to know more, read on.
Read the rest of this entry »
Problem Set 6
Posted by Ooi Wei Tsang in tutorial on March 20, 2013
We will start the discussion of Problem Set 6 next week. Download the PDF version of Problem Set 6 here. Please attempt the questions before coming to class, and be prepared to present your solutions.
CS2105 in the News: Google, Microsoft, and Mozilla revoke two fraudulent Turkish certificates used in targeted attacks
Posted by Ooi Wei Tsang in diy exercise on March 18, 2013
This news appeared early this year.
An attacker armed with a fraudulent SSL certificate and an ability to control their victim’s network could impersonate websites in a way that would be undetectable to most users. Such certificates could deceive users into trusting websites appearing to originate from the domain owners, but actually containing malicious content or software.
CS2105 in the News: Lack of HTTPS in iOS App Store
Posted by Ooi Wei Tsang in in the news on March 18, 2013
Apple finally turns HTTPS on for the App Store, fixing a lot of vulnerabilities
By abusing the lack of encryption (HTTPS) in certain parts of the communication with the App Store, the dynamic nature of the App Store pages, and the lack of confirmation, an active network attacker can perform the following attacks:
- Password stealing: Trick the user into disclosing his or her password by using the application update notification mechanism to insert a fake prompt when the App Store is launched.
- App swapping: Force the user to install/buy the attacker’s app of choice instead of the one the user intended to install/buy. It is possible to swap a free app with a paid app.
- App fake upgrade: Trick the user into installing/buying the attacker’s app of choice by inserting fake app upgrades, or manipulating existing app upgrades.
- Preventing application installation: Prevent the user from installing/upgrading applications either by stripping the app out of the market or tricking the app into believing it is already installed.
- Privacy leak: The App Store application update mechanism discloses in the clear the list of the applications installed on the device.
Midterm Solution
Posted by Ooi Wei Tsang in midterm on March 18, 2013
1-7: E D C B X D B
8. 28 ms; 4 ms; 0 ms; 36 ms
9. (1100,1200) or (1100,1300); Timer starts after first ACK, timeout, retransmit 1100. Receive ACK 1300, start another timer, timeout, retransmit 1300. Receive ACK 1400. Done.
Recent Comments