Subject: Re: RFC3161(TSP): doubts about tcp protocol

From: Denis Pinkas <[email-masked]>
Date: Mon, 07 Apr 2003 10:08:04 +0200

> Hi,

> I've developed a TSA but I have a doubt in TCP protocol: if a client 
> sends a request to TSA with invalid TCP message (for example with a flag 
> different of '00'H, with wrong number of bytes in length,...) What must 
> do a TSA in this situations?? RFC3161 mustn't talk something about it??

Does anyone has a text proposal to clarify this situation ?

Denis

> Thanks and Best Regards,
> Pere Fiol

---

From: "todd glassey" <[email-masked]>
Date: Mon, 7 Apr 2003 07:25:42 -0700

Denis - the question is whether Error Conditions of this sort apply to the
trust processes in some fashion, or are deemed to be transport failings. If
there is a rule that say's that the TSA can only accept "properly formed
messages" as part of its operations process, then this situation is not so
much an issue.

The problem comes in when you try to build a dynamic protocols that can
"negotiate" because then each state and decision matrix has to be defined.
And for what the TSP is, that is too much "noise" in its possible uses. They
need to be better defined as I have always said. Otherwise - you have the
potential of having  many implementations of the TSA with unpredictable
interactions...

My feeling is that any Trust Protocol that receives an invalid or malformed
request should reject that request "whole cloth" for security and
process-integrity reasons.

Todd Glassey

---

From: "Pere Fiol" <[email-masked]>
Date: Tue, 8 Apr 2003 08:37:07 +0200

Hi,

I think the same than Todd!! The messages must be well formed in order
to be more secure and robust ...

I think that will be a good idea change test of RFC to include this
situation in Socket chapter, my proposal is:

------------------------------------------------------------------------
----
3.3. Socket Based Protocol

...

The socket protocol is a FULL duplex protocol. So, if the request is
sended with a
 wrong format and the server can decode it, the server SHOULD response
with a error message 
 and close connection nicely. But, if it isn't possible decode the
response for any reason (as long time waitting without receive any
byte), the server SHOULD break connection without 
send any kind of error message to client.

------------------------------------------------------------------------
----

Best Regards,
Pere

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]]
En nombre de todd glassey
Enviado el: lunes, 07 de abril de 2003 16:26
Para: Denis Pinkas; Pere Fiol
CC: ietf
Asunto: Re: RFC3161(TSP): doubts about tcp protocol

Denis - the question is whether Error Conditions of this sort apply to
the
trust processes in some fashion, or are deemed to be transport failings.
If
there is a rule that say's that the TSA can only accept "properly formed
messages" as part of its operations process, then this situation is not
so
much an issue.

The problem comes in when you try to build a dynamic protocols that can
"negotiate" because then each state and decision matrix has to be
defined.
And for what the TSP is, that is too much "noise" in its possible uses.
They
need to be better defined as I have always said. Otherwise - you have
the
potential of having  many implementations of the TSA with unpredictable
interactions...

My feeling is that any Trust Protocol that receives an invalid or
malformed
request should reject that request "whole cloth" for security and
process-integrity reasons.

Todd Glassey