Subject: RE: [rddp] MPA TCP analysis draft; avoiding confusion on use

From: [email-masked]
Date: Tue, 18 Feb 2003 12:32:32 -0500

Paul,

> I have always been curios why the ADs are placing requirement 3 on MPA.
> Since MPA is now characterized as an adaptation layer for DDP, and as
> such, cannot get turned on unless DDP is turned on, why is it necessary
> to "prove" that MPA/DDP cannot ever get accidentally (or otherwise)
> connected to an inappropriate port/address and (presumably) cause some
> kind of trouble?

MPA proposes to change TCP - see the sender alignment discussion.
If MPA did not propose to change TCP (i.e., all senders could
always use unmodified existing stacks) then (portions of)
your "applications that use TCP" discussion would apply ...

> Has this kind of requirement been applied to other applications that use
> TCP?  For example, has it been shown that an HTTP client cannot ever
> cause a problem when connecting to some other non-http server or other
> client?  I suspect not.

HTTP, etc. require *no* changes to TCP, hence this issue does not arise.

> Of course it may be that the ADs placed this requirement on MPA when MPA
> was being put forth as a general framing mechanism; depending on how it
> got enabled, it might have been enabled unexpectedly under some
> unsuspecting application.  I never thought that was very likely either,
> but...

If MPA is now only for DDP's usage, the proposition that DDP is a
somehow more important application of TCP that is entitled to make
changes to TCP where essentially no other application has ever been
permitted to do so is a non-starter, leaving SCTP as the only means
of obtaining ULPDU alignment with transmitted segments/chunks.

> Attempting to "fix" this "problem" by adding additional Hello exchanges,
> merely seems to move the problem to "proving" that the Hello messages,
> cannot cause problems themselves, putting us back where we started...

Not exactly.  The Hello exchanges can be designed to be specific
to the connection, etc.  At some point one gets to a "proof" without
needing absolute certainty - e.g., every security protocol in the
world is vulnerable to the (highly improbable) "lucky guess" of
some crucial secret key.  This is an exercise in making that sort
of event sufficiently improbable (and I don't think the levels of
assurance that security protocols get to will be required). 
Compare Figures 4 and 5 in the Elzur draft, and note that at the
very least, some careful design will avoid the DNS "near miss".

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-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 18 Feb 2003 16:19:35 -0600

On 2/18/03, [email-masked] wrote:

>Paul,
>
>> I have always been curios why the ADs are placing
>> requirement 3 on MPA. Since MPA is now characterized as
>> an adaptation layer for DDP, and as such, cannot get
>> turned on unless DDP is turned on, why is it necessary
>> to "prove" that MPA/DDP cannot ever get accidentally (or
>> otherwise) connected to an inappropriate port/address
>> and (presumably) cause some kind of trouble?
>
>MPA proposes to change TCP - see the sender alignment
>discussion. If MPA did not propose to change TCP (i.e.,
>all senders could always use unmodified existing stacks)
>then (portions of) your "applications that use TCP"
>discussion would apply ...
>
True, MPA makes some minor changes for an MPA aware sender.
However, the resulting stream is fully TCP compliant.

Specifically, it is impossible to examine a MPA/TCP stream
and *prove* that it could not have been generated by an
extremely annoying ULP that just wanted the stream to
look like it was an MPA/TCP stream.

That leads to two very important points:

-- Given the flexibility of base TCP for ad hoc ULPs, there
will never be a method to absolutely ensure rapid detection
of cross-ULP mismatches for TCP. Any such method would have
to alter TCP itself.

-- An MPA/TCP stream arriving at the wrong port is no more
likely to be mistakenly accepted than any other TCP stream.
Indeed, the draft does a heroic job of showing that it is
*less* likely.

But ultimately I don't see probability as being truly
relevant here. Even with reduced probability, the bottom
line remains that it is a ULP responsibility to identify
the port it will accept service upon, and what services
will be accepted on a given port, and to somewhat promptly
detect and reject stray connections. Further it should
protect itself from damage from arbitrary peers who have not
been authenticated.

Given that there is no special exposure of the Data Sink's
memory until *after* an STag has been exchanged this
certainly doesn't qualify as a security hole.

I agree with Paul, there is no justification for this to be
documented. The message needs to be clear that no ULP is
going to be dragooned into using DDP or MPA. Hence the
normal procedures for matching ULPs and ports are fully
applicable, as complete and/or as flawed as they are for
all other IP based ULPs.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Michael Krause <[email-masked]>
Date: Tue, 18 Feb 2003 14:52:39 -0800

>applicable, as complete and/or as flawed as they are for

Strongly agree with the above.

Mike