BranchCache, et lite dykk (#2)

Forrige post dreide seg mer overordnet om hvordan BranchCache funker og i all enkelhet hvordan det settes opp. Denne posten skal dykke litt dypere ned i hvordan BranchCach er sydd sammen og bidra med mer detaljer.

Oppbygging

BranchCache er implementert som en tjeneste på siden av de aktuelle protokollene SMB og HTTP.

Når WebIO gjør et kall etter en nettside og får en hash (content identifier) tilbake kan BranchCache behandle denne og betjene WebIO fra sin/server/andres cache.

Dette gjør at det funker med 3.parts programmer som bruker standard Windows funksjonalitet, men ikke med f.eks nettlesere som har innebygget sin egen HTTP stack.

En av de store fordelene med BranchCache kontro WAN optimizer bokser er at vi kan cache/optimalisere SSL trafikk også. En optimizer boks som står og ser på SSL trafikk klarer jo ikke gjøre noe med den siden det er kryptert. BranchCache operere på høyere nivå på klienten/server og ser dataene før de blir kryptert på server og etter at de er dekoda på klient.

Oppdeling av innhold

I BranchCache snakker vi om innhold (content) som øverste enhet. En fil av et slag, dokument, bilde på webserver etc. I BranchCache deles disse opp i Segmenter som igjen deles opp i blokker.

Hvert Segment og hver Blokk representeres med en kryptografisk hash.

For å finne innhold vil en client benytte segment id’en for å spørre andre etter innhold. Dersom det er i Distributed Mode vil WS-Discovery protokollen benyttes, med en Probe melding etter Segment id. Ved Hosted mode spørres lokal cache server direkte om denne id’en er tilgjengelig.

Segment er minste enhet som brukes for å finne innhold, dette fordi vi ikke ønsker å spamme nettet med altfor mange forespørsler om innhold. Likevel ønsker vi å kunne hente små biter av innholdet som fort som mulig for å kunne servere til applikasjonen som spør, derfor er en Blokk minste enhet for dataoverføring.

(Strengt tatt ikke en egen protokoll som er laget for dette, kun WSD(PDF) som gjenbrukes, nærmere bestemt Probe og Probe-Match meldingene i protokollen, med custom felt satt spesielt for BranchCache.)

Protokoller

Sikkerhet

Her er det ganske mye innebygget, men lite av det du trenger å forholde deg til i praksis under drift av løsningen.

• Transport: Overføringen av data går over HTTP (mellom cachene), som ikke i seg selv bidrar mye til sikkerhet. Derfor krypteres data blokkene som sendes over nettet. Nøkkelen som brukes til kryptering av blokkene som overføres kalles Segment Secret og er derivert fra Server Secret. Derfor viktig at dennes konfidensialitet opprettholdes.
• Integritet: Det er viktig at klientene validerer innholdet de mottar. Dette gjøres ved at de sammenligner hashen de mottok som en del av beskrivelsen av innholdet fra server med en hash de selv utfører på innholdet de faktisk har fått servert. Serverene settes opp med en hemmelig nøkkel som brukes som del-input til hash algoritmene og andre nøkler deriveres fra denne.
• Tilgang: Det vil alltid
• Hosted Cache: Hosted cache servere må ha et sertifikat (server-auth) fra en sertifikatkjede som klienten stoler på. Dette for å sikre hvem klienten deler informasjon med.
• Cache: På klientene vil denne kun inneholde innhold bruker på denne klienten har benyttet. Innholdet er satt opp med ACL’er. Selve cachen er ikke kryptert, om dette er ønskelig gjelder samme som for dokumenter ellers: bruk Bitlocker eller EFS.

Firewall konfigurasjon

I Distributed mode bruker BranchCache HTTP for overføring av data mellom klientene og WS-Discovery protokollen for å finne innhold. Begge må åpnes for innkommende i firewall, fortrinnsvis med lokalt subnet og Domain profile som scope, mtp sikkerheten.

I Hosted mode brukes også HTTP for å hente innhold. Denne må også åpnes for innkommende fra cache server til klient.

HTTP Port: 80 ;)

WS-Discovery port: 3702

Neste post om BranchCache vil ta for seg konfigurasjon av Hosted Cache server rollen, en litt mer praktisk anlagt post enn denne.