Presentation is loading. Please wait.

Presentation is loading. Please wait.

Postmodern Internet Architecture Defense Zhaosheng Zhu Kevin Tan.

Similar presentations


Presentation on theme: "Postmodern Internet Architecture Defense Zhaosheng Zhu Kevin Tan."— Presentation transcript:

1 Postmodern Internet Architecture Defense Zhaosheng Zhu Kevin Tan

2 2 Shortcomings of current network layer r Protocols ignore competing economic interests r A few protocols dominate, enabling layer violations that entrench technologies. These layer violations support the policies that were not explicitly designed for within the existing architecture. r The consequences of these shortcomings are well-known: various hacks, layering violations, etc.

3 3 What we want to do r Design, implement, and evaluate through daily use a minimalist internetwork layer and auxiliary functionality that anticipates tussles and allows them to be played out in policy space.

4 4 Some novel characteristics: r We separate path determination from forwarding to allow users greater control over the paths followed by packets through the network.. r We capture an unforgeable record of the path traversed by each packet to provide the accountability that would reduce denial of service, spam, and other forms of abuse. r We separate the customer-provider relationship from topology by providing an explicit mechanism for expressing why each router should forward a packet. r We support information flow from the network to the user (for example, about traffic conditions or path availability), and policy flow from the user to the network

5 5 What must a network layer support? r A diversity of mechanisms to achieve a diversity of policies. For example, Accountability, authentication, authorization, censorship, confidentiality, spam filtering, none of which is well- supported by the Internet.

6 6 How to reach? r Remove addressing, and routing and at least some aspects of forwarding. r By decoupling these functions from the base network layer, we may construct policy-compliant source routes to deliver end-to-end performance guarantees, and provide accountability where needed.

7 7 Routing and policy r In BGP, Users have no corresponding method of expressing routing policy. r In conventional source routing, no explicit policy language expresses the means for routing through the network. r Supporting such greater routing flexibility need not rely on complex policy expressions, but rather on designed protocols that explicitly consider business rules

8 8 Application and policy r A common goal of network policy is to enable, prohibit, or charge for certain applications. r Unfortunately, the middle of today’s network is a poor environment for understanding applications. r As a result, filtering on transport-layer ports and payload inspection is increasingly difficult, especially for encrypted traffic.

9 9 Postmodern Networks layer design r At least six functional blocks should be considered m A forwarding directive (“where”) that instructs intermediate nodes how to direct or duplicate the packet. m Motivation (“why”) that compels intermediate nodes to forward packets m Accountability tokens (“who”) that allow each conversation to be audited m Knobs (“how”) that express cross-layer hints to lower layers about forwarding intentions m Dials (“what”) that recover information from lower layers, collecting, for example, the maximum observed loss rate along a path, etc., that is needed to make informed decisions about congestion control m Payload

10 10 Hardware support r Packet header bits are not and should not be precious. Bandwidth is sufficiently cheap that the network should favor carrying more information in the header rather than sacrifice functionality. r Network hardware is powerful enough to provide the flexibility needed to achieve the performance goals

11 11 Main design goal for layer design and mechanisms design r Complete isolation of routing and forwarding. r User control over inter-realm paths, within the constraints imposed by provider- specified policies. r Isolation of the basic forwarding mechanism from any kind of endpoint identifier r Support late binding of provider policies to define which packets are forwardable, and how they are forwarded.

12 12 Three major project thrusts r A forwarding mechanism that is independent of routing and does not require hierarchical addresses. r The mechanisms to support policies governing accountability and forwarding motivation. r Cross-layer mechanisms for performance and manageability.

13 13 Internetwork forwarding service r We propose a mechanism based on loose source routing r Maximizing the separation between forwarding and routing so that optimizations in each dimension can be exploited. r Forwarding does not require hierarchical identifiers linked to topology.

14 14 Forwarding mechanism r Every link (channel between forwarding elements) has a globally unique linkID that need not be tied to topology. r Each forwarding element knows the linkIDs of directly attached links. r The forwarding directive in each packet specifies the links the packet should traverse.

15 15 Communication model

16 16 Forwarding Faults Processing r Forwarding faults occur for one of two reasons: m path resolution and refinement is (implicitly) requested by the source m the specified path contains an error. r One response to a path error is to return an error message to the sender so that it can select a new path and update its routing state.

17 17 Routing protocols r We implement routing as an independent service. r Because the network is organized into hierarchical realms, conventional hierarchical routing approaches similar to those found in the Internet can be applied.

18 18 Motivation and Accountability r Packets contain explicit motivation and accountability headers that describe why the packet should be forwarded and who is responsible for that packet. r Identity makes it possible for senders and networks to populate the motivation fields and the accountability fields with unforgeable tokens.

19 19 Motivation and Accountability r Research who should be visible at the network layer r Reject Global Identity Authorities r Using Decentralized Authorities (use of clique members that certify realm identities with threshold signatures) ‏ r Research how to handle the extra overhead that would result from placing signatures in single packets, over multiple packets, etc.

20 20 Motivation and Accountability r Identity and Anonymity m Sender and Recipient are kept secret from each other m But the set of hosts participating in the protocol are always known, so issues can be resolved. r Accountability m Two-part signature: first part is realm, second part is host/router within realm. m ISPs control how topology is divulged still, but it unambiguously identifies realm packet came from

21 21 Knobs and Dials r Essentially Dials are used by lower layers to inform upper layers to make optimizations r Knobs are used by higher layers to implement such optimizations


Download ppt "Postmodern Internet Architecture Defense Zhaosheng Zhu Kevin Tan."

Similar presentations


Ads by Google