1 / 20

An End-Middle-End Approach to Connection Establishment

An End-Middle-End Approach to Connection Establishment. Saikat Guha Paul Francis {saikat,francis}@cs.cornell.edu Presented by Xin Liu. Outline. The Problem System Architecture Use Cases & Extensions Proof-of-concept Implementation. EME Naming & Addressing Requirements: Old Internet.

latika
Download Presentation

An End-Middle-End Approach to Connection Establishment

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An End-Middle-End Approach to Connection Establishment Saikat Guha Paul Francis {saikat,francis}@cs.cornell.edu Presented by Xin Liu

  2. Outline • The Problem • System Architecture • Use Cases & Extensions • Proof-of-concept Implementation

  3. EME Naming & Addressing Requirements: Old Internet • User-friendly naming (DNS) • Network-level identification (IP) • Identification of the application (Port) • Implication: application takes care of security • Whether to receive a packet • No danger processing a packet

  4. More EME Naming & Addressing Requirements: Current Internet • Blocking of unwanted packets (Firewall) • Middleboxes interrupt E2E semantics • There is poor defense against DDoS attacks • Explicit negotiation of middlebox usage • Limited NAT hole punching techniques

  5. NUTSS • User-friendly names • (foo@bar.com, ftpd) • Dynamic and secure name-address binding • SIP-like • Both on-path and off-path signaling (related work does not have both) • With middlebox usage negotiation • More than satisfying EME requirements • Mobility, multi-homing, protocol stack negotiation

  6. Name-routed Signaling

  7. Network Structure • Core: no middleboxes • P-Box: overlay node for name-routed signaling • M-Box: data-forwarding nodes including firewalls and NAT gateways • One P-Box is associated with multiple M-Boxes and has zero or more parent P-Boxes • Discovery of parent P-Box: the child sends an address-routed message to upstream, and due to lack of authentication token, the parent’s M-Box will send back the address of the parent’s P-Box

  8. Name Registration Access Control: REGISTER message may be rejected

  9. Flow Negotiation On-path & off-path coupling: Tok signed by P-Box and verified by M-Box

  10. Address-routed Packets Token validation is only done for FlowInit packets Flow states are setup by FlowInit packets AddToFlowTable(P)

  11. Connection Setup Example

  12. Connection Setup Example

  13. Connection Setup Example • Previous approaches do not work • TCP/IP & HIP does not work: both endpoints are behind NAT gateways • SIP+STUN etc: M4 blocks the communication

  14. Security • Akamai-like protection: allowing massive replication of P-Boxes and M-Boxes • External DDoS protection required • Token mechanism may be co-opted with capabilities • Trust between P-Boxes: not regulated by the paper • Token eavesdropping: a small alternation needed, i.e. never send tokens in the clear • Hop-by-hop authentication prevents off-path P-Boxes from injection • Token replay: finer grained tokens, similar to TVA capabilities

  15. Incremental Deployment • 1st phase: only endpoints support NUTSS • Incentives: mobility, (limited) NAT traversal, end-to-end access control • 2nd phase: P-Boxes deployment • Incentives: gaining insight into and weak access control over flows • 3rd phase: full deployment

  16. Use Cases & Extensions • Mobility • SIP-like • Legacy NAT traversal • Endpoint-imposed middleboxes • Allowing endpoints to specify anonymizers to hide real addresses • Application-level anycast • Multiple endpoints REGISTER a single name • Pseudo-anycast? Address contains instance number

  17. Use Cases & Extensions • Negotiating multicast • Identify group members with instances and transmit messages to all members • Default-off • Disallow name-routed messages by default • Protocol negotiation • SIP-like

  18. Optimizations • Goal: reducing latency • Piggyback application data in signaling messages • Combine FlowNegotiate and FlowInit when P-Box and M-Box are on the same machine (states are setup with FlowNegotiate) • Include Self-Certifying Identifiers in FlowInit messages and send mutiple FlowInit messages in parallel to pre-establish failover paths

  19. Implementation • SIP-variant • P-Boxes: SIP Express Router proxies • M-Boxes: including shim P-Boxes to couple name-routing and address-routing • Endpoints: user space library • New socket API • Hacking gethostbyname(), connect(), etc

  20. Implementation Findings • SIP can almost implement NUTSS • Lack of nested domains • Latency • 15ms when P-Boxes are deployed on the same network segment as the endpoints • P-Box can route about 1200 name-routed messages per second

More Related