RE: IPsec and RDDP as a transport

[email protected] said:
>> [email protected] said:
>> >> If one shot STags would have been an acceptable solution,
>> >> why wouldn't making one shot STags a "MUST implement"
>> >> be adequate?
>> >
>> > Because that would allow long-lived STags without requiring
>> > the countermeasures for the security exposures they create.
>> >
>> An existing TCP or SCTP application is not required to
>> use IPsec, even if it is present.
>
> This continues to confuse "MUST implement" with "MUST use".
> The usual IETF requirement is "MUST implement" so that an
> administrator can decide whether the network environment
> contains security threats that justify use of security
> measures such as IPsec.  The administrator is free not to
> use IPsec, but it is better to "have and not need" than to
> "need and not have" - the requirement that there be
> mandatory-to-implement security avoids the latter.
>

With all due respect, the confusion is over what is required
and why.

You seem to be working under the assumption that the IESG
had mandated that DDP headers be protected from spoofing,
either by IPsec or by RDDP itself.

That would only be true if the DDP header posed a new
security risk, one not faced by an equivalent LLP-only
application.

I do not believe that this analysis is shared by the WG.
I certainly do not accept it.

A DDP Header has no magic access to user memory. Just as
any above-transport-header, it only has access to user
memory to the extent authorized by the ULP.

I do not believe that you, or anyone else, has disputed
that assertion.

Any application that accepts delivered payload without
*some* form of authentication (whether transport or
application layer) is at risk from any attacker that
can spoof IP packets.

And therefore a wise application designer places their
own authentication in when forged packets may pose a
security vulnerability (which is not always the case)
and there is no transport level authentication service
in use (or available).

But whether or not something is wise for an application
developer is not the issue. The question is whether RDDP
creates a *new* security vulnerability that would not have
existed for a non-RDDP version of the same application.

Basically, if a TCP or SCTP application has the option
of being reckless with its own security, an RDDP application
must have the same right. An RDDP-specific security requirement
can only be justified by an RDDP-specific security vulnerability.

The only identified RDDP-specific security vulnerability is
minor -- namely that the local interface *might* not make
it totally clear to the ULP what exposure it has created.
Default use of persistent STags could indeed lead to such
confusion by a developer new to RDMA.

But I do not accept that a ULP designer that is *deliberately*
using persistent STags has no concept of what they have
exposed. If an application developer has *deliberately*
used a persistent STag, then they are aware of the
persistence and therefore is no new security vulnerability.

The vulnerability is *not* in the RDDP headers, but in the
potential *misunderstanding* of the duration of STag exposure
by developers new to RDMA.

Therefore the solution proposed is *not* to secure the RDDP
headers, but to correct the potential misunderstanding on
the duration of STag exposure.

I believe that requiring a one-shot STag capability is
sufficient, and perhaps that use of persistent STags
MUST NOT be enabled as a default.

The security problem here is strictly within the local
interface. The solution can also be found there, without
driving up the cost of RNICs or disrupting current
development efforts.

Is there anyone in the WG who would argue that the
protocol itself creates a security vulnerability?




--
Caitlin Bestler
http://asomi.com/