Subject: [Tsvwg] Comments on TCP ULP Framing and TLS

From: Andreas Jungmaier <[email-masked]>
Date: Fri, 24 Aug 2001 18:26:14 +0200

Dear all,

as you can see, I am working my way through the draft :-)

I have a number of comments on the section about use of TLS
with ULP TCP framing (as per the document
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-ulp-frame-00.txt )

What you are essentially saying is:
Use of TLS with Framing TCP in PDU alignment mode is a no-no,
since there may be compression methods that add to the fragment
size. Also, RFC 2246 says that 
"The record layer fragments information blocks into TLSPlaintext
 records carrying data in chunks of 2^14 bytes or less. Client message
 boundaries are not preserved in the record layer (i.e., multiple
 client messages of the same ContentType may be coalesced into a
 single TLSPlaintext record, or a single message may be fragmented
 across several records)."
As such you may end up with a fragment size of 2^14+2048+5 bytes !

And if you send such large messages you would have to make sure 
as per section 5.2 of your draft that each TCP fragment does
not look like a new framing PDU. This is messy, IMHO.

Also, I disagree with the statement (of the section 7.3) that
"TLS records are PDUs just like those used by ULPs that permit 
 direct placement. "
You must also consider the possibilities of TLS sending ALERT
messages or CHANGE CIPHERSPEC messages !
If you allow direct placement, but have lost a CHANGE CIPHERSPEC
message, then  your PDU will not decrypt !

Also, I think you should explain a bit more thoroughly what
the difference between a TLS implementation and a framing
aware TLS implementation is (since the framing aware TLS
implementation seems to cover only a subset of the functionalities
that normal TLS implementations provide).

Best regards,

Andreas

- -- 

- ------------------------------------------------------------------------
Dipl.-Ing. Andreas Jungmaier              |                         _
Computer Networking Technology Group      | ASCII ribbon campaign  ( )
University of Essen                       |  - against HTML email   X
http://www.exp-math.uni-essen.de/~ajung   |              & vcards  / \

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Stephen Bailey <[email-masked]>
Date: Sat, 25 Aug 2001 11:46:41 -0400

Andreas,

Thanks again for digging in to this.

First, the description of using TLS with the framing protocol is
intended to be a sketch of the issues more than a complete
specification.  Perhaps we could reinforce that in the text.  Given
the layering of TLS on TCP, if you WANT to maintain the direct
placement advantages offered by the framing protocol, TLS must be a
ULP client of the framing protocol.  Each ULP client needs to define
how it engages the framing protocol.

The further point is that only modifying the `bottom' interface of TLS
to use the framing protocol is not enough if you want to do direct
placement of ULP data.  As your quote from RFC 2246:

   Client message boundaries are not preserved in the record layer
   (i.e., multiple client messages of the same ContentType may be
   coalesced ...

indicates, if you don't modify the `top' interface to TLS, a direct
placement implementation could find the TLS PDUs, but not the ULP
PDUs.

> Use of TLS with Framing TCP in PDU alignment mode is a no-no,

We didn't say that, because like most anything, it's very difficult to
prove conclusively that something `can't be done'.  There's no reason
to catagorically prohibit it.

However, I personally don't think TLS is a good fit with the framing
protocol, particularly if you want to use PDU aligment mode (which
most do, when they can).

Absent all other issues of maintaining ULP PDU boundaries, TLS's
cipher behaviors (CBC or stream) depend upon data from the previous
TLS PDU (or PDUs) to decrypt the present TLS PDU.  The whole point of
the framing protocol is to allow direct placement of ULP PDUs received
in out-of-order TCP segments, but TLS's cipher behavior intereferes
substantially with this goal.  Certainly, assuming the cipher is
either CBC or a self-synchronizing stream, you can decrypt and place
SOME out-of-order TCP segments, but there's always that awkward first
TCP segment(s) of an out-of-order set that you must hold until it's
predecessor(s) arrives.  To implement this is actually roughly the
same as implementing a marker-mode framing receiver but with different
logic for the `eddy buffer'.  As such, adding TLS to a marker-mode
framing implemention might more be straightforward, but I expect the
final result would be spectacularly complicated.

