1. T-110.5140 Network Application Frameworks and XML Summary and Conclusions 25.04.2006 Sasu Tarkoma

2. 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

3. Interconnections Network Security Objects Directories
Interconnections applicable on many levels
Network-level operation
DNS, overlay lookup, IPsec
Application-level operation
UDDI, SSL, WS-Security

4. Mobility and Routing

5. Naming, Addressing, and Routing
How to identify and name a node?
Frequent updates?
One or two new name spaces?
NAMING
unicast: to a specific node
broadcast: to all nodes
multicast: to a subset of nodes
anycast: to any one in some subset (IPv6)
ROUTING
ADDRESSING
Where is the node located?
Differences (IPv4/IPv6)
Multi-addressing?
How to route information to the node’s address? NAT traversal?
Overlay vs. network routing

6. Routing vs. mobility Topology data aggregation is necessary
Cannot track all hosts in the world
IP addresses determined by topology
Network gives the routing prefix
Mobile hosts must change their IP addresses
Causes sockets / connections to break
How to communicate address changes?
Goal of a mobility protocol
Transport and applications do not see address changes

7. Rendezvous How to find the moving end-point?
Tackling double jump
What if both hosts move at the same time?
Requires a rendezvous point
Mobility management is needed!
Initial rendezvous
Can be based on directories
Requires fast updates to directories
Does not work well for DNS

8. Identity/Locator split
Process
Transport
New name space for IDs
Maybe based on DNS
Maybe a separate namespace
Maybe IP addresses are used for location
Good for hiding IP versions
Communication end-points (sockets) bound to identifiers
identifier
ID Layer
locator
IP Layer
Link Layer

9. Host Identity Protocol
New cryptographic namespace
Connection endpoints mapped to 128 bit host identity tags (hashes of public keys)
Mapping at HIP layer
4-phase Base Exchange with cryptographic puzzle for DoS prevention
IPSec for network-level security

10. Upper layer view IP connectivity problematic today
Broken by firewalls, NATs, mobility
Two versions of IP: IPv4 and IPv6
HIP has a potential remedy
Restores end-to-end connectivity (NAT traversal possible but may require changes / tunnelling)
Adds opportunistic security
Handles mobility and multi-homing
Requires DHT based overlay (currently missing)
Where is the network state?
Routers know addresses
Like today
DHT knows HITs / SIDs
Lease based storage
Middleboxes know SPIs
Soft state

11. Lessons to learn Hierarchical routing likely to stay
Addresses carry topological information
Efficient and well established
Applications face changing connectivity
QoS varies
periods of non-connectivity
Identifiers and locators likely to split
Mobility management is needed
Probably changes in directory services
Overlays have been proposed

12. Summary Topology based routing is necessary
Mobility causes address changes
Address changes must be signalled end-to-end
Mobility management needed
Initial rendezvous: maybe a directory service
Double jump problem: rendezvous needed
Many engineering trade-offs

13. Distributed Hash Tables and Overlays

14. Overlay Networks Origin in Peer-to-Peer (P2P)
Builds upon Distributed Hash Tables (DHTs)
Easy to deploy
No changes to routers or TCP/IP stack
Typically on application layer
Overlay properties
Resilience
Fault-tolerance
Scalability

15. Some DHT applications File sharing Web caching
Censor-resistant data storage
Event notification
Naming systems
Query and indexing
Communication primitives
Backup storage
Web archive

16. Applications for DHTs
DHTs are used as a basic building block for an application-level infrastructure
Internet Indirection Infrastructure (i3)
New forwarding infrastructure based on Chord
DOA (Delegation Oriented Architecture)
New naming and addressing infrastructure based on overlays

17. Summary Mobility and multi-homing require directories
Scalability, low-latency updates
Overlay networks have been proposed
Searching, storing, routing, notification,..
Lookup (Chord, Tapestry, Pastry), coordination primitives (i3), middlebox support (DOA)
Logarithmic scalability, decentralised,…
Host/identity split and overlays for directories seem good candidates for solving many of the issues with mobility and multi-homing

18. Middleware

19. Middleware Widely used and popular term Fuzzy term One definition
“A set of service elements above the operating system and the communications stack”
Second definition
“Software that provides a programming model above the basic building blocks of processes and message passing” (Colouris, Dollimore, Kindberg, 2001)

