Leveraging Good Intentions to Reduce Unwanted Network Traffic Marianne Shaw (U. Washington) USENIX 2nd Workshop on Steps to Reducing Unwanted Traffic on the Internet (SRUTI), 2006.

2009/4/7 Speaker: Li-Ming Chen 2 Related Work: Reduce Unwanted Network Traffic Network-based approach  Monitor and characterize network traffic (normal or abnormal)  Eliminate unwanted traffic by identify them Source-limiting approach  E.g., Ingress filtering, reverse firewall…  Define good behaviors of managed users Approach is not independent  Protect one side, assume one side is trustworthy

2009/4/7 Speaker: Li-Ming Chen 3 Motivation User-administrated machines are well- intentioned but easily compromised  Once compromised, they will be used to amplify attacker’s ability to inflict damage Can we leverage users’ non-malicious intentions to prevent their machines from being used to generate unwanted traffic?  Say, even when compromised, these machines only generate well-behaved traffic

2009/4/7 Speaker: Li-Ming Chen 4 The Concept AB Normal communication Hmm, I don’t want this one :( Stop sending, please… (good intention!!) Malicious attempt ! Okay, I accept. (not being blocked!) Malicious attempt blocked !

2009/4/7 Speaker: Li-Ming Chen 5 Goal Propose a solution to reduce unwanted network traffic by enabling either side of a conversation to summarily terminate the conversation without the other endpoints cooperation.  A control plane is used to monitor conversations between endhosts  A enforcement mechanism is used to prevent unwanted traffic injecting into the network  Host-based, no extra mechanism is needed within the network

2009/4/7 Speaker: Li-Ming Chen 6 3 Key Observations (Design Rationales) Accept that machines will be compromised  But can avoid them generate unwanted traffic?! Users would be willing to thwart their machines to be used to inflict damage Defining and identifying unwanted behavior is difficult and often subjective  Two hosts may not classify the same traffic in the same way Can we leverage users’ non-malicious intentions to prevent their machines from being used to generate unwanted traffic?

2009/4/7 Speaker: Li-Ming Chen 7 A Simple Example: TCP-based Prototype Leverage the characteristics of TCP (connection oriented) to develop a prototype that is virtually invisible to endhosts AB Enf. Mech. In this case, The enforcement mechanism executes on a separate physical machine (act as a gateway for A) Connect with a dedicated Ethernet connection Guarantee host A will not generate unwanted traffic

2009/4/7 Speaker: Li-Ming Chen 8 A Simple Example: TCP-based Prototype Normal case: When A starts flooding B, B may send a RST packet to stop the packet flood. AB Enf. Mech. RST (good intention!!) Flooding packets Stop flooding!  However, attacker may ignore the RST, and continue to send high rates of unwanted packets.

2009/4/7 Speaker: Li-Ming Chen 9  However, attacker may ignore the RST, and continue to send high rates of unwanted packets. A Simple Example: TCP-based Prototype AB Enf. Mech. RST (good intention!!) Leverage good intention: Once the enf. mech. observes a valid incoming RST packet, the enf. mech. drops all outgoing network packets associated with this connection. Continue flooding packets Oh, I know that B want to close this connection & the intention is good! Packets blocked

2009/4/7 Speaker: Li-Ming Chen 10 Requirements (problems) When receiving unwanted traffic, B must be able to identify the source. Only honor requests to temporarily terminate an existing packet stream. Enf. mech. must be voluntarily adopted by endhosts. Upon receiving a termination request, the packet stream must be terminated without A’s cooperation. AB Enf. Mech. Enf. Mech. Only a recipient of unwanted traffic can make the request. (This mechanism can not be used for malicious intention)

2009/4/7 Speaker: Li-Ming Chen 11 Design The control plane The enforcement mechanism

2009/4/7 Speaker: Li-Ming Chen 12 Design: Control Plan Signaling 1. Unique Identifier AB Enf. Mech. Enf. Mech. Problem: DHCP, IP spoofing.  IP is the unique identifier of an active conversation  IP Accountability is necessary! A must not spoof its IP address. B can identify and contact A. B should not be penalized for spoofed packet. Enf. Mech. can sense reasonable IP change. Enf. Mech. will discard requests coming from spoofed IP

2009/4/7 Speaker: Li-Ming Chen 13 Design: Control Plan Signaling 2. Defining a Network Conversation AB Enf. Mech. Enf. Mech. A network conversation is used to track sequence of network packets  Dictates which packets will be dropped when a termination request is received. Conversation principals: 5-tuples Conversation start/stop: 1. observe network packets and maintain internal state (e.g., TCP) 2. or observe patterns of network activity

2009/4/7 Speaker: Li-Ming Chen 14 Design: Control Plan Signaling 3. Termination Requests AB Enf. Mech. Enf. Mech. Require a new signaling mechanism Indicate which network conversation is being terminated Indicate the amount of time of the termination B must decide unwanted traffic, Send termination requests back to A, Must not spoof its own identify (IP address).

2009/4/7 Speaker: Li-Ming Chen 15 Design: Enforcement Mechanism (avoid being attacked/misused) 1) the enforcement mechanism cannot be bypassed or subverted by attackers 2) the enforcement mechanism cannot be undermined by replaying a previous conversation through the mechanism 3) the enforcement mechanism can be deployed incrementally by end users and removed as needed, which should be extremely rare.

2009/4/7 Speaker: Li-Ming Chen 16 Endpoint Authentication (TCP example) The enforcement mechanism must provide its own endpoint authentication.  Adding a random 32-bit nonce to the initial sequence number (ISN) during connection establishment  Ensure that two untrusted, colluding hosts cannot subvert the enforcement mechanism.  Man in the middle attack?

2009/4/7 Speaker: Li-Ming Chen 17 Conclusion Argue that one can leverage good intentions of uses to reduce unwanted traffic on the Internet.  Well-intentioned hosts can summarily terminate unwanted traffic  By using independent control plane and enforcement mechanism

2009/4/7 Speaker: Li-Ming Chen 18 My Comment (1/3) A new idea to build up security mechanism But it’s somewhat passive :(  Accept host is vulnerable and will be compromised  Once being bothered by a malicious host, request for termination   In real world, compromised might be unacceptable   besides, a vulnerable host gains nothing from this mechanism Except not generating too much unwanted traffic to the Internet, after it got infected !!

2009/4/7 Speaker: Li-Ming Chen 19 My Comment (2/3) The action is triggered by well-intentioned hosts  What does unwanted traffic mean to me?  How to show my good intention?  not discussed in this paper…  or not implemented in on-line protocols & applications and enforced by its peer (who sends unwanted traffic)  Accountable, integrity (for both)

2009/4/7 Speaker: Li-Ming Chen 20 My Comment (3/3) Receive unwanted traffic, but request for termination for others!  E.g., stop sending packets to this subnet  Or stop scanning on these ports Reflection !?  Why everybody don’t like me? It must be something wrong…