Subject: [rddp] Re: security-draft : completions and ULP pacing

From: Caitlin Bestler <[email-masked]>
Date: Tue, 24 Jun 2003 19:55:38 -0500

>7.1.4  Limiting the Scope of the Completion Queue 
>
> Completions associated with sending and receiving data, or
> setting up buffers for sending and receiving data, could be
> accumulated in a shared Completion Queue for a group of
> RDMAP/DDP Streams, or a specific RDMAP/DDP Stream could have a
> dedicated Completion Queue. Limiting Completion Queue
> association to one, or a small number of RDMAP/DDP Streams can
> prevent several forms of Denial of Service attacks.

There is an assumption implicit in this section that I believe
is unwise. At the minimum, a vunerability that is a defect of
one proposed local interface is being presented as a general
security concern.

As noted previously, a DDP stream relies upon ULP flow control
more so than does a non-RDMA stream. Normally the connection/
association is flow controlled based upon LLP congestion control
and LLP buffer capacity advertising.

A fully optimized RDMA-enabled connection/association makes
no use of LLP buffering. Therefore, reducing transport flow
control to congestion control only.

The assumption in the RDMA Architectural model is that the
data sink must enable each receive. The presumption is that
the Data Sink is able to communicate credits, most probably
in its untagged messages, after enabling the matching number
of receives.

One of the strengths of the iWARP protocol suite is that by
leaving credit management to the ULP, the ULP can easily
dynamically adjust the credit level. Indeed, it can be an
automatic feedback associated with processing. As the load
in processing requests increases, new credits will be issued
more slowly. The following loop is an example:

    post_receive()
    while (get_completion(recv_completion_queue))
        process_message()
        post_receive()
        send_response()
    
The longer that "process_message" takes, the slower the peer
will receive its new credit. Note that the new receive is authorized
just before sending the response.

The key is that the ULP explicitly authorizes the reception of each
untagged message. I will point out that there were no objections to
this rule in the architecture draft. The only objection was the one
that I raised, which stated that the local interface MAY allow the
ULP to authorize reception of an untagged message without supplying
a buffer -- but that the ULP MUST still authorize each receive.

This is a rule that I believe the local interface SHOULD/MUST enforce.

The local interface can allow a Receive Queue to be fed from a buffer
pool. When dealing with a large number of clients this may be a wise
policy decision. If this is combined with authorizing receptions on a
per stream basis there is far less of a security concern than if the
the presence of a buffer implies authorization.

Under the latter scenario, a peer that is not in compliance with its
ULP protocol rules will quickly exceed its alloted number of receives.
The DDP stream would then be terminated.

If instead it is the receive queues that are shared, one over-eager
peer can take more than its fair share of buffers. Even without
exhausting the buffer pool, it could thereby generate too many
completions.

If the each "receive must be enabled for an endpoint" rule is
followed, then the maximum size of any completion queue can be
easily determined. Given the relatively small size of completions,
there would be no reason to favor multiple completion queues over
a single completion queue. That should be left to the designer
of the local ULP implementation.

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp