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

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

• Jim Pinkerton

2
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
• 7.3.1 Buffer Overrun - RDMA Write or Read
  Response
• 7.4.8 Controlling Access to PTT STag Mapping
• 7.5.1 RNIC Resource Consumption
• 7.5.2.1 Multiple Streams Sharing Receive Buffers
  - MUST
• 7.5.2.2 Local Peer Attacking a Shared CQ
• 7.5.2.3 Remote Peer Attacking a Shared CQ
• 7.5.2.4 Attacking the RDMA Read Request Queue
• 7.5.4 Exercise of non-optimal code paths -
  RECOMMENDED
• 7.6 Elevation of Privilege
• Application Requirements
• 7.2.4 Using an STag on a Different Stream - MUST
• 7.3.2 Modifying a Buffer After Indication
  SHOULD
• 7.4.2 Using RDMA Read to Access Stale Data
  SHOULD
• 7.4.3 Accessing a Buffer After the Transfer

3
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 3.5 - Non-graceful iSCSI teardown
• All normative references in iSCSI-security are
  not appropriate

4
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, its 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

5
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.

6
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.

7
One-Shot STags

• Attack defined in 7.3.2 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 ???

8
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).

9
TBDs in Document

• Issue Guidance for application protocols like
  NFS which implement security
• Finish Summary table of Attacks/Trust Models
• Finish incorporating Tom Talpeys comments posted
  to reflector