[rddp] RDDP WG Vienna minutes

[[e-mail]]

RDDP WG minutes - Vienna, Austria, July 2003
--------------------------------------------

Thanks to Tom Talpey for taking the initial minutes.  Letters in [square
brackets]
indicate first letter in name of corresponding presentation in proceedings.

Tuesday, July 15 5-6pm
----------------------

David Black (WG chair) introduces agenda changes, no bashing, agenda
accepted [A]

Review of WG draft intentions and status - see presentation [B]

+ RDDP Applicability statement, Lode Coene [C]

Review of document content - draft considered by authors to be in good
shape,
waiting for comments from WG.

David Black requests that TCP mapping issues (drawbacks of TCP by comparison
to SCTP) be included in the applicability statement.

+ SCTP Mapping draft [D]

On its third revision.

A DDP Stream establishment issue has been identified, can a
protection domain assignment be deferred or no? Needs documentation
at a minimum.

A draft revision under author review concerns single-message
exchange for "private data", compatible with current MPA draft,
but this is part of the open startup issues in the MPA draft.

No others issues are currently identified, speak up now...
New version expected in next few weeks.

+ Shared receive queues vs Shared buffer pool [D]

David Black presented this issue from the mailing list on behalf
of Caitlin Bestler, who was unable to travel to Vienna.

Shared receive queues are proposed in draft-hilland-verbs-00. Their
presence/absence has impact on other drafts:

	Architecture document
		should it define a "post receive"?
	Security issues

The problem: need to underprovision receive buffers, but how to
control per-receive queue quotas?

Two proposals:
	Shared receive queue (draft-hilland)
	Shared buffer pool (email on list)

The proposals are described and a lengthy discussion ensues.

David Black suggests trying the following tack: need to resolve robustness
to
DOS attack on shared buffers. Tag this as the only open portion of this
issue
and look at countermeasures in security draft. Examine offline and continue
this
issue on Thursday.

A question is asked about why this issue is holding up the architecture
draft, which is *not* an interface specification.  David Black answers that
the architecture draft goes into sufficient detail on pseudo-interfaces that
some discussion of resource sharing is necessary there.

+ RDMAP/DDP Security draft - Jim Pinkerton [E]

Presents the new security draft for first time.

Draft is focused on wire protocol issues, in a generic way with out
referencing
verbs, etc.

Sketches components necessary to implement security over RDMA. - privileged
resource
manager, controlling the RNIC itself as well as two classes of application -
priv
and non-priv applications.

Identifies resources to be analyzed (and controlled): connection context,
data buffers,
translation tables, STags, completion queues, plus RDMA Read request queue.

Describes the "dimensions of trust": local resource sharing, local trust and
remote
trust. 

There are 8 combinations of trust, 4 are addressed in the paper. The 4 were
chosen
as most applicable to IETF areas of interest, due to brevity and also lack
of relevant
applications which might fall into the other 4.

Enumerates tools for countermeasures: protection domain, limiting STag
scope, (4 others)

<presentation abbreviated due to end of WG meeting time>

David Black requests that for Thursday's session, protocols should decide
which "trust
bucket" each lands in, determines if bucket is addressed in draft, and if so
are the
issues accurate?

Thursday, July 17, 3:30-5:30pm
------------------------------

+ Architecture draft resolution

ddp_post_receive goes back in
Allow sharing of buffers for untagged receives
Work out how to avoid tacking limit per stream/socket problem in arch
	draft; problem will be addressed in security draft
In ddp draft, ok to not fail immediately on shared overdraw

question from floor - have we addressed the issues raised by VJ
delay-bandwidth
results? Enough buffers to allow the flow to use all available bw?
A (David Black): The fact that RDDP moves control of buffering resources
upwards
	in the protocol stack doesn't change the need to provide
bandwidth-delay
	product quantity of buffering to enable full use of the available
	network bandwidth.  This is an issue for receivers to appropriately
	provision receive buffers.  Consider adding a statement to this
effect
	to the architecture draft.

+ Return to Security document discussion, Jim Pinkerton.

