Subject: RE: Fw: [rddp] STag validation semantics

From: "Mukund, Shridhar" <[email-masked]>
Date: Thu, 17 Oct 2002 14:52:51 -0700

Renato,

Some thoughts on the DDP draft:

1. DDP (RDDP?) draft needs to stand on it's own without depending on 
   either RDMAP draft or the MPA draft. For instance a ULP like 
   iSCSI *may* want to ride on DDP without requiring RDMAP. For that 
   matter it should be valid to implement a DNIC(DDP NIC) instead of 
   a RNIC. I hope we agree there.

2. Please introduce the notion of DDP-STag vs. ULP-STag(RDMAP-STag). 
   This seems to be the source for much confusion. Further more, the 
   two layers DDP and RDMAC(or another ULP of DDP) associate different 
   meanings to them.

   * DDP-STag = RDMAP-STag is just an artifact of RDMAP implementation.
     Only when the ULP consumer wants to sink remote data, it needs to
     bring DDP-STag into existence. 
     For iSCSI over DDP, may be DDP-STag = ITT or TTT.

   * It is the DDP-STag that needs to be scrutinized rigorously 
     against IP-related attacks.(Granted, ULP-STag will be subject to 
     other attacks outside the scope of IPSec)

   * You cited applications such as file/web servers that need to give 
     read access to the world. Those ULP-STags will not map down to 
     DDP-STags on the wire! ULP may define broader scope for ULP-STag
     and find ways to enforce it.

   * As Caitlin/Julian alluded elsewhere, some may find innovative ways 
     of using DDP-STags including DDP-STag = foo(ULP-STag,...)to provide 
     useful functions/features. ... sure, let's keep things simple 
     for RDMAP other than recognizing the difference for documentation.

3. Since buffers(security critical resources) are modified by the DDP
   layer, the security envelope should be stretched into the DDP layer.
   (Granted, the ULP creates & controls that envelope). 
   * Most verbiage in your email refers to RDMAP instead of DDP.
   * Postponing security checks to RDMAP/ULP layer while the 
     underlying layer(DDP) modifies secure resources does not sound 
     like a good design choice.( I believe it is not intended )

4. If IPSec is used for security against malicious data placement 
   then all connections within a PD MUST be secured at the same level 
   of IPSec *connection* security( SA relationships and related language
   as the security envelope moves further from TCP connection ... ). 
   - But for the above, we give a FALSE sense of security to remote
     clients who choose to protect their connection using IPSec 
     but are still exposed to attacks from packet injection on other 
     insecure connections within the PD.  
   
   Alternatively, we could state that IPSec CANNOT be used to secure 
   against malicious data placement. I think that may not fly. Note 
   that the last sentence in section 10.2 of DDP draft actually implies 
   this.

Thanks.

-Shridhar Mukund

