Draft-ietf-rddp-security-02 Summary of outstanding issues August 4, 2004 Jim Pinkerton

Moving to Standards Track Current draft: –34 RECOMMENDED clauses in document. –8 MUST clauses in document Revision (posted after this IETF) divides all into MUST/SHOULD/RECOMMENDED –Protocol or RNIC Requirements Buffer Overrun - RDMA Write or Read Response Controlling Access to PTT & STag Mapping RNIC Resource Consumption Multiple Streams Sharing Receive Buffers - MUST Local Peer Attacking a Shared CQ Remote Peer Attacking a Shared CQ Attacking the RDMA Read Request Queue Exercise of non-optimal code paths - RECOMMENDED 7.6 Elevation of Privilege –Application Requirements Using an STag on a Different Stream - MUST Modifying a Buffer After Indication – SHOULD Using RDMA Read to Access Stale Data – SHOULD Accessing a Buffer After the Transfer Accessing Unintended Data With a Valid STag RDMA Read into an RDMA Write Buffer Using Multiple STags to Access One Buffer Local Peer Attacking a Shared CQ Remote Invalidate an STag Shared on Multiple Streams Recommendation: Publish updated draft after this meeting and have con-call with any interested parties to quickly iterate on MUST/SHOULD/etc.

IPSec – Required or Optional? For Optional –Significant hardware complexity if in RNIC –Question of how widely it will be enabled – wasted effort? For Required –Some attacks can only be mitigated with IPSec –Preserves wide deployment options “Bump in the wire” approach eliminates IPSec as an RNIC requirement Recommendation: IPSec is Required - Remove IPSec requirements section and make portions of IPS security RFC normative. But how to do this? –Required sections of ips-security Section 2.3 Security Protocol requirements (ESP, transforms, IKE) Section 5 Security Considerations –Not Required – SRP, SLPv2, iSNS, CHAP, etc. –Questions: Section Non-graceful iSCSI teardown All normative references in iSCSI-security are not appropriate

Abortive termination on an error Current protocol drafts drop connection if bad STag, etc received For: –Simpler error handling –Because must correctly guess the TCP sequence number, it’s easier to just send a TCP RST, rather than RDDP headers. Thus solving at RDDP layer does not remove connection teardown attack Against: –Prefer more robust protocol in face of errors Proposal: No change. Attack documented as man-in-the-middle attack, mitigation is IPSec

Should STags be random? For: –Makes it harder for attacker to guess (man-in-middle attack) Against: –If you can guess the TCP parameters, you can truncate the data stream with a TCP RST segment. Thus no significant security advantage to making it random. –Hw implementations strongly prefer linear lookup tables vs CAMs Recommendation: No Change.

Shared S-RQ Attacks Consensus from reflector: –“The proposed requirement is that the Privileged Resource Manager contain code sufficient so that a non-RDDP application can be converted to an RDDP application without enabling a denial of service attack that disconnects innocent clients or having to write inter-client receive resource protection code. This is a "MUST implement" requirement, so that the functionality is available to any RDDP application; applications MAY use this protection, but are not required to do so.” Proposed text: –“If an RNIC Engine provides the ability to share receive buffers across multiple Streams, the combination of the RNIC Engine and Privileged Resource Manager MUST be able to detect if the Remote Peer is attempting to consume more than its fair share of resources so that the Local Peer can apply countermeasures to detect and prevent the attack.”

One-Shot STags Attack defined in Modifying a Buffer After Indication –Concern is requirement is on ULP, but what if ULP does not implement it correctly? For one-shot STags –Reduces implementation requirements on ULP Against one-shot STags –How does RNIC know when buffer is done to invalidate STag? No protocol semantic to enable this. –Some applications strongly want multi-shot STags High Performance Computing Double buffered graphics engine –Already many ULP requirements for security (about half of MUSTs) Recommendation: ???

Current text in security draft “The Local Peer can protect itself from this type of attack by revoking remote access when the original data transfer has completed and before it validates the contents of the buffer. The Local Peer can either do this by explicitly revoking remote access rights for the STag when the Remote Peer indicates the operation has completed, or by checking to make sure the Remote Peer Invalidated the STag through the RDMAP Invalidate capability, and if it did not, the Local Peer then explicitly revokes the STag remote access rights. The Local Peer SHOULD follow the above procedure to protect the buffer before it validates the contents of the buffer (or uses the buffer in any way).”

TBD’s in Document Issue: Guidance for application protocols like NFS which implement security Finish Summary table of Attacks/Trust Models Finish incorporating Tom Talpey’s comments posted to reflector