What’s (probably) coming next in SMB - .NET Framework...SMBD QUIC TDI WSK NDK/RDMA TCP UDP...

Post on 18-Aug-2021

2 views 0 download

Transcript of What’s (probably) coming next in SMB - .NET Framework...SMBD QUIC TDI WSK NDK/RDMA TCP UDP...

What’s (probably) coming next in SMB SMB Core Dev team

Microsoft Corporation

Big things in flight

Compression Security QUIC

Question breaks

Compress SMB payloads

Better perf over narrow/congested networks

Good at large, inefficient data formats

Shipped (partial story) in 19H1 aka 1903

Compression

Pattern 0: All-zero

Pattern 1: [0-255]…

Pattern 2: Not Compressible

Data Patterns Used

SMB Compression Demo

Client negotiates for compression via negotiate context:

Server responds with compression algorithm(s) XPRESS, XPRESS Huffman, LZNT1, PATTERN_V1:

Negotiation

Algorithm Id 1Algorithm Count Algorithm Id 2

2 Byte 2 Byte 2 Byte

Selected

Algorithm Count

Selected

Algorithm ID 1

2 Byte

Selected

Algorithm ID 2

2 Byte

New, compact transform header for SMB Compression

Current transform header is 52 bytes and not 8-byte aligned

Compress and Decompress

Reserved 1* Reserved 2*Algorithm

Protocol ID 8B

16B

Original Message Size

When compressing & encrypting, nest the transform headers

Compressing encrypted packets means bad compression ratio, so force encryption after compression

Interop

SMB Encryption

Transform Header

SMB Compression

Transform Header

SMB2 HEADER and

other payload …

Data Pattern 1, Seq Write, End-to-end throughput (Gbps)

11

0

20

40

60

80

100

120

140

160

180

1 2 3 4

Series1 Series2

Data Pattern 1, Seq Write, CPU Usage (%)

12

0

10

20

30

40

50

60

70

80

90

1 2 3 4

Series1 Series2 Series3 Series4

Data Pattern 1, Seq Write, Total Network Usage to Transmit 1TB of Data (GB)

13

0

200

400

600

800

1000

1200

1 2 3 4

Series1 Series2

Sampled for CopyFile()

Usage customizable via registry

No user interfaces or management yet

Documented in Open Protocol Spec

Windows implementation details

Questions about compression?

Accelerated Signing

RDMA Signing and Encryption

Security

Historical: SMB 3.1.1 client only supported CMAC

Irony: encryption perf better than signing

Now: Adding AES-GMACBetter perf algorithm

Nonce with each packet improves replay attack prevention

Signature validation moved to lower layers for faster rejection

Accelerated Signing

Client will support AES128-GMAC

Append neg context (ID = 0x0008) algorithm count & algorithm IDs:

Server selects algorithm, responds:

Negotiate

Algorithm Count Algorithm Id 1 Algorithm Id 2

2 Byte 2 Byte 2 Byte

0x0001 Selected Algorithm ID

2 Byte

Historical: enabling sign/encrypt on SMB Direct Disabled RDMA direct placement

Tanked performance, worse than TCP!

Hard to diagnose

Irritates a valuable customer persona: security focused

Now: Separating sign/seal of RDMA payload from SMB message

Not free, but much better

RDMA Signing and Encryption

Perf gain over current packet-based encrypted traffic

Planned design:Encrypt RDMA buffer

Include signature in SMB payload

Improved sign and encrypt in RDMA

Signature and

NonceTransform Descriptor

Signature

Length

Signature

Offset

Nonce

Length

Nonce

Offset

Original Message SizeReserved

1

Reserved

2

Channel

Offset

Channel

Length

Channel

(V1 or V1 Invalidate)

SMB2 HEADER SMB2 REQ WRITE RDMA Descriptor

8B

16B

24B

Questions about security?

Google-derived

Internet-ready

Secure-by-default MitM protection

IETF standardized (someday)

Low latency, low congestion

UDP/443, but H2 and TCP-like

“QUIC” stands for nothing ¯\_(ツ)_/¯

QUIC

SMB over QUIC Demo

Upsides:

Prevents server spoofing via server cert

QUIC connection always protected by TLS encryption

Avoid being blocked by providers – 443, not 445

SMB basically unchanged, QUIC becomes VPN-like

Downsides:

Edge network-centric

Much lower perf than even SMB-encrypted

NTLM likely for SMB

SMB over QUIC upsides/downsides

QUIC connection latency reduction: 0-RTT

SMB over TCP

SMB_COM_NEGOTIATE Request

SMB2_NEGOTIATE Response

DNS Query

DNS response

TCP SYN/ACK

TCP SYN

TCP ACK

DNS: 1 RTT

to Name

Server

TCP: 1

RTT

SMB

Session

Setup

Pre-resolve

TCP Fast Open

SMB over QUIC

QUIC Request / SMB_COM_NEGOTIATE Request

SMB2_NEGOTIATE Response

DNS Query

DNS response

QUIC Reply

QUIC Request

DNS: 1 RTT

to Name

Server

QUIC:

Handshake

Including

TLS

SMB

Session

Setup

Pre-resolve

SMB/QUIC: Components

WSK SMBDTDI QUIC

MRXSMB

MRXSMB20MRXSMB10

RDBSS

Multichannel / Signing / Encryption / Compression

TCP NDK/RDMA

UDP

Multiplexing

TLS

Congestion Control

NICRNIC

WSKSMBD TDIQUIC

TCPNDK/RDMA

UDP

Multiplexing

TLS

Congestion Control

RNICNIC

SRVNET/SRVADMIN

SRV (SMB 1.0) SRV20 (SMB 2.x)

Multichannel / Signing / Encryption / Compression

Local File SystemApplication

QUICK will be another protocol option used side by side with WSK and RDMA

Try WSK/RDMA, sleep 100ms, try QUIC, x10

Usage customizable via registry

NTLM very likely for SMB Looking into alternatives like KDC Proxy, others

No user interfaces or management yet, but ADCS can deploy certificates

Windows implementation details

Questions about QUIC?

Native support for FileNormalizedNameInformation

Directory Caching EnhancementsWindows clients can now cache much larger directories ~ 500K entries.

Will attempt directory queries with 1 MB buffers to reduce round trips and improve performance

Important note to implementers: do not fail when seeing new SMB capabilities, just ignore

Other changes

Thanks!

Don’t forget those surveys :)

© Copyright Microsoft Corporation. All rights reserved.