> -----Original Message-----
> From: Renato Recio [mailto:[email-masked]]
> Sent: Friday, October 04, 2002 9:40 AM
> To: [email-masked]
> Subject: Re: Fw: [rddp] STag validation semantics
> 
> 
> 
> Julian,
> 
> Regarding protection:
> 
>    Protecting an STag from being used on a connection which 
> is not allowed
> to use it is a problem that was solved even before IB.  The solution
> consists of providing a *protection* mechanism for 
> associating an STag with
> a connection.  Lets call that mechanism a Protection Domain (PD).  The
> semantics for the PD are:
> 
>  - A Protection Domain (PD) MUST be used to associate a RDMA 
> Stream to an
> STag.  Each RDMA Stream MUST be associated with one, and only one,
> Protection Domain.  Each STag MUST be associated with one, 
> and only one,
> Protection Domain.  However, the same PD can be used on multiple RDMA
> Streams and on multiple STags.
> 
> - If the PD associated with an STag does not match the PD 
> associated with
> the RDMA Stream, RDMAP MUST terminate the RDMAP Stream using the
> termination mechanism in section 6.8.
> 
> Under this approach the RNIC (RDMA enable NIC) resource used 
> to perform the
> memory protection and translation process, based on the 
> incoming STag and
> TO,  only has to create one resource for *all* RDMA Streams 
> that fall under
> the same PD.  A ULP can then expose different portions of a 
> single buffer
> (that is referenced by a single STag) on multiple RDMA 
> Streams and only the
> RDMA Streams which share the same PD will have access to the 
> buffer.  RDMA
> Streams that do not share the same PD cannot access the buffer.
> 
> An inferior approach would be to have:  An STag *MUST* only 
> be valid on
> one, and only one, RDMA Stream.  Why is this approach 
> inferior?  Because it
> either requires:
> 1.  The RNIC to have multiple memory protection and 
> translation entries for
> each buffer which a ULP wants to share across multiple RDMA Streams.
> 2.  The RNIC entry used to hold the memory protection and 
> translation for
> the buffer would need one additional chunk of state 
> ("connection salt" as
> you called it) for each RDMA Stream that the ULP wants to 
> access the shared
> buffer.
> 
> So in my opinion,  the PD approach I described above is "sweeter" :{).
> 
> BTW,  under the above approach,  a ULP *could* choose to make the STag
> associated with a single RDMA Stream.
> 
> BTW,  You may ask,  what ULPs would want to share buffers?  
> Here is a list
> of some of the top:
> - Web servers that send the same content to many, many clients.
> - File servers that provide many clients with read access to the same
> files.
> - Databases in a cluster or multi-tier server environment.
> 
> 
> Regarding security:
> 
> Obviously if a rogue endpoint can inject RDMA/DDP/Transport 
> Segments into
> the fabric,  all kinds of damage would result.  I believe 
> iSCSI faces the
> same problem.
> 
> Thanks,
> 
> Renato J Recio
> Distinguished Engineer
> IBM I/O Architecture and Technology
> Tel 512-838-3685, T/L 678-3685
> 
> 
> 
>                                                               
>                                                           
>                       "Julian Satran"                         
>                                                           
>                       <Julian_Satran@il        To:       
> [email-masked]                                                  
>                       .ibm.com>                cc:            
>                                                           
>                       Sent by:                 Subject:  Fw: 
> [rddp] STag validation semantics                           
>                       [email-masked]                       
>                                                           
>                       rg                                      
>                                                           
>                                                               
>                                                           
>                                                               
>                                                           
>                       10/04/2002 09:52                        
>                                                           
>                       AM                                      
>                                                           
>                                                               
>                                                           
>                                                               
>                                                           
> 
> 
> 
> 
> 
> 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]           To:        
> [email-masked]        
>                                            cc:                
>              
>                                            Subject:        
> Re: [rddp] STag 
>     01/10/02 16:12                 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
> 
> 
> 
> 
> 
> _______________________________________________
> 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: Thu, 17 Oct 2002 17:17:14 -0500

On 10/17/02, Mukund, Shridhar wrote:

>
>4. If IPSec is used for security against malicious data
> placement then all connections within a PD MUST be
> secured at the same level of IPSec *connection* security(
> SA relationships and related language as the security
> envelope moves further from TCP connection ... ). - But
> for the above, we give a FALSE sense of security to
> remote clients who choose to protect their connection
> using IPSec but are still exposed to attacks from packet
> injection on other insecure connections within the PD.  
>   
> Alternatively, we could state that IPSec CANNOT be used
> to secure against malicious data placement. I think that
> may not fly. Note that the last sentence in section 10.2
> of DDP draft actually implies this.
> 

The ULP already controls which LLP transport is used for
each stream, and which PD each stream is associated with.

The DDP layer, by contrast, does not create LLP connections
and in a cleanly layered implemenation would not even know
whether the LLP was secure or not.

Therefore, as valid as this guideline is, it would be the
ULP itself that is in position to enforce it. And since 
the ULP would only be harming itself when it chose not
to follow it, there is no reason for this to be anything
more than a strongly recomended practice.

