RE: iSCSI over TLS

[Sukanta ganguly <sganguly@yahoo.com>]

Julian,
  I see what you are saying. I also not just blindly
opposing IPSec. An optimal security for a protocol can
best be done at that layer. That would be the most
optimal solution. Obviously, we do not have an
security developed inherently for the iSCSI at the
iSCSI layer. So we are debating whether we should
transport i.e. TLS or tunnel i.e. IPSec. Given that if
we go lower in the layer than the protocol itself, the
knowledge of the portocol does not exist, i.e. at
IPSec the semantics of iSCSI is not present at all. So
to some extext integrity is questionable, for lack of
a better term to explain. At a layer higher than the
protocol atleast we maintain the semantics of the
protocol, i.e. a TLS record would have the entire
iSCSI packet. Thats seems like the best way to
maintain the integrity of the protocol (Don't chew me
up on the use of the work integrity as I am just
trying to explain it in terms of the semantics of the
iSCSI protocol, so bear with my explaination).
  Defining a standard with dependencies like the one
we are doing with IPSec involved is not necessarily
bad, but does spill the working of a protocol to
multiple layers, just to get it working. This is not a
very good design (Again, I am just explaining my views
and not pointing fingers at anybody. If there is some
short coming that I am stating, then it is me who does
not yet have a better solution and hence I am the part
to the problem. I am not trying to sit on the sideline
and point out issues. This being a public forum and
people are defining standards that others will be
using in the future, we have an obligation to think
through the whole picture throughly. I had a pretty
nasty response from one of the iSCSI veteran, when I
was trying to point out some problems with TCP and
iSCSI and hence I am putting this disclaimer.)

 Hope, my comments are taken constructively :-)

SG

--- Julian Satran <Julian_Satran@il.ibm.com> wrote:
> 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
> >>3) Apply packet policy based on L3 header
> >>4) Decrypt packet - verify it is covered by the SA
> >>5) Pass to L4 (TCP) for processing
> >>6) Verify Framing/etc.
> >>7) Done
> >>TLS
> >>1) Recieve L2 Packet
> >>2) Pass to L3
> >>3) Pass to L4 (TCP) for processing
> >>4) Decrypt packet
> >>5) Verify Framing/etc
> >>6) Done
> >>
> >>It turns out the policies for TLS are much simpler
> than for IPsec, the
> >>application itself gets to determine if security
> should be turned on or 
> >>not
> >>(rather than another application pushing policies
> into an SPD) and I 
> >don't
> >>see a difference in the security offload
> requirements.  In many cases 
> TLS
> >>will go through firewalls/NAT/NATP much better
> than IPsec, allowing for 
> a
> >>wider deployment model.
> >>
> >>
> >>Bill Strahm
>
>>+========+=========+=========+=========+=========+=========+=========+
> >>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
> 
=== message truncated ===


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