Subject: RE: [rddp] STag validation semantics

From: "Julian Satran" <[email-masked]>
Date: Tue, 1 Oct 2002 18:25:55 +0300

The whole discussion is about scope not only exposure. The iSCSI ITT is 
limited to a single command.
Having an STag span connections will be hard to accept because the 
security enclosure has to be as wide as the scope.
One way to make it acceptable would be ask for a coordinated security/STag 
enclosure.

Julo

Renato Recio/Austin/IBM@IBMUS
Sent by: [email-masked]
30/09/02 21:30

        To:     [email-masked]
        cc: 
        Subject:        RE: [rddp] STag validation semantics

Shridhar,

  In terms of security exposure, the STag has a similar exposure as the
iSCSI Initiator Task Tag.  If a ULP is concerned about a rogue endpoint
essentially hijacking a connection and injecting rogue segments into the
fabric (e.g. DDP Segments that target a valid DDP Stream), then the ULP
really needs to use a secure protocol under RDMA/DDP to close the hole.

  However, in some environments, the network used to interconnect the 
nodes
will be physically secure and will not be exposed to such network
break-ins.  In these cases, the ULP would not need to use the secure
protocol.

Thanks,

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

                      "Mukund, Shridhar"   
                      <Shridhar_Mukund@a        To: 
"[email-masked]'" <[email-masked]> 
                      daptec.com>               cc: "[email-masked]'" 
<[email-masked]> 
                      Sent by:                  Subject:  RE: [rddp] STag 
validation semantics 
                      [email-masked]   
                      g  

                      09/30/2002 12:25   
                      PM  

>>STag scope (not only for invalidation) is a serious security concern.
>>The most conservative approach - STag scope is connection or a group
>>of connections - a session, or the even more restrictive iSCSI view -
STag

>>valid for a >>commad might be too restrictive for other applications but
extending
>>it will require carefull scrutiny and will involve some form of
authentication envelope.

>>Julo

From what I understand(about STag and PD), it seems like we should *not*
expose STags on the wire. If an iSCSI/RDMA session chooses IPSec 
protection
on all it's (TCP)connections, it's STag-set should not be visible from
other
unprotected connections even thru' guess work or accident.

Does it make sense to have a level of indirection as follows?
Define BPI(Buffer Parameter Index, kind of like SPI), such that the 
5-tuple
<Source IP Addr,Dest. IP Addr, Source Port, Dest. Port, BPI> points to a
valid
STag only if defined apriori for that connection.

-Shridhar Mukund

_______________________________________________
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: Tue, 1 Oct 2002 11:09:39 -0500

On 10/1/02, Julian Satran wrote:

>The whole discussion is about scope not only exposure. The
>iSCSI ITT is limited to a single command. Having an STag
>span connections will be hard to accept because the
>security enclosure has to be as wide as the scope. One way
>to make it acceptable would be ask for a coordinated
>security/STag enclosure.
>
>Julo
>
The intent is to allow an STag to have the scope of a ULP
session. A ULP session would be defined as a set of one or
more DDP/RDMAP Streams that are meaningfully connected by
the ULP (i.e., it is not defined).

An example of a ULP Stream would be the set of
communications channels in a DAFS Session.

It is extremely desirable to allow an STag to be used on any
stream *within a session* without having to remember to use
a different value for each Stream.

With InfiniBand, that goal is met by allowing multiple
connections to be placed in a single Protection Domain.
R-Keys (IB's STag) are validated within a Protection Domain.

I believe that a Protection Domain concept: increases
compatability with IB, provides a meaningful scope /
security enclosure,  and can be implemented easily.

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, 01 Oct 2002 10:01:42 -0700

>security enclosure,  and can be implemented easily.

Agreed.

Mike