Caitlin Bestler

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 17 Oct 2002 18:00:04 -0500

On 10/17/02, Mukund, Shridhar wrote:

>1. DDP (RDDP?) draft needs to stand on it's own without
> depending on either RDMAP draft or the MPA draft. For
> instance a ULP like iSCSI *may* want to ride on DDP
> without requiring RDMAP. For that matter it should be
> valid to implement a DNIC(DDP NIC) instead of a RNIC. I
> hope we agree there.
>

I believe that is already implicit. Indeed, even when
offering RDMAP it would be quite legitimate to implement
RDMAP in the device driver rather than the NIC.

And yes, in addition to working without RDMAP, one of the
other goals would be to enable other alternate layers just
above DDP.

>2. Please introduce the notion of DDP-STag vs.
> ULP-STag(RDMAP-STag). This seems to be the source for
> much confusion. Further more, the two layers DDP and
> RDMAC(or another ULP of DDP) associate different meanings
> to them.
>
> * DDP-STag = RDMAP-STag is just an artifact of RDMAP
> implementation. Only when the ULP consumer wants to sink
> remote data, it needs to bring DDP-STag into existence.
> * It is the DDP-STag that needs to be scrutinized
> rigorously against IP-related attacks.(Granted, ULP-STag
> will be subject to other attacks outside the scope of
> IPSec)
>
> * You cited applications such as file/web servers that
> need to give read access to the world. Those ULP-STags
> will not map down to DDP-STags on the wire! ULP may
> define broader scope for ULP-STag and find ways to
> enforce it.
>
> * As Caitlin/Julian alluded elsewhere, some may find
> innovative ways of using DDP-STags including DDP-STag =
> foo(ULP-STag,...)to provide useful functions/features.
> ... sure, let's keep things simple for RDMAP other than
> recognizing the difference for documentation.
>

The STag already is a DDP creature. It is merely referenced
by the ULP and RMDAP. It is transalted, and placements are
made based upon it, by the DDP layer. In the abscence of a
contrary requirement for the local interface, the value
itself may be selected by the DDP layer (which is a omission
inherited from IB, where I believe it was deliberate).

However, unlike IB, the local semantics of an STag are
*very* open to local enhancement. The final set of drafts
will certainly include a requirement that the ULP be able
to create an STag with bounds that can reference a subset of
its already authorized/mapped memory. The local interface 
MAY allow other forms of STag creation as well.

Ultimately an STag is merely a handle which yields a bounded
range of addressable bytes, or something that behaves as
though they were a range of addressable bytes.

>3. Since buffers(security critical resources) are modified
> by the DDP layer, the security envelope should be
> stretched into the DDP layer. (Granted, the ULP creates &
> controls that envelope). 
> underlying layer(DDP) modifies secure resources does not
> sound like a good design choice.( I believe it is not
> intended )
>

What sort of security are you looking for? A one-time key
to enable each transfer?

Why? The ULP can already limit an STag to a single
transaction. It can already deliver the buffer advertisement
within an encrypted message.

The only way to increase security of the STag beyond that
would be to make it larger, or to upgrade the mandate that
the key be made as pseudo-random as possible be upgraded
from a SHOULD to a MUST. Neither of these would seem to by
very much relative to the cost their implementation would
have.

Further, placing security mechanisms directly in the DDP
layer would actually undermine security in the long run.
Concentrating security mechanisms in the transport and ULP
layers encourages investment in those layer's mechanisms,
and ensures that DDP/RDMAP applications can easily apply
new developments made available at those layers without 
having to update all of the RNICs involved.

The bottom line on security is that the ULP already has
ful control over all of the following:

- how secure the LLP connection is.
- how secure the buffer advertisemet is.
- which STags are valid on which connections.
- when each STag is invalidated.

And all of that is achieved without requiring a single
cryptographic feature within the DDP or RDMAP engines.

Caitlin Bestler