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

At 08:49 AM 6/28/2004, Caitlin Bestler wrote:

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

Agreed.

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

Agreed.


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

Signaled events which are also local interface issues is another avenue. In 
general, I agree that the methods can vary and trying to restrict them is 
not necessarily wise.

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

This would necessitate changes to the verbs document and referencing it for 
developers to understand their local interface requirements and how to deal 
with any security issues for this class of problems at the verbs level.

Mike