1 / 68

BranchCache & DirectAccess

BranchCache & DirectAccess. Sébastien Pittet. Au sujet du contenu. Cette présentation comporte des slides fournis par Microsoft. En outre, elle est très largement complétée par des informations issues de reverse engineering par LANexpert. Session plan & Agenda. BranchCache. Direct Access.

Download Presentation

BranchCache & DirectAccess

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. BranchCache &DirectAccess Sébastien Pittet

  2. Au sujet du contenu • Cette présentation comporte des slides fournis par Microsoft. • En outre, elle est très largement complétée par des informations issues de reverse engineering par LANexpert.

  3. Session plan & Agenda BranchCache Direct Access

  4. Microsoft in the Branch • Home to 20% of Windows Servers • Most servers used as application servers or to provide infrastructure services H Q Branch Office Source Internal Microsoft Research 2007

  5. Branch Office Deployment Topologies Data Center Security VPN, Network Access Protection, Identity and Access Networking Centralized • + Highly resilient • + High Performance • - Costs • - Complex • + Ease of Deployment • + Simplicity • - Performance • - Single Point of Failure Distributed

  6. Network Performance Factors • Make the protocol aware of the varying network conditions • Reduce amount of Round trips the protocol makes • Reduce WAN utilization Sender Application Receiver Application Sender’s Networking Stack Receiver’s Networking Stack Network

  7. Why WAN requires special handling • Latency on WAN links • Delays connection setup • Delays Data Txfer • Degrades end user experience • Protocols can only Receive limited data based on buffer size LAN Latency < 1ms WAN Latency >100ms

  8. Impact of Latency

  9. Automatically Tune the Network Stack Automatically adjusts for maximum efficiency Faster network transfers, especially across WAN links Optimized use of available network bandwidth Reduced packet loss resulting in fewer retransmits Optimized performance without loss Intelligent, automated tuning of TCP receive window size Better packet loss resiliency (e.g., wireless connectivity) Advanced congestion control for better throughput (CTCP)

  10. Standard TCP

  11. Improving TCP Performance

  12. MS : Compound TCP (CTCP) To enable on Vista: netsh interface tcp set global congestionprovider=ctcp To disable on Win7 and Win2008R2: <idem> congestionprovider=none

  13. SMBv2 Compounding Sample • A common application generated request sequence is shown below • Left side shows resulting client-server requests without compounding • Right side shows resulting client-server requests with compounding • Benefit of round trip savings is greater the higher the link latency Open Dir Open Dir Response Query Dir Query Dir Query Volume Response Response Query Volume Close Dir Response Close Dir Query Dir Satisfied from SMB2 client cache Response Query Volume

  14. File Shares – Streaming Improvement Parallel requests greatly increase read/write speed Request Download speed (kb/sec), 100 ms RTT Response SMB1 SMB2

  15. Branch Office Enhancements Situation Today • Application and data access over WAN is slow in branch offices • Slow connections hurt user productivity • Improving network performance is expensive and difficult to implement • Windows 7 Solution SMB Enhancements BranchCache™ Transparent Caching Improved Office Experience Offline Files Enhancements Improve user productivity Reduce network bandwidth utilization

  16. New in Win7 and WS08R2 Introducing BranchCache™ • Reduce Network utilization • Improve End user experience • Preserve End to End Encryption • Simple to Deploy and Manage

  17. BranchCache™ - Distributed Cache Main Office Data Get Get ID ID Data Data Get Branch Office Get

  18. BranchCache™ - Hosted Cache Main Office Get Get ID ID ID ID ID Data ID Data Data Data Search Search Get Put Advertize Get Cache in the branch that is always available Installable on an existing WS08R2 server Works across IP subnets Request Branch Office

  19. Framework • If application is using http.sys or SMB • Public API available for other Apps WSUS SCCM Office WMP IE BITS Explorer SharePoint XCOPY/Robocopy SMB (CSC/SRV) HTTP (WebIO/http.sys) Windows BranchCache

  20. Deployment Use Group Policy to enable Windows Branch Cache on Windows 7 clients Branch Office Branch Office Install the optional “Windows Branch Cache” component on a Windows 7 web or file server Hosted Cache Branch Office IIS • Optionally, install a hosted cache in your branch. Configure clients to use it with Group Policy File Server Group Policy Management Main Office

  21. Deployment - Screenshots

  22. Situation - Demo

  23. BranchCache™ demo

  24. Monitoring • Event logs - Operational logs & Audit logs • Perfmon counters - Client, hosted cache and Content Server • netsh for querying the infrastructure for potential problems • Cache size too small, firewall issues, certificate problems etc • SCOM pack - for rolling all the information up

  25. Going deeper…

  26. Content identifiers Content (File) Segments Unit of discovery S1 S2 S3 Blocks Unit of download B1 B2 B 3 Bn B1 B2 B3 Bn B1 B2 B3 Bn Many Hashes Returned by server Segment hashes and Block hashes Hash may be up to 2000:1 ratio from original data

  27. HTTP integration IE IIS Open URL Data Get data Data “Branch Cache Capable” wininet http.sys Hashlist Hashlist Data Hashlist Data BranchCache BranchCache Data H3 Hashlist H1 H2 H4 H5 Data Hashlist H1 H2 H3 H4 H5

  28. SMB integration BranchCache Data Hashlist SMB Hash Generation Service Generate or update hash Application CSC Service HashGen Utility ReadFile Request Hashes Prefetch File Generate or update hash Savehashes Data Hashlist Request Hashes Data CSC Driver SMB Client Driver SMB Server Driver Access hashes Hashlist Data CSCCache CSC = Client-Side Caching (Offline files)

  29. How is SSL optimized? IE IIS Data in clear Data in clear BranchCache BranchCache HTTP HTTP Data in clear Data in clear SSL SSL Data encrypted Data encrypted Sockets Sockets

  30. How is IPsec optimized? Explorer File Server Data in clear Data in clear BranchCache BranchCache SMB SMB Data in clear Data in clear IPsec IPsec Data encrypted Data encrypted Network Network

  31. Security Server Blocks 64K slices of segment Block hashes BlockHashList Segment hash (HoD) HashofData = Hash(BlockHashList) Server secret key Ks (secret to server) B1 B2 Private Segment key (Kp) HMAC(Kp, HoD)  send to client Bn Encryption key (Ke) HMAC(Kp, “KeKeKe”) Segment discovery key HMAC(Kp, HoD + ”HoHoDk”) Client

  32. Flow – a security view • Client requests data from the server, and indicates BranchCache capability • Server authorizes the client • Server retrieves segment content information (block hashes, segment hashes, private segment key) one by one • Server sends these details on same channel as data • Client computes a segment ID for discovery • Multicast on the local network

  33. Flow contd. • Serving clients receive the multicast • Lookup for segment ID from the segment discovery • Respond with data availability • Client requests blocks from the serving client • Serving client computes encryption key from the segment secret key • Serving client encrypts each block with the encryption key using AES-128 • Client receives the data • Decrypts the data with its computed encryption key • Validates block data against the block hash list • If valid, returns data to application

  34. Security of data at rest • Clients • Cache only contains content requested by the client • Data in cache ACL’d so that it is only accessible if authorized by the server • If data leakage is a concern, then use BitLocker or EFS • Hosted Cache • Cache contains content requested by all branch clients • Use BitLocker or EFS to encrypt cache as necessary • All data can be purged from the cache using • netshbranchcache flush

  35. WS-Discovery (WSD) • Web Services Dynamic Discovery (WS-Discovery) • Technical specification that defines a multicast discovery protocol to locate services on a local network. • The WS-Discovery standard was developed by BEA Systems, Canon, Intel, Microsoft, and WebMethods. • As the name suggests, the actual communication between nodes is done using web services standards, notably SOAP. • Various components in Microsoft's Windows Vista operating system, such as the "People Near Me" contact location system, use WS-Discovery. • BranchCache in Distributed mode use WS-Discovery

  36. WS-Discovery - messages • Discovery sequence • Client searching for one or more target services • sends a SOAP formatted message to a multicast group • Probe message locate service by type • Resolve message locate service by name • Target services that match the probe or resolve send a response (match) directly to the client • Network operations • If IP multicast is used here are the assignments • SOAP/UDP port 3702 • IPv4 multicast address: 239.255.255.250 (ttl=1) • IPv6 multicast address: FF02::C (link-local scope) • Target service that joins the network sends hello announcement message to the multicast group • Use bye message to leave

  37. PCCRD Framework • Peer Content Caching and Retrieval Discovery • Content caching discovery protocol based on WDS • Documented in [MS-PCCRD] • Designed to reduce WAN bandwidth usage when in distributed BranchCaching mode • Client send multicast WSD probe to discover peer(s) • Probe are scoped to remain in the local subnet • Probe intend to discover segments based on HoHoDk • Peer(s) respond with unicast WSD probe match to client • Probe match is send only if peer has segment in cache • Probe contain peer sockets where to download segment • By default, if this peer learned the complete segment via 10 or more other peers it will not respond to probe

  38. Probe Discovery • Ethernet II, Src: 00:15:5d:04:f2:08, Dst: 01:00:5e:7f:ff:fa • Destination: IPv4mcast_7f:ff:fa (01:00:5e:7f:ff:fa) • .... ...1 .... .... .... .... = IG bit: Group address (multicast/bcast) • Source: Microsof_04:f2:08 (00:15:5d:04:f2:08) • .... ...0 .... .... .... .... = IG bit: Individual address (unicast) • Type: IP (0x0800) • Internet Protocol, Src: 192.168.4.2, Dst: 239.255.255.250 • Version: 4 • Header length: 20 bytes • Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) • 0000 00.. = Differentiated Services Codepoint: Default (0x00) • .... ..0. = ECN-Capable Transport (ECT): 0 • .... ...0 = ECN-CE: 0 • Total Length: 842 • Time to live: 1 • Protocol: UDP (0x11) • User Datagram Protocol, Src Port: 63342, Dst Port: ws-discovery (3702) • Length: 822 • Data (814 bytes) Detailed in next slide

  39. Probe Discovery <?xml version="1.0" encoding="utf-8"?> <soap:Envelopexmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsd="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:PeerDist= "http://schemas.microsoft.com/p2p/2007/09/PeerDistributionDiscovery"> <soap:Header> <wsa:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</wsa:To> <wsa:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe </wsa:Action> <wsa:MessageID>urn:uuid:d29a1861-35a8-44c4-a79e-d08b3e3e0b4a </wsa:MessageID> </soap:Header> <soap:Body> <wsd:Probe> <wsd:Types>PeerDist:PeerDistData</wsd:Types> <wsd:ScopesMatchBy="http://schemas.xmlsoap.org/ws/2005/04/discovery/ strcmp0">1A70F20150DB3225F69929A14BC4DF88E8B83559F10F303F9DD3C60296 EFAEE8</wsd:Scopes> </wsd:Probe> </soap:Body> </soap:Envelope> HoHoDk (Segment discovery key)

  40. Probe Match Response ... <soap:Header> <wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To> <wsa:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/ProbeMatches</wsa:Action> <wsa:MessageID>urn:uuid:8ed3bb68-5990-480c-94ae-c56c21f350e8</wsa:MessageID> <wsa:RelatesTo>urn:uuid:d29a1861-35a8-44c4-a79e-d08b3e3e0b4a</wsa:RelatesTo> <wsd:AppSequenceInstanceId="1237828411" MessageNumber="1"/> </soap:Header> <soap:Body> <wsd:ProbeMatches> <wsd:ProbeMatch> <wsa:EndpointReference> <wsa:Address>urn:uuid:38579136-1d5e-41ab-9420-4c7b9f3d1c4d</wsa:Address> </wsa:EndpointReference> <wsd:Types>PeerDist:PeerDistData</wsd:Types> <wsd:Scopes>1A70F20150DB3225F69929A14BC4DF88E8B83559F10F303F9DD3C60296 EFAEE8</wsd:Scopes> <wsd:XAddrs>192.168.4.1:80</wsd:XAddrs> <wsd:MetadataVersion>1</wsd:MetadataVersion> <PeerDist:PeerDistData><PeerDist:BlockCount>00000002</PeerDist:BlockCount> </PeerDist:PeerDistData> </wsd:ProbeMatch> </wsd:ProbeMatches> </soap:Body> ... Socket for download Number of block(s) in segment

  41. PCCRR Framework • Peer Content Caching and Retrieval : Retrieval • Content caching retrieval protocol based on HTTP • Documented in [MS-PCCRR] • Protocol defines two request/response exchanges between a client and a server • Request via HTTP POST on path /{116B50EB-ECE2-41ac-8429-9F9E963361B7}/ • Content Retrieval Request (GetBlocks) • Download non disjoint blocks or less than four consecutive blocks. Current implementation get block one after the other. • Server reply with a content (Ke encrypted) or nothing if not found • Content Availability Request (GetBlockList) • Used to check the availability of a block list (disjoint or >3) • Server reply with range of requested content it has

  42. Discovery and Retrieval • Time Source Destination Proto Info • 0.305079 192.168.4.2 239.255.255.250 UDP Dst port: ws-discovery • 0.400034 192.168.4.1 192.168.4.2 UDP Src port: ws-discovery • 0.508525 192.168.4.1 192.168.4.2 UDP Src port: ws-discovery • 0.516309 192.168.4.2 239.255.255.250 UDP Dst port: ws-discovery • If there is a probe match the client fetch blocks one by one from peer • Time Source Destination Proto Info • 0.468117 192.168.4.2 192.168.4.1 HTTP POST /116B50EB-ECE2-41ac-8429- • 9F9E963361B7/ HTTP/1.1 (68 bytes) • 0.491281 192.168.4.1 192.168.4.2 HTTP HTTP/1.1 200 OK (chunked block 1) • 0.509451 192.168.4.2 192.168.4.1 HTTP POST /116B50EB-ECE2-41ac-8429- • 9F9E963361B7/ HTTP/1.1 (68 bytes) • 0.544430 192.168.4.1 192.168.4.2 HTTP HTTP/1.1 200 OK (chunked block 2) • ... • 192.168.4.2 = client requesting segment • 192.168.4.1 = peer having segment and responding to probe • 239.255.255.250 = link local IPv4 multicast for discovery

  43. Decode FSCTL Request Ethernet II, Src: 00:15:5d:04:f2:08, Dst: 00:0c:29:6e:32:0e Internet Protocol, Src: 192.168.4.2, Dst: 10.2.4.244 Transmission Control Protocol, Src Port: 49210, Dst Port: microsoft-ds (445), NetBIOS Session Service SMB2 (Server Message Block Protocol version 2) SMB2 Header Fsctl Request (0x0b) Length: 56 Function: Unknown (0x001441bb) 0000 0000 0001 0100 .... .... .... .... = Device: NETWORK_FILE_SYSTEM .... .... .... .... 01.. .... .... .... = Access: FILE_READ_ACCESS .... .... .... .... ..00 0001 1011 10.. = Function: 0x0000006e .... .... .... .... .... .... .... ..11 = Method: METHOD_NEITHER GUID handle File: test2.txt File Id: 00000025-02f0-0000-1500-0000ffffffff Max Ioctl Out Size: 64512 In Data Offset: 0x00000078 Length: 24 unknown: 01000000010000000100000000FC00000000000000000000 Out Data: NO DATA Offset: 0x00000078 Length: 0 Decoded Next Slide SRV_READ_HASH

  44. To Summarize BranchCache™ reduces WAN bandwidth consumedby end users for intranet based HTTP and SMB traffic and improves end user experience. BranchCache™ accelerates delivery of encrypted content such as when using HTTPS and IPsec, and at the same time ensures authorization of users by the server at the central office. BranchCache™ doesn’t require additional equipment in the branch offices and can be easily managed using existing systems management technology such as group policy

  45. Windows 2008 R2 Direct Access … and requirements!

  46. DirectAccess Requires IPv6 • to providing seamless, secure access to enterprise resources from anywhere Internet Enterprise Network DA Server IPv6 IPv6 Application Server

  47. Why aren't you supporting IPv6 now? • No pressing need • No business value • No customer demand

  48. Pressing Need

  49. IANA/8 Allocations By Year NAT (RFC 1631, May 1994) and CIDR (RFC 1517, Sep 1993) introduced Average 12 allocations per year since 2003

  50. Power, and by Extension, Money,Throughout the World

More Related