20. Why Middleware? Application development is complex and time-consuming
Should every developer code their own protocols for directories, transactions, ..?
How to cope with heterogeneous environments?
Networks, operating systems, hardware, programming languages
Middleware is needed
To cut down development time
Rapid application development
Simplify the development of applications
Support heterogeneous environments and mask differences in OS/languages/hardware

21. Middleware cont. Middleware services include
directory, trading, brokering
remote invocation (RPC) facilities
transactions
persistent repositories
location and failure transparency
messaging
Security
Network stack (transport and below) is not part of middleware

22. Transparencies Location transparency transport protocol transparency
RPC and RMI used without knowledge of the location of the invoked procedure / object
transport protocol transparency
RPC may be implemented using any transport protocol
transparency of OS and hardware
RPC/RMI uses external data representation
Presentation is important
XML is becoming increasingly important
transparency of programming languages
language independent definition of procedures: CORBA IDL

23. Network Application Framework
Network Application Framework is middleware
Contains services for distributed applications
Middleware as a term is fuzzier and larger
In this course, we focus on network application frameworks and XML
objects (discovery, representation)
directories (overlays,..)
network
security

24. Examples Middleware Mobile middleware CORBA
Message-oriented Middleware
Event Systems & tuple spaces
Java Message Service
Java 2 Enterprise Edition (J2EE)
.NET
Mobile middleware
WAE
J2ME
Wireless CORBA
FUEGO

25. Mobile Middleware I
Middleware is typically designed and implemented for fixed-network hosts
High bandwidth, low latency, reliable communication
Persistent storage and sufficient computing power
No mobility
Mobile environment requires new solutions
Existing middleware services do not scale
Previous lectures: mobility is challenging
Small devices / embedded systems pose totally different challenges

26. Mobile Middleware II Goals for middleware: Mobile middleware
fault-tolerance, adaptability, heterogeneity,scalability, resource sharing
Mobile middleware
dynamically changing context
decoupled
events, tuple spaces
Basic solution for wireless
Use a proxy

27. Summary Middleware Mobile middleware
for application development and deployment
for supporting heterogeneous environments
Main communication paradigms: RPC/RMI, asynchronous events (publish/subscribe)
J2EE, CORBA, ..
Mobile middleware
Desktop middleware not usable on small, mobile devices
Special solutions are needed
J2ME, Wireless CORBA, ..

28. Web Services

29. Standardization W3C Web Services OASIS
XML Protocol Working Group
SOAP
Web Services Addressing Working Group
Web Services Choreography Working Group
Web Services Description Working Group
WSDL
OASIS
E-business standards, UDDI
WS-I (Web Service Interoperability Org.)
Binding profiles,..

30. Web Service Architecture
The three major roles in web services
Service provider
Provider of the WS
Service Requestor
Any consumer / client
Service Registry
logically centralized directory of services
A protocol stack is needed to support these roles

31. Web Services Protocol Stack
Message Transport
Responsible for transporting messages
HTTP, BEEP
XML Messaging
Responsible for encoding messages in common XML format
XML-RPC, SOAP
Service Description
Responsible for describing an interface to a specific web service
WSDL
Service discovery
Responsible for service discovery and search
UDDI

32. WS Protocol Stack Discovery: UDDI Description: WSDL
XML Messaging: SOAP, XML-RPC, XML
Transport: HTTP, FTP, BEEP, SMTP, JMS

33. What is WSDL? WSDL: Web Service Description Language
An XML language used to describe and locate web services
location of web service
methods that are available
data type information and XML messages
Commonly used to describe SOAP-based services
W3C standard (work in progress)
Initial input: WSDL 1.1 as W3C Note
Current version 2.0 (last call)
Some differences between 1.1 and 2.0
WSDL 1.1 in WS-I Basic Profile 1.0 and 1.1.

34. WSDL Overview <definitions>: ROOT WSDL element
<types>: The data types that are used
<message>: What messages are transmitted?
<portType>: The supported operations
<binding>: The binding to concrete protocols
<service>: Reference to actual location

35. Mapping SOAP to WSDL

36. Putting it together
Source:

37. SOAP Message Structure
SOAP Envelope
Optional header contains blocks of information regarding how to process the message:
Routing and delivery settings
Authentication/authorization assertions
Transaction contexts
Body is a mandatory element and contains the actual message to be delivered and processed (and fault information)
SOAP Header
Header block
Header block
SOAP Body
Message Body

