RE: iSCSI over TLS

[Sukanta ganguly <sganguly@yahoo.com>]

Bill, 
  I think what Julian is trying to say is that since
the TLS record is not completed, one would have to
have seperate buffers so that first the entire TLS
record is collected in the host memory and the TLS
works on decrypting it.
  After that iSCSI can start working on the packet
received.
 

SG

--- Bill Strahm <bill@sanera.net> wrote:
> I am confused...
> 
> Why can't I put the data into the memory location
> specified by the TCP
> sequence number ???
> 
> I am assuming that is what you are doing in the case
> of IPsec dropping a TCP
> frame in the middle of the stream.  TCP stacks that
> I am aware of WILL NOT
> pass out of order stream data to applications until
> the intermediate frames
> are dealt with anyway, so what is the difference
> between holding encrypted
> frames and unencrypted frames until the stream is in
> order ?
> 
> I believe that there are also TLS options to do per
> frame crypto, however at
> that point you have to start shipping over IVs with
> each frame, removing
> most wire advantages of TLS over IPsec...
> 
> Bill
>
+========+=========+=========+=========+=========+=========+=========+
> Bill Strahm     Software Development is a race
> between Programmers
> Member of the   trying to build bigger and better
> idiot proof software
> Technical Staff and the Universe trying to produce
> bigger and better
> bill@sanera.net idiots.
> (503) 601-0263  So far the Universe is winning ---
> Rich Cook
> 
> 
> -----Original Message-----
> From: owner-ips@ece.cmu.edu
> [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Friday, November 09, 2001 10:06 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI over TLS
> 
> 
> SG,
> 
> The issue is that if you are not able to decrypt you
> have no iSCSI packet
> header (or RDMA headers) and can't  place data in
> memory (i.e. you need
> anonymous buffers and have to copy).
> With IPSec you are far better off.
> 
> Julo
> 
> 
> 
> 
> "Sukanta Ganguly" <sganguly@opulentsystems.com>
> 09-11-01 18:08
> Please respond to sganguly
> 
> 
>         To:     Julian Satran/Haifa/IBM@IBMIL
>         cc:     "IPS" <ips@ece.cmu.edu>
>         Subject:        RE: iSCSI over TLS
> 
> 
> 
> Julian,
>    I agree to the philosophy of framing and
> steering. With TLS support you
> can still place incomplete TLS records in host
> memory, without decrpyting
> it. Only buffering support needs to be beefed up on
> the host side. And
> frankly speaking that it already present with out of
> order packet
> deliveries etc. I am not proposing that TLS start
> acting on the packet
> immediately as the first peice of the TLS record
> arrives.
>    The same behavior is observed with iSCSI packets
> which span TCP
> packets. The host has to wait for the entire iSCSI
> packet to be present in
> the host memory before the iSCSI layer can do
> anything with it.
>    Do you see my point of argument! ;-)
> 
> SG
> 
> *********** REPLY SEPARATOR  ***********
> 
> On 11/9/2001 at 5:46 PM Julian Satran wrote:
> 
> >The whole reason for doing framing and steering is
> to be able to start
> >placing data in host memory without waiting for all
> the data to arrive.
> >With TLS data can't be decrypted if pieces are
> missing.
> >
> >Julo
> >
> >
> >
> >
> >"Sukanta Ganguly" <sganguly@opulentsystems.com>
> >09-11-01 17:42
> >Please respond to sganguly
> >
> >
> >        To:     Julian Satran/Haifa/IBM@IBMIL,
> "IPS" <ips@ece.cmu.edu>
> >        cc:
> >        Subject:        RE: iSCSI over TLS
> >
> >
> >
> >Julian,
> >   It is correct that TLS records span TCP packets,
> but how does that
> >become anymore of a problem. For packets to be
> resend via the TCP
> >mechanisms, the sender TLS layers prepares the TLS
> record and then hands
> >it over to TCP, TCP may break that TLS layer into
> e.g. say 5 packets and
> >sends them to the receiver. If the receiver does
> not retrieve packet
> >number 3, it will be resend by the sender.
> >  I did not see the problem that TLS brings into
> the picture. Also, what
> >tweaking of the stack are you referring to in this
> scenario. This is just
> 
> >general handlinf of packets that are  done anyway.
> iSCSI will only make
> >sense of the packet after TLS decrypts the packets.
> Did I miss something
> >here ???
> >
> >SG
> >
> >*********** REPLY SEPARATOR  ***********
> >
> >On 11/9/2001 at 4:14 PM Julian Satran wrote:
> >
> >>Bill,
> >>
> >>The one "tiny" item you forgot to mention is that
> TLS records span TCP
> >and
> >>iSCSI PDU boundaries. TLS records can't be
> decrypted in face of TCP
> >packet
> >>loss and markers/alignment can't be recovered (to
> be more precise
> require
> >
> >>a lot more tweaking of the stacks).
> >>
> >>Julo
> >>
> >>
> >>
> >>
> >>"Bill Strahm" <bill@Sanera.net>
> >>08-11-01 23:55
> >>Please respond to "Bill Strahm"
> >>
> >>
> >>        To:     Julian Satran/Haifa/IBM@IBMIL
> >>        cc:
> >>        Subject:        RE: iSCSI over TLS
> >>
> >>
> >>
> >>Julian,
> >>
> >>I do not understand how TLS interferes with
> delivery of iSCSI packets
> any
> >>more than IPsec.  In either case your TOE MUST
> decrypt the packet and
> >deal
> >>with the results.  I do not see how this changes
> the problem if the
> >packet
> >>is decrypted before going to the TOE (again the
> hardware to do this MUST
> 
> >>be
> >>on the NIC device) or after going through the TOE
> processing...
> >>Quick summary of what I think needs to happen
> >>IPsec
> >>1) receive L2 packet
> >>2) determine it is IP
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com