1 / 48

Contents

T-110.5140 Network Application Frameworks and XML Introduction and overview 5.2.2007 Sasu Tarkoma Based on slides by Pekka Nikander. Contents. Introduction Starting point, topics, goals Overview Networking: naming, addressing, routing Multi-addressing:Mobility, multi-homing

Download Presentation

Contents

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. T-110.5140 Network Application Frameworks and XML Introduction and overview5.2.2007Sasu Tarkoma Based on slides by Pekka Nikander

  2. Contents • Introduction • Starting point, topics, goals • Overview • Networking: naming, addressing, routing • Multi-addressing:Mobility, multi-homing • Security: Trust, risks, protocols, keys • Objects: Encapsulation, XML, frameworks • Performance: bandwidth, delay, bottlenecks • Connections between aspects • Examples

  3. Starting Point • Assume that you already know details of • TCP/IP and underlying technology • Basics of cryptography and cryptographic protocols • Java, C++, and OO programming • Basic client/server programming • Adding to these • Distributed objects and distributed security • XML and Web services • Architectural overview and understanding • New directions in research and standardization

  4. Topics Covered • Distributed systems security • Multi-addressing: Mobility and multi-homing • Building applications with XML • Distributed objects • Role of directory services • Mobile and wireless applications • XML-based presentation and RPC • Scalability and performance issues

  5. Course focus and goals • General overview of all aspects involved • Ability to implement distributed systems • Hands-on experience with CORBA, SOAP (web services), XML, network-level security • Understanding of • Distributed object-oriented systems • Crypto based security in distributed systems • XML and how it is used in practise • Performance issues • Architecture and why does it matter

  6. Course Info • Course structure • Lectures on Mondays 14-16 in T5 • Two assignments as pair-work • Final exam on Tuesday 10.5. 9-12 in T1 • Study materials for the course • Lecture slides and handouts, scientific papers, and relevant standards • Several books for background

  7. Contact information • Lectures • Sasu Tarkoma (@tml.hut.fi) • Assignments • Jani Heikkinen (@tml.hut.fi) • More information will be posted soon • Common questions to the newsgroup: • opinnot.tik.naf • For those who do not yet have a group, please read/post to this newsgroup. • Personal questions by email: • T-110.5140@tml.hut.fi

  8. Lecture Outline Please check the news section on the web page for updates!

  9. Overview

  10. Networking • Communication between distributed entities • What are network entities? • How are they named? • How are they connected? • Where is state? • How it is created? • How it is removed? • How it is maintained? • How are resources allocated?

  11. Naming, Addressing, Routing I/II NAMING ADDRESSING ROUTING

  12. Naming, Addressing, Routing II • Naming, addressing, and routing may be applied on many levels and for different purposes • Naming • Simply the name of an entity • For example: a domain name • Addressing • The address of an entity • For example: geographical location, IP-address

  13. Routing • Routing • How information is routed to the entity in distributed environment • Examples: IP-routing, overlay-routing • For the remainder: we assume that addresses are assigned topologically • Prefix-routing (network part, host part) • More flexibility: CIDR • Keeps routing tables manageable • Addresses depend on location

  14. Mobility and Multi-addressing • Multi-addressing • Entities may have multiple addresses • Mobility requires support for address change • In mobility the topological location (access point) changes --> the address changes • Mobility • Mobile nodes • Handover terminology • make-before-break • break-before-make • Moving networks

  15. Mobility Example:Mobile IP Triangular Routing Correspondent host Triangular routing Foreign agent Home agent Home link Foreign link Mobile host

  16. Multi-addressing • Multi-homing • Server has multiple addresses on different networks for increased reliability • Client has multiple addresses • Multi-homing requires support for address change • Topology change can cause renumbering • From old prefix to new prefix • Changing the IP host addresses of each device within the network • Related with multi-homing and must be supported by mobility protocols

  17. Site multi-homing ISP1 Multi-homed site End-host multi-homing NAT1 Internet ISP2 NAT2 WLAN GPRS Wireless Host Multi-homing Examples

  18. Multi-layer Operation • Mobility and multi-homing can be realized on different layers • Network (Mobile IP) • Between network and transport (HIP) • Transport (SCTP) • Application (SIP, Wireless CORBA, overlays)

  19. View points to Distributed Systems • User view point • Services that work • 24/7, anywhere • Usability, security • Developer view point • Easy to develop and debug • Fast time-to-market • Administrator view point • Easy to deploy and maintain • Scale well • Secure

  20. Security Requirements • Requirements • Confidentiality • Authentication • Authorization • Rules, policies, ACLs • ticket-based schemes • Non-repudiation • Auditing and logging • Availability

  21. Security • Physical network operated by many parties • Not all operators can be trusted • Protecting subnets • Firewalls, NATs, middleboxes • Connectivity problems • Need for cryptographic protection • Integrity and confidentiality of data • Identification, access control, and authorization • Key distribution and trust creation/evaluation

  22. Objects • Information hiding for programmers • Extend a familiar paradigm to a distributed environment • Psychological drawbacks • Huge difference in latency • Completely different fault semantics • Synchronization problems • How to name and find objects? • Using services provided by third parties?

  23. Performance • Network Quality of Service (QoS) characteristics • End-to-end latency • Bandwidth • Sometimes also jitter matters • A dynamic phenomenon if packet switched • Congestion leads to drops or delays • Different paths have different QoS properties • Two worlds: wireless and wired

  24. Delay and failure model • A uni-processor machine works or fails • A method call takes a few nanoseconds • In a network, • round trip latency may be ~ 100ms • a single end-node may fail • a path between two end-nodes may fail • performance may fall to unacceptably poor level

  25. Interconnections • Layered model • Object centric view • Network centric view • Directories vs. security Network Security Objects Directories

  26. Layered Model Presentation Object API, serializ. Presentation Session “Transaction”, RPC Transport Congestion control End-to-end Internetworking Routing

  27. Object centric view Network Security Object API to network Object-level security Objects Directories Naming and finding objects

  28. Naming and finding objects • Each object needs to have a name • Each type (class) needs to have a name • Each method (action) needs to have a name • Objects may be mobile, replicated, ephemeral, or permanent • How to find an object? • How to maintain a consistent view of types?

  29. Providing an object API • Mostly a naming related issue • How to find the object? • How to find type and method meta-data? • How to refer to remote objects? • How to move objects over the network? • How to synchronize replicated objects? • Abstraction of delay and faults

  30. OO security • Objects represent reactive data storage • May implement access control logic • Threads of execution act upon them • <Thread ID, Call History> --> {permissions} • How to trust a remote node? • How to represent threads, call history, and permissions over the network?

  31. Network centric view Network security Network Security Secure network mgmt Delay and failure mode Naming, addressing, and directories Objects Directories

  32. Network security • Large networks are physically vulnerable • Cryptography for integrity and confidentiality • Need to solve the key distribution problem • Not everybody is equally trusted • Need to have identities and credentials • Availability depends on protocol design • Privacy depends on protocol design • Balance: security vs. ease of administration vs. performance

  33. Naming, addressing, and directories • Network entities are named • DNS names: www.example.org • Names need to be translated to addresses • Network knows how to forward to an address • A directory provides translation information • Avoid circular design! Make sure that basic networking works even without directories.

  34. Chicken and egg with security and directories Security • Security mechanisms require access to long term public keys • Directory access must be protected Access control Long term keys Directories

  35. Examples • Networking: IPv4 and IPv6 • Directories: DNS • Security: IPsec and IKE • Objects: Java RMI

  36. Networking: IPv4 and IPv6 • Hosts named and addressed by IP address • Two broad classes of state: • Routing and forwarding tables • End-to-end state • IP addresses are assigned topologically • Forwarding tables • Created by routing protocols • Converge time: minutes

  37. Concerns with networks • Non-forwarding,non end-to-end state: NAT • Should always be soft state • Congestion control, reliability, packet drop / retransmission, flow control • Traditionally handled at the transport layer • Routing hardware design and cost • Complexity of next-hop lookup • QoS facilities, queues, traffic shaping

  38. Directories: DNS • Provides Domain Name to IP address mapping • Hosts are no longer named with IP addresses • Replicated, hierarchical repository • Data cached at end-hosts • Reduces traffic • Make update distribution slow • Partitioned into administrative domains • Relatively poor security • Mostly relies on manual configuration

  39. Concerns with directories • Actual data storage and structure • Logical structure: architecture • Physical structure: performance • Partitioning, replication, caching • Access control: reading, modification • Representation of relationships • Representation of objects

  40. Security: IPsec • IP Security (IPsec) • End-to-end, below congestion control • Authentication Header (AH) • Integrity and authenticity (immutable IP header+payload) • Problems with NATs (dst mutable) • ESP (Encapsulating Security Payload) • Transport-mode: higher level payload • host-to-host • Tunnel-mode: payload is IP packet • network-to-network • Mostly in tunnel mode, VPNs • Contains a complex policy control model • Does not work for IP control traffic

  41. IKE • IPSec separates key management into IKE / IKE v2 • Security Association (SA) • relationship between two or more entities that describes how the entities will use security services to communicate securely • Internet Key Exchange (IKE) • negotiates the IPSec security associations (SAs) • IKE creates an authenticated, secure tunnel • Five authentication options • negotiates the security association for IPSec • authentication, establishment of shared keys

  42. IPsec and IKE 1.No IPSec SA for Bob 4. Protected packets are sent to Bob IPSec Alice IPSec Bob IKE Alice IKE Bob IKE Tunnel 2. Alice’s IKE starts negotiations 3. Negotiation completes. IPSec SAs in place

  43. Concerns with security • Right layer to implement? • What about multi-layer security? • Privacy? DoS protection? • Trust management? • How to bootstrap trust? • Authorization and credentials?

  44. Objects: Java RMI I/II • Java Remote Method Invocation • Objects in one VM invoke methods in objects in a remote VM • Remote handle • From the registry name facility • By receiving the reference as an argument or return value of a method call • Client needs stubs (generated from interfaces / downloaded, rmic compiler) • Type polymorphism adds interesting semantics • Run-time dispatch instead of compile time • Dynamic binding • Parameters of method calls are passed as serialized objects (deep copy)

  45. Objects: Java RMI II 5. Skeleton calls method 1. Client Obtains Handle Application Client Server 2. Stub is called (rep. Remote object) 7. Stub unmarshals result and passes it to client (type checking) 3. Marshalling arguments 6. Skeleton marshals result Stubs Skeletons RMI system Remote Reference Layer 4. Skeleton unmarshals Transport Transport independence. Connection management. Unicast/multicast object invocation.

  46. Concerns with objects • Object Discovery • Representation of Object Handle • Reliability and disaster recovery • Fault tolerance: Replication, Consistency, etc. • Version detection • Marshalling and unmarshalling • Transparency vs. efficiency • Performance • Easy to send more data than necessary! • Distributed garbage collection • Semantics: defining objects beyond appearance • Supporting heterogeneous environments

  47. Summary • Networking: naming, addressing, routing • Multi-addressing:Mobility, multi-homing • Security: Trust, risks, protocols, keys • Objects: Encapsulation, XML, frameworks • Performance: bandwidth, delay, bottlenecks

  48. Questions / discussion

More Related