[This meeting time conflicts with SAAG meeting so security experts may not
be
in attendance.]

Current open issues summarized:
- IPSec section is currently a placeholder, and will be filled in
	(Bernard Aboba to help out)
- Also, summary section at end still in progress.
- From reflector, elaborate some issues in "trust model".
- Multiple Protection Domains
- Scope of STags
- Other resources to add to security discussion (async event queue, PD, etc)
- STag disable/enable by non-privileged app.

Question from floor - we need an analysis of issues introduced by RDMA into
	existing protocols, e.g. NFSv4. When transfers are done purely by
RDMA
	they may not be protected by existing security.
A (David Black): This may indeed require additional security coverage such
as
	IPsec which may be enabled by existing CCM NFSv4 proposal.

It as also noted that the integrity protection is present in NFSv4,
RPCSEC_GSS
integrity, can verify that RDMA transfers actually occur as promised, while
IPsec
can be used to enforce the authorizations themselves. Two different issues,
important to keep separate.

Question  - should performance analysis be included in our analysis?
	Especially where IPSec overhead is involved.
A (David Black): First of all, let's complete the security analysis. At that
point,
	the specific performance implications may be worth analyzing. But
not before.

Next major revision of this document should become an official WG draft. No
objections.

+ Status of TCP mapping issues

WG chair summarizes marker issues resolved to date:
	Sender alignment
	Marker usage, intervals, optionality
	CRC use (5+ issues)
		Further discussion to go into applicability draft

Question from floor - have we worked out when it's ok not to use MPA
	CRC yet?  Prefers to have it always present for simplicity.
A (David Black): Rough consensus is for CRC to be optional.  Discussion of
when
	it may be disabled and what ULP designers/implementers should assume
goes
	into the applicability statement draft.

Last(?) CRC Issue - one CRC or two?
	Case for two - faster placement, fast header validation
	Case for one - tractable, simpler, doesn't abuse layering

Statement from floor - there are more reasons to have two CRCs:
	DDP Routers don't have to rebuild data crc
	Don't have to wait for whole segment to begin processing header

Large amount of controversy whether it's valid to rewrite DDP headers.

WG Chair declares that rough consensus exists for one CRC; while there
are advantages to two, they don't outweigh increased complexity.
Further discussion will be on the list.

+ MPA discussion - Paul Culley

Changes to most recent draft recapped:
	optional, receiver-specified markers
	optional, mutually agreed CRC
	MPA streaming mode "key" validation mechanism at connect
	new informational sections

Authors' additional proposals
	no "alignment" of market to TCP sequence #, as alignment would
violate
		layering
	CRC field always present, not filed in or checked when not used -
simplicity
	no private data in MPA (carried only in TCP mode), quiescing stream
required
		at MPA init
	MPA 128-bit start key, carrying a fixed MPA signal + CRC/marker
bits, etc.
	passive/active rules specified
		Question - what happens if both "active"? Needs to be
addressed
		Resolved - Start Key should at a minimum assert Active vs.
Passive.

Discussion of connection startup models - immediate RDMA enabled, RDMA
enabled midstream,
RDMA midstream with private data (blob follows MPA key).  This whole area of
how
to initiate a connection, including private data, is open and needs to go to
list

Chair proposes that this document is ready to go to official WG draft for
TCP
mapping of RDDP (with significant issues to be worked out of course).  No
objections.

Question: Is the MPA draft as informational or standards track?
A (WG Chair) Informational: per ADs from recent rechartering.  Can be
reconsidered
	when draft is complete and ready for publication as an RFC.

Q: Didn't acceptance of Start Key mechanism enable standards track status?
A (WG Chair): No, refusal to accept Start Key mechanism would have resulted
in
	TCP mapping work being removed from RDDP WG charter.

NOTE: WG Chair has subsequently verified w/ADs that standards track status
for
	the TCP mapping (MPA) can be reconsidered when the draft is
complete.
	Among the reasons for this is a strong desire to see exactly what is
	being proposed and understand its effects on TCP before approving
	standards track status.

_______________________________________________
rddp mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rddp