Subject: RE: [rddp] comments on draft-black-rdma-concerns-00.txt

From: "Teisberg, Robert" <[email-masked]>
Date: Tue, 30 Jul 2002 09:48:44 -0500

Exactly.  Looking at it from the transport's perspective, by the time
the data is delivered, the transport has advanced its ack pointer.  The
hypothetical duplicate packet is outside the receive window and will
be discarded by the transport.  (If you are remembering my spirited
discussion with Doug Otis regarding out-of-order placement, please
also remember that I advocated an "as-if" rule requiring RDDP to make
out-of-order placement undetectable by a properly written ULP.  Placement
of an out-of-window packet would violate this.)

Unreliable transports create an entirely different set of issues, as
Caitlin points out.

> -----Original Message-----
> From: Culley, Paul 
> Sent: Tuesday, July 30, 2002 9:00 AM
> To: [email-masked]; H.K. Jerry Chu
> Cc: [email-masked]; [email-masked]
> Subject: RE: [rddp] comments on draft-black-rdma-concerns-00.txt 
> 
> 
> It seems that the case you bring up should not be allowed in 
> a good implementation.  Once the data is "delivered" to the 
> application (step 2, allowing step 4 to take place), the 
> implementation should not allow duplicate packets to have any 
> effect.  I believe that reliable transports like TCP and SCTP 
> have this semantic, it is very unclear to me that an 
> unreliable transport should be used by an application that 
> wants to treat the data as you suggest.
> 
> Paul Culley
> HP Sr. Fellow
> 281-514-5543
> 
> 
> -----Original Message-----
> From: Bill Sommerfeld [mailto:[email-masked]]
> Sent: Tuesday, July 30, 2002 2:17 AM
> To: H.K. Jerry Chu
> Cc: [email-masked]; [email-masked]
> Subject: Re: [rddp] comments on draft-black-rdma-concerns-00.txt 
> 
> 
> > In other environment and/or application paradigm where attacks
> > are not an issue, implementations may choose to defer tag
> > invalidation or reuse/remap tags in order to attain higher
> > performance. These different levels of protection can be
> > negotiated upfront.
> 
> So, in thinking further about this, maliciousness is not actually
> required for overwrites to be problematic.
> 
> Next hypothetical:
> 
> Remember that IP networks may duplicate packets.  
> 
> 1) application receives packet using DDP
> 2) application gets notified that data is available.
> 3) application believes it is in a safe and trusting environment, so
> RDDP mapping remains valid (neither explicit invalidation nor implicit
> invalidate-on-rx takes place)
> 4) application modifies received data in place
> 5) duplicate packet arrives, overwriting buffer.
> 6) application does some processing which depends on data not
> being overwritten after (4)
> 
> 						- Bill
> 
> _______________________________________________
> 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: "H.K. Jerry Chu" <[email-masked]>
Date: Wed, 31 Jul 2002 20:12:02 -0700 (PDT)

>I suspect that many folks are expecting STags to have a NIC wide scope, that 
>is, any connection on the NIC can use any STag.  That definitely opens up 
>guessing attacks.  While likely implementations MAY do that, a much better 
>choice will be to limit the STag scope to an individual connection.

I thought about that too. But I came to realize this is logically
equivalent to widening the STag, except that widening STags has the
benefit of making NIC's job easier. NICs only need to deal with STags,
which have the dual "security key" function proposed.

>
>If connection scope is chosen, then an attacker must both "hijack the
>TCP connection" and guess the correct STag.

What you said is true only if the connection scope is enforced by the 
DDP-capable NICs before data is placed. This almost requires TOE in
NICs, which is a difficult hoop to jump, both technically and economically.

Also a STag with a scope limited to a connection almost implies the
same value won't be used in any other connections. Randomizing the
value of STags seems a much simpler way to guard against forgery.

>This is where careful use of IPSEC can help; it can make it nearly
>impossible to hijack the connection.
>
>For an example of how the STag scope might be made variable, see VIA Ptags, or 
>InfiniBand Protection Domains.

I took a look at IBA spec on the protection domain, but can't see how it
can help unless the protection domain # is passed on the wire, or is tied
to some connection # and the NIC knows about the mapping (so it can
decide a STag is bad and throw it away). But the last one is equivalent
to limiting STag to a connection scope, which requires TOE on the NICs...

Jerry Chu
Sr. Staff Engineer
Solaris Networking
Sun Microsystems, Inc.
(650) 786-5146

>Note that I don't believe that these mechanisms belong in a wire level 
>specification; but it might be instructive to provide a pointer to, or include 
>a "verbs" level description of these in the security sections of the RDDP 
>document.
>
>Paul Culley
>HP Sr. Fellow
>281-514-5543
>
>
>From: H.K. Jerry Chu [mailto:[email-masked]]
>Sent: Tuesday, July 30, 2002 8:28 PM
>To: [email-masked]
>Cc: [email-masked]
>>It is NICE if the STag deregistration can be automatically
>>applied at the earliest possible moment. But it does not
>>close any security holes. The buffers are exposed until the
>>trailing SEND *and* the deregisration have completed.
>>Consolidating those two completions is a *local*
>>optimization, it has no interoperabilty implications.
>>
>>It is A REALLY GOOD IDEA to use STags exactly once, and it
>>is also A REALLY GOOD IDEA to deregister them as prompty as
>>possible. It is also A REALLY GOOD IDEA to have the fastest
>>processor possible and a few spare GB of DDRAM for your host
>>processor. Redundant power supplies are nice too.
>>
>>The point is that how many STags are available, how quickly
>>they must be reused and how efficiently they can be reused
>>are all economic tradeoffs. The market should be allowed to
>>determine those answers, not the IETF.
>
>It seems that the last defense here is a good selection of STags
>to export. 32 bit STag seems too small for security purpose. In
>the least one should analyze the implication on security and
>recommend some algorithm for selecting STags that is better against
>spoofing. E.g. a simple tag index into a page table will not be
>random at all and be trivial to spoof. (But a randomized STag may
>be hard to implement on NICs efficiently.) This is similar to
>hijacking a TCP connection except that the latter still seems much
>hard. One must guess the correct seq# and port # at the right time
>and also manage to shut out the other end of the TCP connection...
>But here once a valid STag is guessed no other protection is there.
>On a busy system the working set of transient network buffers could
>be in many megabyte range making the probability of guessing a valid
>32 bit STag >> 0. Even with IPsec, a malicious user on an
>authenticated system or a buggy application may stomp on some
>random place in remote memory causing data corruption that will be
>impossible to debug.
>
>Rgds,
>
>Jerry
>
>>
>>
>>
>>
>>
>>
>>Caitlin Bestler
>>http://www.asomi.com/CaitlinBestler.html
>
>