Subject: Re: iSCSI over TLS

From: Dave Sheehy <[email-masked]>
Date: Thu, 08 Nov 2001 12:42:04 PST

Julo,

> 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.

If framing and steering "are essential" (your words) then why is framing
not a MUST in the spec? And why are so many implementers stating (or hinting)
that they are NOT going to implement it? I think there is a major disconnect
here. iSCSI w/o framing or markers is dead in the water IMHO.

Dave Sheehy

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 9 Nov 2001 11:56:25 +0200

Dave,

It is not me you have to blame. Neither on the list nor on face-to-face 
the group could not reach a consensus on making it must for the sender if 
the receiver so wishes.

Julo

Dave Sheehy <[email-masked]>
Sent by: [email-masked]
08-11-01 22:42
Please respond to Dave Sheehy

        To:     [email-masked] (IETF IP SAN Reflector)
        cc: 
        Subject:        Re: iSCSI over TLS

Julo,

If framing and steering "are essential" (your words) then why is framing
not a MUST in the spec? And why are so many implementers stating (or 
hinting)
that they are NOT going to implement it? I think there is a major 
disconnect
here. iSCSI w/o framing or markers is dead in the water IMHO.

Dave Sheehy

---

From: "Sukanta Ganguly" <[email-masked]>
Date: Fri, 09 Nov 2001 08:08:57 -0800

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]
>>Peter,
>>"Peter Mellquist" <[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: "John Hufferd" <[email-masked]>
Date: Fri, 9 Nov 2001 11:05:41 -0800

Bill,
What you are missing here is that many (most) folks that are combining the
iSCSI functions and TCP/IP Offload Engines (TOEs) together on the same chip
(or HBA), get to see the packets as they arrive, if they can see the iSCSI
header (which is usually but not always first) it can begin the placement
of the PDU segments directly in the final memory locations and not into
anonymous buffers, which will require another move within the Hosting
System.  (The reason they can do that is they are able to have their own
internal interfaces into the TCP/IP stacks that they have on their Chips or
HBAs).

It is this key reason why the various vendors think they can have
performance close to or equivalent to FC adapters.  They will not give that
up for TLS.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

"Bill Strahm" <[email-masked]>@ece.cmu.edu on 11/09/2001 10:40:29 AM

To:   "Ips@Ece. Cmu. Edu" <[email-masked]>
cc:
Subject:  RE: iSCSI over TLS

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,

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

09-11-01 18:08

        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

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 10 Nov 2001 10:43:19 +0200

Bill,

The archive has long discussions about it. There are several other docs 
you may want to go through (a memo from June 2000 on my site and a 
doc+presentation by Randy Haagens in the archive.

Julo

09-11-01 20:40

I am confused...

pass out of order stream data to applications until the intermediate 
frames

Bill

-----Original Message-----

SG,

Julo

Julian,

SG