Subject: RE: I-D ACTION:draft-ietf-cat-krb5-tcp-00.txt

From: "Mike Swift (NT)" <[email-masked]>
Date: Tue, 2 Dec 1997 11:55:46 -0800

This draft states:

	In theory, there's no reason for having explicit length fields, that
information is already encoded in the ASN1 encoding of the Kerberos packets.
But having explicit lengths makes it unnecessary to have to decode the ASN.1
encoding just to know how much data has to be read.
I think we are better off using the ASN.1 encoding rather than adding a
separate length field. It is more compatible with existing code (having an
extra length field means additional work to manage a different sort of
buffer. Furthermore, decoding asn.1 to pull off the length is not terribly
difficult. In fact, it is pretty easy to just try to decode the buffer and
if it doesn't succeed, read more data.

- Mike

---

From: Assar Westerlund <[email-masked]>
Date: 03 Dec 1997 00:27:39 +0100

"Mike Swift (NT)" <[email-masked]> writes:
> buffer.

I don't think there is any existing code that supports TCP, so that's
not an issue.  You have to add code for handling the ``reassembly''
and timeout and stuff anyways.

> Furthermore, decoding asn.1 to pull off the length is not terribly

I (obviously) don't agree.  I think it's much simpler and makes
everything more modular being able to read in the data just as data
and then do the ASN1-decoding in some other part of the code.

There's prior art in draft-ietf-cat-kerb-chg-password-00.txt.

/assar

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Tue, 2 Dec 1997 21:50:11 -0500

From: "Mike Swift (NT)" <[email-masked]>
   Date: Tue, 2 Dec 1997 11:55:46 -0800 

I think we really want to have the explicit length field.  Consider what
happens if you are reading the ASN.1 packet from the network; it's much
easier to read four bytes from the network, figure read from them how
much data to expect, and then read that many more bytes from the
network.

To parse the ASN.1 from the network requires that you pull a number of
bytes from the network byte-by-byte ---- in the worst case, if you're
being lenient about accepted (incorrectly encoded) ASN.1
indefinite-encoded BER, you would have to peal bytes from the networking
code on a byte-by-byte basis.

Using traditional socket or winsock interfaces, this is very painful.
It's often much, much, much better to treat ASN.1 as a black box which
is encoded/decoded using low-level routines, and then passing explicit
length fields when slinging ASN.1 structures around.

							- Ted