Adding TLS support to a PDU alignment mode implementation defeats the
primary, compelling advantage of PDU alignment mode (no need for eddy
buffering).

IPSec is a much easier choice to implement for securing framing
protocol exchanges, and, not surprisingly, seems to be what those who
have expressed interested in the framing protocol plan to implement.

> size.

The compression methods MAY add to the fragment size.  We pointed out
that (probably) the easiest way out of this dilemma would be to use a
compression method which is guaranteed not to add to the fragment's
size.  This is only a problem if you are using PDU alignment mode.
Even if the compression might expand, an alternative would be to
reserve enough space for the expansion.

Again, we wanted to expose the issues we saw with implementing
TLS+framing protocol while maintaining the advantages that the framing
protocol offers.

> "TLS records are PDUs just like those used by ULPs that permit

I can see the wording here is a little suspect.  The point intended is
that TLS records are ULP PDUs.  Alerts & change cipherspec messages
are also PDUs.  However, your next point:

> messages or CHANGE CIPHERSPEC messages !  If you allow direct
> placement, but have lost a CHANGE CIPHERSPEC message, then your PDU
> will not decrypt !

is important.  Independently of the specific messages involved, if the
cipher parameters change on-the-fly out-of-order processing is not
possible.  This is a similar problem as faced by TLS accelerators in
traditional NIC cards.  I can envision a variety solutions
(e.g. quiesce the link and exchange new cipher parameters
synchronously), but not being a TLS expert, I'm not sure what can or
is ACTUALLY done in this case.

This is yet more complexity with a TLS+framing protocol
implementation.  We still can't say it can't be done, but we can say
it's certainly complex to do it.

> Also, I think you should explain a bit more thoroughly what the
> difference between a TLS implementation and a framing aware TLS
> implementation is (since the framing aware TLS implementation seems
> to cover only a subset of the functionalities that normal TLS
> implementations provide).

Actually, I would suggest that if enough people are interested in
TLS+framing, we do a separate draft that covers it.  The present draft
attempts to uncover some of the issues, it does not attempt to solve
them.  We need people both motivated and capable of producing a
solution before we can do that.  If you are such a person, please let
us know.

Thanks again for your feedback.

Steph

---

From: Jacob Heitz <[email-masked]>
Date: Sat, 25 Aug 2001 12:36:30 -0700

I have a simple alternative that requires no additional headers.
I'm sure it must have already been thought of, but rejected.
If so, I'd like to know why it was rejected.

Modify the sending TCP to send one ULP PDU in one IP packet,
ie, a one to one correspondence between ULP PDU and IP packet.
Do this for retransmissions as well as transmissions. 
TCP needs this modification for either proposal.

Modify the receiving TCP to pass data up to the ULP as PDUs
corresponding to received IP packets.
TCP needs this modification for either proposal.

If a PDU to be sent exceeds the maximum segment size, the
sending TCP would segment it into the required number of
segments and set the PUSH bit on only the last segment.
This way, the receiver can reassemble them.

I make no proposal for bundling short ULP PDUs together into
a single TCP segment.

-- 
// Jacob Heitz. Tel:510-747-2917

---

From: Andreas Jungmaier <[email-masked]>
Date: Mon, 27 Aug 2001 16:44:55 +0200

Stephen, dear all,

> Thanks again for digging in to this.

Sure, it is a pleasure.

> specification.  

I agree. It is sketchy. After all, direct placement and TLS
are two topics that are difficult to have at the same time.

> protocol, particularly if you want to use PDU aligment mode (which

That is what I think, too. It is just awkward.

> I can see the wording here is a little suspect.  

I would even say, it is *wrong* - you cannot have direct placement
in any case - see below.

> The point intended is that TLS records are ULP PDUs.  Alerts & change 
> cipherspec messages are also PDUs.  However, your next point:
>

> solution before we can do that.  If you are such a person, please let

Thanks for the offer, but I think we have actually solved the problem
already - however with SCTP (see 
http://www.ietf.org/internet-drafts/draft-tuexen-tsvwg-tls-over-sctp-00.txt )

Best regards,

Andreas Jungmaier

- --