38. What is UDDI?
Universal Description Discovery and Integration
Industry-wide initiative supporting web services
Specifications
Schemas for service description
Schemas for business (service implementers) description
Developed on industry standards
Applies equally to XML and non-XML web services
Implementation
Public web service registry and development resources
SOAP-based programming protocol for registering and discovering Web services
XML schema for SOAP messages
a description of the API
UDDI does not directly specify how pricing, deadlines, etc. are handled/matched
Advanced discovery via portals and marketplaces

39. Web Services Security

40. Need for XML security XML document can be encrypted using SSL or IPSec
this cannot handle the different parts of the document
documents may be routed hop-by-hop
different entities must process different parts of the document
SSL/TLS/IPSec provide message integrity and privacy only when the message is in transit
We also need to encrypt and authenticate the document in arbitrary sequences and to involve multiple parties

41. High-level view to WS security
Security is as strong as the weakest link
The options for an attacker are:
Attack the Web Service directly
Using ”unexpected” XML
Attack the Web Services platform
Attack a WS security tool
Attack the underlying operating system or network connection

42. Application-layer Security
Identity-based security
Authentication and authorization information shared across security domains
Content-based security
Protecting against buffer overflow and CGI-like attacks
Must have knowledge about the applications to which these messages are directed
Accountability or non-repudation
Need message level security
Maintain integrity, archived audit trails
The standards and specifications mentioned earlier address these issues

43. Standardization landscape
Who are specifying the basic standards?
Who are specifying the higher level standards?
Who is implementing the standards?

44. Who are specifying the standards?
Joint IETF/W3C
XML Signature (
W3C
XML Encryption (
XML Key Management (XKMS) (
OASIS
WS-Security
SOAP Message Security specification etc.
SAML: Security Assertion Markup Language
XACML: Extensible Access Control Markup language
Electronic Business XML (ebXML) (with UN/CEFACT)
Web Services Interoperability Organization (WS-I)
Basic security

45. Standardization Groups
Extensible Rights Markup Language
W3C
OASIS
XrML
Provisioning
XML Common Biometric Format (XCBF)
eXtensible Access Control Markup Language (XACML)
XML Key Management Specification
WS-Security
Biometrics
XML Encryption
XML Signature
XKMS
SAML
XACML
Security Assertion Markup language

46. Basic XML Security XML Digital Signatures (XMLDSIG) XML Encryption
XML Canonicalization
XML Key Management

47. Web Services Security Requirements
Access control to Web services
WS-Security, XML-Signature
SAML – Issuing and validation of SAML assertions
Digital certificate validation
Content-filtering XML
Filters based on data format (XSD)
Filters based on content (XPath)
Filters based on integrity (XML Signature)

48. Functional point of view
XML
Management
Console
Design and
Deploy
Security
policies
ID Management
LDAP
PKI
Single Sign-On
Authorization
Authentication
Content Checking
Reporting
Activity
Alerting
Secure logging
Integrity
Validation
Routing
XML

49. Security Contexts in Web Services
Remember Web Services goals:
Re-use existing services
Combine services from several domains
Security result: Must support several security domains
SOAP intermediaries
Reusing security tokens from one message in another message

50. Summary Security contexts WS security standard revisited SAML
Security needed within and between contexts
XML validation, encryption, and authentication needed between security contexts!
WS security standard revisited
SOAP header carries security information (and other info as well)
Selective processing
SAML
Statements about authorization, authentication, attributes
SAML & WS-Security & XACML
Implementations available

51. Putting it together

52. With identity/locator split + overlays?
CONTROL
Upper layers
DNS names, custom
identifiers
Overlay
Overlay addresses
Host Identities
Congestion
IP addresses
ID Layer
IP addresses
End-to-end
DATA
Routing
Routing paths
Routing paths

53. ”Theory” WS Security SOAP TCP IP ”Practice” WS Security SOAP TCP4 IPv4
HTTP/TLS/sockets
TCP6
IPv6
”Future?”
WS Security
SOAP
IPv4
HTTP?/sockets
IPv6
TCP
HIPsec H I P C
T R L

54. Discussion

55. Important Dates Exam on Tuesday 16.5. 9-12 in T1.
Deadline for the second assignment 12.5.