Subject: [Dime] Query regarding handling diameter corrupted packet

From: [email-masked]
Date: Fri, 19 Sep 2008 00:02:59 -0500

Dear All:

	We need some clarification of handling diameter corrupted packets. As  
stated in RFC 3588,

	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 (send a TCP RST bit) or an SCTP ABORT
    	message (graceful closure is compromised).

o) In case of TCP, in this case, is it fine to just close the  
Connection with the peer (by socket close), and re-open another new  
connection (Diameter + transport) with same peer?

o) As we have experience, in case of TCP, we can encounter a corrupted  
buffer if there is a mismatch between our tcp stream slicing pointer,  
with diameter message size encoded, which can happen in many ways, one  
of this is wrongly encoded from peer, or missing some padding in time  
of encoding. But main issue is that, once we miss even four byte from  
beginning for one wrong encoded packet, we can not recover for all  
rest of the packets from the tcp stream (assuming fully loaded  
traffic), even-if we ignore couple of byte, since there is no message  
boundary defined in Diameter message. So, can we have message boundary  
defined in Diameter messages in future extension, to recover from this  
situation mainly in case of TCP.

o) In case of TCP, since we depend on message size encoded inside  
buffer to slice a diameter packet, so we can not detect  
DIAMETER_INVALID_MESSAGE_LENGTH for a wrong corrupted message (until  
it is some very big value), so we have to depend on message flags  
checking, Command code, AVP Code etc. but unfortunately all may be  
within correct range. But disaster may happen, when we encounter one  
AVP (mainly string) with very big length, which may corrupt the full  
system. In any case, do we need to inform with some error message to  
the peer before closing the TCP connection, and re-open again?

o) Do we need to follow same reset procedure for SCTP case? Since in  
SCTP even-if one message is corrupted, we can always recover if the  
rest of the messages are ok.

Kind Regards,
Nilanjan

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime