Subject: Fw: [rddp] STag validation semantics

From: "Julian Satran" <[email-masked]>
Date: Fri, 4 Oct 2002 17:52:19 +0300

Renato,

Perhaps the context is not right. But the IB design point is different 
from IP.
And security is not protection. The type of attacks that have to be 
considered in an IP network
are beyond protection.  The whole STag concept is weak if you have to 
secure it and have no way to enforce it.

Perhaps the session is the answer but sharing the same type of security 
over all connections is not painless (even to specify).
But perhaps we should consider all other alternatives. 

If the ULP maintains a connection affinity (as iSCSI does) then limiting 
the scope of an STag to a connection is painless even in face of recovery.
If the ULP needs a wider scope - and the RDMAP has no effective means to 
police that - then it may want to give up the invalidation shortcut - but 
I am afraid that even this will be frowned upon in some quarters.

But I have real trouble understanding where limiting STag to a connection 
will cause pain. Many an implementer may find ways to express within the 
STag a "constant part" (the core-STag) and a "connection salt" and avoid 
the whole issue of securing a session. 

Regards,
Julo 

Renato Recio/Austin/IBM@IBMUS
Sent by: [email-masked]
01/10/02 16:12
 
        To:     [email-masked]
        cc: 
        Subject:        Re: [rddp] STag validation semantics

I agree with Caitlin and wanted to add another point.  In IB,  our view 
was
the ULP could associate the Protection Domain with a process.  For 
example,
the ULP could make the process id = the protection domain.  If the ULP 
does
that, then one process cannot access the resources owned by another
process,  because they are protected by the PD.

Thanks

Renato J Recio
Distinguished Engineer
IBM I/O Architecture and Technology
Tel 512-838-3685, T/L 678-3685

                      Caitlin Bestler   
                      <[email-masked]        To:       [email-masked]     
 
                      i.net>                   cc:   
                      Sent by:                 Subject:  Re: [rddp] STag 
validation semantics 
                      [email-masked]   
                      rg  

                      09/30/2002 08:05   
                      PM  

On 9/30/02, Mukund, Shridhar wrote:

>
>Caitlin,
>
>Isn't it true that a connection can be associated with
>multiple protection domains at the same time?
>
>Are you assuming otherwise? Why?
>

The Protection Domain model I was referring to comes from
InfiniBand. Each QP(connection) is associated with exactly
one Protection Domain. Each R-Key(STag) is also associated
with exactly one Protection Domain. An R-Key with the 'wrong
Protection Domain' for a QP is rejected.

This requires far less NIC-accessible table space, and fewer
cycles, to validate than a generalized validating lookup on
the QP/R-Key combination.

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

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

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 4 Oct 2002 10:48:27 -0500

On 10/4/02, Julian Satran wrote:

> Renato,
>
>Perhaps the context is not right. But the IB design point
>is different from IP. And security is not protection. The
>type of attacks that have to be considered in an IP
>network are beyond protection.  The whole STag concept is
>weak if you have to secure it and have no way to enforce
>it.
>
>Perhaps the session is the answer but sharing the same
>type of security over all connections is not painless
>(even to specify). But perhaps we should consider all
>other alternatives. 
>
>If the ULP maintains a connection affinity (as iSCSI does)
>then limiting the scope of an STag to a connection is
>painless even in face of recovery. If the ULP needs a
>wider scope - and the RDMAP has no effective means to
>police that - then it may want to give up the invalidation
>shortcut - but I am afraid that even this will be frowned
>upon in some quarters.
>

What is wrong with a protection domain affinity? It can be
as finely tailored as the local ULP desires: process,
session or connection. The STag is valid *only* on the
set of connections that the ULP desires.

If some partners in a multi-party session are only trusted
to use certain connections, the ULP can set of the
protection domains on that more limited scope. The ULP is
fully in control. The ULP can even use transport layer
security if they want complete protection.

>But I have real trouble understanding where limiting STag
>to a connection will cause pain. Many an implementer may
>find ways to express within the STag a "constant part"
>(the core-STag) and a "connection salt" and avoid the
>whole issue of securing a session. 
>

Having to place a "connection salt" in the STag doesn't
solve the problem that a different STag is needed for each
connection.

This can lead to complexities such as having to use a
different buffer descriptor for reading and writing the
exact same buffer. This is not a very natural concept to an
application developer. Further, it is not something they
would have to do under IB. The combination would almost
certainly be that requiring the correct STag value for each
connection within a session would result in many errors.

Caitlin Bestler