Subject: RE: iSCSI over TLS

From: "Julian Satran" <[email-masked]>
Date: Fri, 9 Nov 2001 20:05:42 +0200

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" <[email-masked]>
09-11-01 18:08
Please respond to sganguly

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     "IPS" <[email-masked]>
        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" <[email-masked]>
>09-11-01 17:42
>Please respond to sganguly
>
> 
>        To:     Julian Satran/Haifa/IBM@IBMIL, "IPS" <[email-masked]>
>        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" <[email-masked]>
>>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
>>[email-masked] idiots.
>>(503) 601-0263  So far the Universe is winning --- Rich Cook
>>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>>Julian Satran
>>Sent: Tuesday, November 06, 2001 10:17 PM
>>To: [email-masked]
>>Subject: Re: iSCSI over TLS
>>
>>
>>Peter,
>>
>>A group of us seriously considered TLS. The main reason for dropping it
>>was that it would interfere with any mechanism we could think of doing
>>framing and steering and we thought that framing and steering are
>>essential at 10Gbps and over.
>>
>>Julo
>>
>>
>>
>>
>>"Peter Mellquist" <[email-masked]>
>>Sent by: [email-masked]
>>07-11-01 02:15
>>Please respond to "Peter Mellquist"
>>
>>
>>        To:     <[email-masked]>
>>        cc:
>>        Subject:        iSCSI over TLS
>>
>>
>>
>>I am aware that the ips group is leaning toward IPSEC as for the 
security
>>solution but I am interested if anyone is also considering using 
>Transport
>>Layer Security (TLS)?
>>
>>I am concerned that the requirement for IPSEC might make TOEs  more
>>complex
>>than they need to be. Can TLS be optionally used as well as defined by 
>the
>>specification? This could allow TOE vendors to only be concerned with
>>providing normal IPv4 / ipv6 and leave the security to a higher layer. A
>>TLS
>>stack sitting above the TOE could then handle security very well. Also, 
I
>>anticipate that the first generation of TOEs will not support IPSEC. 
With
>>a
>>iSCSI/TLS we could enable security solutions with the first generation 
of
>>TOEs and get speed and security.
>>
>>Are any TOE vendors planning to support IPSEC?
>>
>>Can TLS or IPSEC be supported?
>>
>>-peter
>>
>>
>>
>>Peter Mellquist
>>Seven Systems Technologies
>>575 Menlo Drive Suite 2
>>Rocklin CA
>>916-577-1275
>>[email-masked]

---

From: "Bill Strahm" <[email-masked]>
Date: Fri, 9 Nov 2001 10:40:29 -0800

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Julian Satran
Sent: Friday, November 09, 2001 10:06 AM
To: [email-masked]
Subject: RE: iSCSI over TLS

SG,

Julo

Julian,

SG

require
any

TLS
a
security
I
With
of

---

From: Sukanta ganguly <[email-masked]>
Date: Fri, 9 Nov 2001 11:23:34 -0800 (PST)

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

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Julian Satran
=== message truncated ===

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

---

From: Sukanta ganguly <[email-masked]>
Date: Fri, 9 Nov 2001 11:20:47 -0800 (PST)

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

---

From: Stephen Bailey <[email-masked]>
Date: Sun, 11 Nov 2001 15:52:23 -0500

Bill,

> most wire advantages of TLS over IPsec...

You have a reference for this?  Sounds interesting, but I've never
heard of it before (which means nothing).

Thanks,
  Steph

---

From: Stephen Bailey <[email-masked]>
Date: Sun, 11 Nov 2001 15:57:20 -0500

Sukanta,

> a TLS record would have the entire iSCSI packet.

How do you figure?

TLS has exactly the same stream semantics as TCP.  A ULP has no
control over how many octets go in a TLS record.  More importantly,
even if a sender TLS implementation does control this (agreed you
could build an implementation which provided this property), a
receiver can not assume the property, since the recordization (like
segmentation) is a free choice of the TLS layer.

Steph