Subject: Re: [AAA-WG]: Issue 224: Handling errors in the TCP stream

From: Pat Calhoun <[email-masked]>
Date: Sat, 3 Nov 2001 07:33:15 -0800

Doesn't this text belong in the transport draft?

PatC
On Thu, Oct 25, 2001 at 10:51:31PM -0500, David Frascone wrote:
> Submitter name: David Frascone
> Submitter email address: [email-masked]
> Date first submitted: 25-Oct-01 
> Reference:  
> Document: Base
> Comment type: Technical 
> Priority: 1
> Section: 
> Rationale/Explanation of issue: 
> 
> Since TCP is stream oriented, an error in the stream is completely
> un-recoverable.  Therefore, when an error is detected in the stream, the
> connection must be closed.
> 
> Errors can be detected by reserved bits being set, avp lengths being
> less than the size of an AVP header, or greater than the diameter message
> length.
> 
> There was no input on whether or not to first send a response.  Since
> an error can occur in a request or in an answer, I think closing the
> connection without sending a response is acceptable.
>

---

From: Allison Mankin <[email-masked]>
Date: Sat, 03 Nov 2001 11:13:40 -0500

Pat,

David's text recommends a good thing to do - but the cause of
possible errors would be a security problem not a transport
problem - with TCP reliable delivery, the connection would not 
deliver messages with errors - even a short packet could
only result from aborting the connection - so the connection is
closed already and Diameter knows there was a problem when that 
happens.

The security problem is packet insertion (blind spoofing) that could
be achieved through sequence number guessing.  This is real, and
David's original message sent me to look into it (but not get around
to posting yet, alas).  People can check out -
  http://www.cert.org/advisories/CA-2001-09.html

It might not always be that an error would be detectable - it
could be a plausible enough message.  TLS use (I believe) will mean
the connection is shut down by an insertion attempt, through TLS
fatal alerts.  Again, what David suggests is what happens.

For the transport and security drafts, points I would make:

- it may be quite important to protect the TCP with TLS
- SCTP is less vulnerable 
- there might be DoS worries from TLS shutting down and
  so I inquire (of any TLS folks here and will put this
  to the TLS WG also) if TLS should change not to close down
  (fatal alert) in all cases instead of ignoring the data that 
  doesn't authenticate.

Allison

---

From: Pat Calhoun <[email-masked]>
Date: Sun, 4 Nov 2001 13:35:57 -0800

How about the following text to handle this issue:

2.1  Transport

[...]

When Diameter is used over TCP and an error in the stream occurs,
the stream cannot be recovered and the transport connection MUST be closed.

PatC

---

From: Allison Mankin <[email-masked]>
Date: Sun, 04 Nov 2001 19:43:13 -0500

Pat,

> the stream cannot be recovered and the transport connection MUST be closed.

There is no way to see the error in a TCP stream.  If there
isn't a seamless flow of bytes with the right sequence numbers
and checksums, TCP sender will retransmit till there is, or the
connection will close itself :)

Suggestion that is more accurate about errors:

If Diameter receives data up from TCP that cannot be parsed or
identified as a Diameter error made by the peer, the stream is
compromised and cannot be recovered.  The transport connection MUST
be closed using a RESET call (graceful closure is also compromised).