RDMAP/DDP Security Draft

draft-ietf-rddp-security-01.txt

Jim Pinkerton, Ellen Deleganes, Sara Bitan

Agenda

• What’s new in this version

• What’s still to be done

Status of Security Draft Review

• Document outline/approach appears to be stable

• Major update/clarifications to text to resolve issues from reflector and private feedback– All feedback from last two IETF sessions done

• Possibly only minor work left– see end of talk for outstanding issues

Major Changes

• Revision history in Section 2.2, pdf version has change bars

• Section on Security Services for RDDP– Currently states SHOULD implement, where

SHOULDs are derived from iSCSI security draft• Moved “Trust Models” to an appendix and

removed all reference to them in the document (including “partial trust”).

• Krause’s comments• Changed “connection” to “Stream” (one or two

places were missed – but in some cases it could be both (i.e. connection setup issues).

New Concepts

• Partial Mutual Trust – from reflector discussion, latest proposal is:

A collection of RDMAP/DDP Streams are willing to assume that the local and remote end points of Streams from the collection will not perform malicious attacks against any of the Streams in the collection.

• Finer granularity interface to RNIC– Added discussion on Send Queue, Receive Queue,

Completion Queue, Asynchronous Event Queue– Collapsed “Request Proxy Interface” into

”Application Control Interface”• Defined semantics for Privileged vs. Non-Privileged

application use of the “Application Control Interface”

New Concepts

• Resource sharing as a first-tier concept (based on feedback) - Added/modified sections to cover security threats for:– Shared Receive Buffers– Shared Completion Queue– RDMA Read Request Queue– Shared STags (and remote invalidate)

• 6 pages on “Security Services for RDDP”– Currently states “SHOULD” however RDDP is just a

transport. But security services should be tailored to the application?

• Change this to section SHOULDs to “If IPSec is implemented, then , then XYZ is RECOMMENDED...”?

New Attacks in Specification

• Spoofing Attacks– Impersonation– Stream Hijacking– Man in the middle attack (rename only)– Unintended sharing of STags

• Information disclosure– Network based eavesdropping

Outstanding Issues

• Section 8: Security Section:– Reflector feedback on SSL limitations– Guidance for application protocols (like NFS) which implement

security• Section 9 – do we copy what is in IPS security draft? • Should Appendix A: “Implementing Client/Server

Protocols” stay or go?– Intent was to take generic statements in the spec and make

specific comments in the context of Client/Server communications

– Intended to provide no new requirements – just summarize existing ones from a Client/Server perspective

– Concern is that we end up with some duplicated text from the body of the spec.

– If section stays, it needs some cleanup

Outstanding Issues

• Summary Section – What is it supposed to summarize?– Application behavior focused - Attack Name by Attack Type,

application behavior to enable attack (e.g. shared resources, mutual partial trust) by data transfer type used by application (Sends, RDMA Write, RDMA Read)?

– Countermeasure focus - Attack Name by Attack Type, and countermeasure(s) used for attack

• PD, E2E Auth, Limit Scope, Resource Manager– Guidance would be appreciated – but preferably don’t

choose both ;-)• Draft status – informational or proposed standard?

• Anything else??

Support Slides

Functional Component Model

PrivilegedResourceManager

PrivilegedApplication

Non-PrivilegedApplication

RNIC Engine firmware

Admin

PrivilegedControlInterface

PrivilegedData Interface

Non-PrivilegedDataInterface

Application Control Interface

RNICInterface (RI)

Internet

Functional Components

• Privileged application– Assumed to not intentionally attack the system, but

may be greedy for resources

• Non-privileged application– Desire to provide benefits of RDMAP/DDP without

introducing additional security risk– Not trusted, granted only a subset of the capabilities

granted to a privileged application

• Privileged Resource Manager– Controls allocation of “scarce” resources– Implements policies to detect and prevent DoS

attacks

The RI in More Detail

RI

SendQueue

ReceiveQueue

CompletionQueue

AsyncEvent

Queue

Resources: Page Translation Table, STag Table, Connection

Context Memory

Host

Network

RDMARead

RequestQueue

Threats and Attack Classes• Spoofing

– Connection hijacking– Unauthorized STag use

• Tampering– Unauthorized modification of remote buffers

• Information Disclosure– Unauthorized read access to remote buffers

• Denial of Service– Consumption of “precious” resources

• Elevation of Privilege– Loading FW onto the RNIC = primary threat

Tampering

• Remote Peer attempts to tamper with buffers on a Local Peer– Attempt to write outside of the buffer bounds– Modify buffer contents after indicating buffer

contents are ready for use– Using multiple STags to access the same

buffer

Information Disclosure

• Remote peer attempts to improperly read information in buffers on a Local Peer– Use of RDMA Read to access stale data– Accessing buffer after transfer is over– Accessing unintended data through use of a

valid STag– Using multiple STags to access the same

buffer

Denial of Service

• Resource consumption – Receive data buffers when pool is shared– Completion Queue entries– RDMA Read Request Queue– Untagged receive buffers

• Remote invalidation of an STag across multiple connections

Tools for Counter Measures

• Protection Domain• End-to-end authentication• Limiting scope of:

– STag• Number of connections, amount of buffer advertised, time the

buffer is advertised, randomly use the namespace

– Buffer access rights• Write-only, Read-only, Write/Read

– Completion Queue• One or more connections

– Error generation/propagation

• Resource manager

Tools for Counter Measures

• Protection Domain• End-to-end authentication• Limiting scope of:

– STag• Number of connections, amount of buffer advertised, time the

buffer is advertised, randomly use the namespace

– Buffer access rights• Write-only, Read-only, Write/Read

– Completion Queue• One or more connections

– Error generation/propagation

• Resource manager

Counter Measures

• Protection Domain (PD)– Data buffers associated with an STag can be

accessed only through connections in the same PD– Limit CQ access to connections in the same PD

• Limit STag scope – Limit SdTag usage to a single connection, or

connections in the same PD– Limit the time the STag is valid by invalidating STag

when data transfer is over– Limit the memory the STag can access by setting

base and bounds to just the intended buffers

Counter Measures

• Set appropriate buffer access rights– Enable only the rights needed (read only, write only or

read/write)– Local peer only access for buffers that do not require

remote access

• Limit scope of error propagation/generation– Limit generation of error events to prevent event

queue overflow

• Resource Manager– Put allocation of scarce resource under control of a

Resource Manager

Attacks & Countermeasures

Threat/Attack Class PDE2E auth

Limit scopeResource ManagerSTag Buffer

AccessCQ Error

SpoofingConnection hijacking

Unauthorized STag use

TamperingUnauthorized data modification

Information Disclosure

Unauthorized data access

Denial of ServiceConsumption of resources

Elevation of PrivilegeLoad FW on RNIC

(Or not allow this feature)

Combinations of TrustLocal ResourceSharing

Local Trust?

Remote Trust?

Name Example

Application

N N N NS-NT

RDDP/DDP client/server Networking

N N Y NS-RT

Authenticated Remote Peer

N Y N Kernel client

N Y Y Similar to S-T

Y N N S-NT Typical Networking

Y N Y ??

Y Y N S-LT Storage target

Y Y Y S-T MPI

Dimensions of Partial Trust

• Primarily a tool to educate the non-IETF RDMA community on the risks of traditional RDMA (local and remote trust)

• Within IETF the assumption is generally no remote trust, no local trust– Thus dimensions of trust could be simplified to

just a local resource sharing issue• i.e. Are local resources shared between streams?

• Should we remove dimensions of trust?