Re: Long-lived Stags: Why?

On Jun 10, 2004, at 3:45 PM, [email protected] wrote:

> John,
>  
> "Single shot" automatic invalidation of STags wouldn't break other 
> things in addition
> to breaking apps written for Infiniband. For inster it would break 
> iSER and modifying
> iSER to allow it would lead to very inefficient undesireable operation 
> characterists.
> One needs to be able to have one side set up a large buffer for a 
> transfer and allow
> the other side to use smaller buffers to handle that transaction a 
> piece at a time as
> happens when a SCSI initiator sets up a buffer for a large Read and 
> the SCSI target
> uses multiple RDMA Writes to transfer the data.
>

I believe some clarifications are in order.

The question under discussion is whether RDDP creates new security 
vulnerabilities
that would not be be faced by an equivalent TCP/SCTP application.

The vulnerability identified is that a local interface may make it easy 
for the
ULP to leave a tagged buffer "open" at the RDDP layer when it was 
logically closed
according to the Upper Layer Protocol.

I have heard no disagreement with the contention that an application 
following
the guidance in the Security draft would have a problem. That is, the 
tools to
prevent this mismatch are already fully described, and in fact are 
available in
every known local interface.

There is a valid argument that the correct procedures are far from the 
default,
and that local interfaces may actually encourage over-exposing STags by 
requiring
extra steps to precisely tailor the RDDP layer exposure to match the 
logical
exposure.

So, even without any additional steps, it is arguable that RDDP as it 
stands
has presented a set of solutions for any increased vulnerability it may 
create.

Whether or not such an argument is fully defensible is probably not 
relevant.
I sense no clamoring for taking the most extreme position to the IESG, 
and
instead a consensus that *something* should be done so that 
applications that
simply use the STag associated with a Memory Region are not left 
exposed to
attacks by forged packets.

Two different strategies have been discussed to address this 
vulnerability:

a) blocking all unauthenticated DDP segments. Theoretically this could 
be
    done at the RDDP layer, at the TCP or SCTP layer, or at the IP layer.
    Because of the need to facilitate out-of-order handling, to leverage
    existing designs, and to avoid redesigning DDP packet handling code
    (and/or gates) that already exist, it is clear that the only viable
    solution to authenticating DDP segments is to authenticate the IP
    datagrams that carry them: which implies IPsec.

    If packet authentication is the selected solution, I believe it is
    clear that the preferred solution would not only be IPsec, but the
    exact same rules for usage of IPsec that apply to iSCSI.

b) The alternate, more minimal, approach is to eliminate the gap
    between the ULP's concept of when a buffer is writable and what
    has been communicated to RDDP using the local interface.

    One usage of the term "one shot" STag is a proposal to eliminate
    the potential mismatch by limiting the flexibility of STags.
    Many people have objected to this approach.

    But many of those objections have seemingly assumed that the
    choice was between requiring IPsec and crippling the local
    interface.

    I disagree. Enhancing the local interface can also eliminate
    the gap between ULP expectations and actual RDDP exposure.
    Doing so will result in more robust implementations, and will
    not result in the incremental per-unit cost of an IPsec solution.
    Keep in mind that most of the opinions expressed on this topic
    have agreed that for the vast majority of deployed RNICs, the
    IPsec functionality will *not* provide any additional value.
    So requiring IPsec would either impose a "compliance tax", or
    encourage non-compliant deployments. Once one IETF requirement
    has been ignored, it becomes easier to ignore others. Having
    decided that their RNIC won't support IPsec, will a manufacturer
    also be tempted to omit support for unaligned TCP segments?

    Enhancing the local interface would ensure that persistent
    STags were only used by applications that made a deliberate
    decision to do so. Typically this would be because they already
    had their own solutions in place, as is the case with iSER.

	Enhancing the local interface imposes no penalty on those
    applications that have already solved the exposure problem
    on their own.

That is why I believe these are the only two acceptable solutions.
The enhanced local interface can be implemented on top of existing
verbs, and IPsec can be inserted under an existing solution. All
other solutions break applications and/or break implementations.


>   
> In iSER we did put in a specific requirement that iSER check that the 
> Send
> carrying the Status for a command also invalidated the STag for that 
> command
> and doing the invalidation if the Send didn't.
>  
> It would probably be appropriate to put a SHOULD statement into RDMAP 
> and/or DDP
> about the ULP ensuring that an STag was invalidated for remote access 
> before it
> tells the application that the data is in the buffer. This would say 
> that other
> ULP's should do something similar to what we put into iSER. Given that 
> "single shot"
> would be undesireable, there is no way for DDP or RDMAP to enforce the 
> invalidation
> because they don't know when the ULP operation has been completed. The 
> requirement
> for ULPs should be stated. If one can put a MUST on a ULP, then it 
> could be a MUST.
>  
>

That is close to the first position: the Security Draft told you not to 
do that.
Changing it from a "please don't" to a "MUST NOT", when run-time 
enforcement is
impossible, isn't likely to be very persuasive to the IESG.

Stating that the local interface MUST NOT make a default out of insecure
practices, however, is enforceable and it is a requirement at the 
correct layer.

I see no conflict in preparing both solutions. The correct procedure is 
to identify
the *minimum* requirement that will address the problem. Clearly the 
local interface
enhancement would be the more minimal of the two solutions. However, if 
the IESG
does not accept our argument that it is adequate, then we would still 
have a
more stringent solution (IPsec) which would then be the most minimal.