Re: Why IPsec is needed for iSCSI but might not beneededfo r RDDP/iWARP

On Jun 28, 2004, at 10:14 AM, [email protected] wrote:

> Jim (and Mike),
>
> My current belief is that this will need discussion in San
> Diego - I'm uncomfortable trying to call rough consensus on
> IPsec requirements on the mailing list based on the traffic
> I've seen, BUT ...
>
> ... the security draft needs to be updated because it's current
> approach to IPsec is not good.  Let's put the IPsec text into
> the next version of that draft and then discuss what we want
> to do and why in San Diego.
>
> The problem with the current security draft text is that it
> (re)profiles IPsec - that should not be necessary at this point,
> instead the draft should do one of the following two things:
> 	- Reference appropriate sections of RFC 3723 (IP Storage
> 		security) to reuse that IPsec profile.
> 	- Reference IKEv2 and associated drafts to use the new
> 		work done there.
> The former approach exactly matches the existing text and
> doesn't pull in an IKEv2 requirement, so that's probably
> preferable.
>
> Thanks,
> --David
>

I think that it is clear that there are at least some
RDMA applications that would benefit from having transport
layer anti-spoofing as an alternative to having to authenticate
the payload themselves after invalidating the STag.

So clearly defining how IPsec would work with RDMA is clearly
beneficial, whether IPsec ends up being a MUST implement or not.

I also believe that there is consensus on the following points:

1) Mandating IPsec implementation is preferable to making any
    changes to RDDP or RDMAP headers.

2) Mandating IPsec implementation is preferable to restricting
    the application model, for example by standardizing the
    usage of tagged buffers in relation to untagged buffers.

3) The nature of the RDDP specific vulnerability is in the
    local interface. Specifically, the common practice for
    RDMA ULPs is to "deliver" a tagged buffer implicitly
    by completing an untagged message. That is the receiver
    of the untagged message understands that a set of previously
    advertised tagged buffers has been delivered, but just as
    the method of advertising is not known to RDDP, neither is
    the method of delivering content through tagged buffers.

    Local interfaces can actually encourage the application
    designer to use one of these "delivered" tagged buffers
    *before* ending the exposure of the buffer to tagged writes.
    In the absence of transport layer authentication, the ULP
    can only authenticate received tagged buffers *after*
    the exposure has been eliminated.

I believe the open issue is whether we can specify a set of
local interface requirements which:

a) will satisfy the IESG that they are sufficiently complete
    and there natural usage simple enough that use of RDMA over
    unsecured transports will create no new security vulnerabilities.

b) are simple enough that they do not require a redesign of
    in-progress hardware. There are simple methods to add IPsec
    functionality *below* the existing iWarp layers, although
    they add variable cost in doing so. But something that can
    be added on may be preferable to a theoretically simpler
    solution that requires rework, especially this far into
    the development process.

I would be interested in hearing if everyone agrees with the
above, and further if they believe the solutions already
described for the local interface are sufficiently simple
in at least the case of a simple receive queue.

If there is consensus that the proposed local interface enhancements
are adequate at least for simple receive queues, we would then have
to proceed with a discussion on how to apply these techniques to
shared receive queues, and exactly what standards apply to shared
receive queues.  I believe the same approach will work for SRQs,
but it is definitely more challenging than for simple endpoints.
But there is no point in doing that work if the WG does not believe
in either assumption A or B above.