Re: MID Policing; RE: Parse error at the message level

While I warned against the usage of Option 1, I do not believe it to be
in the mandate for Q3 to state that it cannot be done that way.  That is
an implementation detail for vendors to decide upon.  There may be good
reasons to use option one in particular circumstances that would not
apply in general.

As for the protocol version rejection, keep in mind that it only comes
into play after a version negotiation has taken place.  So one can be
reasonably assured that the other end is, in fact, a working H.248
implementation.

Kevin 

-----Original Message-----
From: Elad Chomsky [mailto:[email protected]] 
Sent: Wednesday, February 27, 2008 11:54 AM
To: Schwarz Albrecht; Boyle, Kevin (NCRTP:0Q10); [email protected]
Subject: RE: MID Policing; RE: [Megaco] Parse error at the message level

Hi Kevin and Albrecht,

I have no problem with option 2. However if we go with it, I think we
should also:

1/ Remove "mId" from the description of error #410 (Incorrect
identifier).

2/ Change the description of error #400 (Syntax error in message) so
that it's clear it only applies for a syntax error in messageBody.


Additionally, section 11.3 of the amended H.248.1 requires that "Any
subsequent messaging that does not conform to the negotiated version
shall be rejected with Error Code 406 ("Version Not Supported")." This
seems to me to suffer from the same security concerns. Am I missing
something here?

Thanks,
Elad

-----Original Message-----
From: Schwarz Albrecht [mailto:[email protected]]
Sent: Wednesday, February 27, 2008 10:46 AM
To: Elad Chomsky; [email protected]
Subject: MID Policing; RE: [Megaco] Parse error at the message level


I'm tending to option 2.
Because "security" may have a higher priority than "message decoder
robustness" in the majority of H.248 Control Association deployment
scenarios.

Elad, there is an entire chapter in Draft H.Sup7 on
12	H.248 Control Association: policing of incoming H.248 messages
http://www.itu.int/md/meetingdoc.asp?lang=en&parent=T05-SG16-080422-TD-W
P2-0553


The "fully secure H.248 domain" is subject of 12.3.5.
However, the general cases are discussed before.
The pre-condition of "MID policing" is: the H.248 sender must be able to
encode a correct H.248 message format with a correct MID.

-Albrecht


> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Kevin Boyle
> Sent: Dienstag, 26. Februar 2008 22:06
> To: Elad Chomsky; [email protected]
> Subject: Re: [Megaco] Parse error at the message level
> 
> Keep in mind that using Option 1 makes DoS attacks very easy 
> -- I flood your port with short malformed messages, and make 
> you generate responses to each and every one.  Not only do I 
> waste your time in processing the garbage sent, but now I 
> make you waste the processing time in generating a response 
> and an unwitting accomplice by doubling the number of 
> messages on the network.  Further, by doing this I can make 
> you send response messages that are much larger than the 
> garbage I send in, meaning that the responder becomes the one 
> that congests the network the most.
> 
> I would be extremely careful about responding to malformed 
> messages that don't even get to a TransactionID.  The more 
> compliant a message is to the protocol, the more effort 
> required to execute an attack and the less likely it will happen.
> 
> Kevin
> 
> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Elad Chomsky
> Sent: Tuesday, February 26, 2008 12:34 PM
> To: [email protected]
> Subject: [Megaco] Parse error at the message level
> 
> Hello All,
> 
> I was wondering about the correct behavior when a parse error 
> at the Message level is encountered (i.e. before any 
> transaction request or reply was parsed).
> 
> For example, consider the following message:
> 
>     !/3 [XXX 123.123.123.4]:55555
>     T = 5 {
>       ...
>     }
> 
> This message should fail parsing, as it contains an illegal mId.
> 
> 
> Option 1 is to reply with a message containing only an error 
> descriptor.
> Error code #410 seems the most appropriate. It should look 
> something like this:
> 
>     MEGACO/3 [124.124.124.222]:55555
>     Error = 410 { "Incorrect identifier: [XXX 123.123.123.4]" }
> 
> 
> Option 2 is to simply ignore the offending message and not 
> generate any reply. One (weak) corroboration to this approach 
> is that the definition of error #410 is "The transaction 
> request(s) has been disregarded due to a syntax error..."; 
> and when parsing is aborted it is not known whether the 
> message contains any transaction requests.
> 
> 
> My personal preference is option 1.
> 
> Thanks,
> Elad
> 
> _______________________________________________
> Megaco mailing list
> [email protected]
> http://www.ietf.org/mailman/listinfo/megaco
> _______________________________________________
> Megaco mailing list
> [email protected]
> http://www.ietf.org/mailman/listinfo/megaco
>