Aside from cautioning about the use of the word "consensus"
("rough consensus" should only be called by the WG Chair
for legal and procedural reasons), this was a very helpful
email message in summarizing the current state of things
and proposing what to do next
Specifically, I would strongly encourage work on:
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.
The result would need to be phrased in terms of requirements/
restrictions on the functional interface and behavior presented
to ULPs. This has been done before, as the IPsec security
"databases" (SPD and SAD in RFC 2401) are examples. I would
hope the result can be posted to the list, as the deadline for
new drafts is coming up quickly. While the verbs draft could
be useful as an example to work on, the eventual requirements
will need to go into the DDP, RDMAP, and/or security drafts.
I think this work is a good idea *even if* we ultimately decide
that IPsec is mandatory-to-implement. This is because (IIRC,
as Dwight pointed out) IPsec can't stop a malicious client
who is able authenticate, and RDDP is potentially applicable to
protocols that need to allow sufficiently large populations
of clients to authenticate (e.g., NFSv4, HTTP) that authentication
material can be expected to be obtainable by a motivated attacker.
To see a worked example of this in a different context, Google
for "exploder control" and notice that this control was
cryptographically signed ...
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[email protected] Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: Caitlin Bestler [mailto:[email protected]]
> Sent: Monday, June 28, 2004 11:49 AM
> To: RDDP
> Cc: David Black; Jim Pinkerton
> Subject: Re: [rddp] 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.
>
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.