PS & Arch drafts: status and security issues

I have news to report ...

The IESG has been reviewing the RDDP Problem Statement and Architecture
drafts.  The current draft status can be found in the IETF Draft Tracker at
	https://datatracker.ietf.org/public/pidtracker.cgi
Enter rddp in the WG Acronym: field and hit the SEARCH button.

New versions of both drafts are going to be needed, mostly to deal with
editorial issues, but some security issues have arisen in the Architecture
draft that I'm forwarding so that they can be discussed in the context
of the security draft on the list and in Seoul:

	I see several threat issues.  The first is the tension between
	direct copy and packet authentication.  In many cases, it is not
	possible to authenticate a packet until the entire thing has been
	read.  But here, the data is being copied to a receiving buffer
	directly from the wire, before authentication takes place.  This
	is especially a challenge to a multi-threaded interface --- ATM
	where the cells for some packet are not consecutive, perhaps --
	where you might get interleaving.

The risk here is that if one does placement of fragments and then runs
the (cryptographic) integrity check and the check fails, the application
has a corrupted buffer.  In particular, applications that are coded to a
sockets paradigm can get corrupted memory that was never part of any
successful receive with RDDP - that can't happen with plain sockets.

	More generally, authorization for access to storage has to be
	dependent on the connection as well as the steering tag.  Otherwise,
	you introduce new vulnerabilities.  This is especially problematic
	given that receive buffers may (according to the document) be used
	for data from a different socket.

Probably just needs some clarifying text, as I believe this was always
intended.

	Aside: I think that many of these issues, as well as the multiple
	receiver problem (and I do not accept the argument that requiring
	many different clients to use the same address is in any way
	comparable to any existing problem in that space), would go away
	if the steering tag sent over the wire to the receiver were not
	just opaque, but by intent a random 64- or 128-bit tag to a local
	buffer descriptor.  That permits easy local revocation of
	capabilities, as well as a defense against remote contamination
	attempts if the value were communicated previously over an
	encrypted channel.

Also, if the STag values generated by an implementation are hard to
predict, traffic injection by an adversary becomes more difficult.

	The use of TLS (as discussed briefly in the security considerations)
	or any other protocol that provides authentication will not fit well
	into the proposed architecture.  The integrity check cannot be
performed
	until the entire packet (or record in the case of TLS) is available
in
	memory.  So, the data must be copied from the I/O interface to
memory,
	which may involve some reassembly, before the integrity check can be
	performed. This issue should be discussed in the security
considerations.

This is the same issue as the first one, and suitable discussion should
suffice.  The bigger mismatch between TLS and RDDP is that TLS wants to
run in-order whereas RDDP wants to enable out-of-order placement.  The
combination could require a significant amount of data to be placed
before TLS can be run over it to determine that it's all junk.

NOTE: While it's ok to start working on revisions to the architecture
and problem statement drafts, this set of IESG comments is NOT COMPLETE.
When I have a complete set of comments available, I'll communicate the
comments and guidance on what to do about them to the draft authors.
Anything with technical impact will be cc:'d to the list.

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