| Newsgroups |
gmane.ietf.rddp |
| Message-ID |
<[email protected]> |
Having seen no objection since the posting of the draft
minutes, the RDDP WG has rough consensus on all the
issues discussed in San Diego (see below) except for
the three issues handled in separate email threads:
- MPA CRC check requirements
- Mandatory Security (IPsec)
- Discouraging use of network-writable data
Here are the final San Diego minutes that I just sent
to the secretariat:
RDDP WG Minutes - FINAL
60th IETF Meeting, San Diego
Wednesday, August 4, 0900-1130
------------------------------
Many thanks to Hemal Shah for taking the raw minutes. Letter
in square brackets (e.g., [A]) is first letter in file name
containing slides for that portion of the meeting.
-- Agenda Bashing and Administrivia - David Black, WG Chair [A]
- Blue Sheets
- NOTE WELL
The agenda was bashed prior to the meeting to include the MPA
CRC issue that came up in the IPS meeting on Monday.
-- Status of drafts - David Black, WG Chair [no slides]
Problem statement draft needs some minor revisions, and then
should be ready for IESG approval.
Architecture draft is held up by a security issue related to
determining the mandatory to implement security mechanism(s).
RDMAP draft was sent in for posting but didn't make it.
Both it and the DDP draft will have boilerplate and
security updates applied and be resubmitted.
Applicability statement and SCTP mapping are missing from the
Internet-Draft servers. They will be resubmitted with
updated boilerplate.
Broadcom needs to update their IPR notice to comply with RFC 3668
soon in order to avoid it causing delays.
MPA draft status (informational vs. standards track) will be
determined by WG chair in consultation with ADs after
WG last call. WG chair understands that WG would prefer
it to be standards track.
-- MPA CRC issue (David Black, WG Chair, slide extracted from
Mike Ko's iSER presentation to the IPS WG on Monday) [B]
iSER is a protocol that uses MPA (RDDP mapping to TCP) for iSCSI.
The iSER draft authors have found MPA's current CRC requirements
text to be insufficient for iSER usage of MPA, and hence currently
impose stronger requirements. iSER requires that RDDP provide at
least CRC32-class integrity, but the current MPA draft text allows
CRC32C to be disabled in situations where that would not be the
result.
The RDDP WG's rough consensus has been that ULPs can assume at least
CRC-class integrity from RDDP. Hence the sense of the room is that
the MPA draft text needs to be tightened to do this and remove the
need for iSER to add requirements to MPA.
ACTION: MPA draft authors to propose specific new text on reflector.
-- Security Draft (draft-ietf-rddp-security-02.txt) - Jim Pinkerton [C]
Two Important issues:
- Mandatory to implement security requirements.
- How to strongly discourage use of data while write-accessible from
network.
-02 draft is not significantly different from -01, mostly a boilerplate
update
There are 34 RECOMMENDED clauses and 8 MUSTs in the current draft split
among RNIC protocol implementation and application implementation
requirements. It's not clear that the "RECOMMENDED"s and "MUST"s are
all correct. Jim will post a new security draft to the reflector and
schedule a conference call to provide a recommendation to the WG on
which requirement level should be used for which clause. See RFC 2119
for the definitions of MUST and RECOMMENDED. SHOULD is a synonym
for RECOMMENDED, but lower-case should has it's ordinary meaning which
is weaker than an RFC 2119 SHOULD.
--> Important Security Issue #1: IPSec - required or optional?
A lengthy discussion ensued on this topic. Important points:
- For optional: IPsec can involve significant hardware complexity.
- For mandatory: Some attacks can only be mitigated by IPsec (WG has
little interest in designing its own security mechanism), and
they will be of concern in some deployment environments.
IP Storage (RFC 3723) enables IPsec to be implemented separately from
the protected protocol - when this is done correctly for end-to-end
security, the resulting architecture is "bump in the stack (BITS)" as
opposed to "bump in the wire (BITW)" - see RFC 2401 for more on this.
The security draft needs to be clear that the security requirements
are intended to enable end-to-end security.
Making IPsec mandatory does *not* force it to be implemented in
hardware. IETF RFCs impose functional requirements for security,
not performance, so a potentially slow software implementation can
be used to meet those requirements.
Since iSER is using RDDP with iSCSI, reusing the IP Storage IPsec
requirements (RFC 3723) for iSCSI will avoid adding complexity in
that situation, as the iSCSI requirements will not be removed by
iSER.
The data rates expected for some uses of RDDP require that a key
exchange protocol be mandated (i.e., only manual keying is
unacceptable).
The issue at hand has two parts:
(1) Should IPsec be required or optional?
Sense of room: it should be required, but without any restrictions
on how it is implemented.
(2) Should the IPsec requirements be based on the existing RFCs
(e.g., use IKEv1) or the new drafts coming from the ipsec WG (e.g.,
use IKEv2).
Sense of room: Base them on the existing RFCs by referencing the
IP Storage IPsec requirements in RFC 3723.
Two UPDATEs from after the meeting:
- Making IPsec required clears the IESG security issue blocking the
rddp architecture draft.
- Based on the saag meeting on Thursday, the IETF Security Area has
no problem with mandating use of IKEv1 in a new RFC, even
though IKEv2 will be an RFC in the near future.
--> Additional issues from Jim's slides.
- Abortive termination on error
Current protocol drafts drop connection if bad STag is received
Proposal: No change (ok with room)
- Should STags be random?
Small security advantage to doing so, IPsec is the real solution.
HW implementations prefer to control tags for linear lookup
Recommendation: No change (ok with room).
UPDATE: Also ok with Security AD whose DISCUSS on this issue is blocking
the rddp architecture draft at the IESG - MUST implement IPsec is
more than sufficient.
- Shared Receive Queue attacks
This issue involved some detailed text editing - do it on the
reflector.
--> Important Security Issue #2: How to strongly discourage allowing
network write access to data in use by a ULP or application.
This includes slides from John Carrier [D] (many thanks to John
for preparing these detailed slides on *very* short notice).
This issue has misleadingly been called "One-shot STags".
Issue is around having data sink buffer contents getting changed before
the buffer is invalidated. If protocol or application logic depends on
the contents not changing, this may open up attacks on the protocol.
IPsec doesn't help because one has to protect against a less than fully
trusted peer who can authenticate and use IPsec if required.
One-shot STags are a "heavy hammer" approach to this problem - completion
of an RDMA write always invalidates the associated STag. The problem is
that this is too heavy - both NFS/RDMA and iSER need multi-shot STags for
resource management and optimization reasons, and cannot live with a
restriction that all STags be single-shot. One consequence is that the
receiver MUST check for STag invalidation before using the data, even
when Send with Invalidate was used (have to make sure right STag was
invalidated).
There are a couple of additional possibilities:
a) Receive and Invalidate. If one knows which untagged receive buffer
will be used for the ULP operation that signals completion of the
data transfer, one can pre-mark that receive buffer to force
invalidation of the STag when the transfer completes.
Problem: This won't work when data transfers can complete in
non-deterministic order, because the exact sequence of completion
has to be known in advance. Both iSCSI and NFS exhibit this
non-deterministic completion order behavior.
Sense of room: Not worth pursuing further due to limited applicability.
b) RDMA Write & Invalidate: Define an RDMA Write primitive that also
invalidates the STag that it uses. Having every RDMA Write invalidate
the associated STag is an implementation of One-shot STags, and hence
won't work. Defining RDMA Writes that do and don't invalidate the
appropriate STag still requires a receiver check for invalidation and
hence provides no leverage.
Sense of room: Not worth pursuing.
Conclusion of issue: Need to make sure security and protocol drafts
contain stiff warnings about the need for any ULP using RDDP to
invalidate receive STags prior to using data they cover. Architecture
draft will incorporate this warning also. Need to specifically call
attention to situations in which protocol logic path depends on
contents of received buffer.
--> Things to be done to security draft:
- Guidance for application protocols like NFS which implement security,
including informative reference to channel bindings draft
(Nicolas Williams to provide this ref, David Black to send him
email reminding him to provide it. UPDATE: Done.)
- Finish summary table of attacks/trust models
- Finish Tom Talpey's comments posted to the reflector
-- Next steps
- Revise security draft.
- Add appropriate security requirements in DDP, RDMAP, and architecture
draft.
- Good chance to move DDP, RDMAP, and security drafts to WG Last Call by
mid-September.
- WG Last Call on transport mappings drafts (MPA, SCTP mapping) and
applicability statement will be later.
----------------------------------------------------
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
----------------------------------------------------