Subject: [Megaco] Parse error at the message level

From: "Elad Chomsky" <[email-masked]>
Date: Tue, 26 Feb 2008 17:33:50 -0000

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-masked]
http://www.ietf.org/mailman/listinfo/megaco

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 26 Feb 2008 16:06:11 -0500

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-masked] [mailto:[email-masked]] On Behalf
Of Elad Chomsky
Sent: Tuesday, February 26, 2008 12:34 PM
To: [email-masked]
Subject: [Megaco] Parse error at the message level

Hello All,

Thanks,
Elad

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Wed, 27 Feb 2008 09:46:01 +0100

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Kevin Boyle
> Sent: Dienstag, 26. Februar 2008 22:06
> To: Elad Chomsky; [email-masked]
> 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
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Elad Chomsky
> 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).
> 
> Error code #410 seems the most appropriate. It should look 
> something like this:
> 
> 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.
> 
> 
_______________________________________________
Megaco mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/megaco

---

From: "Elad Chomsky" <[email-masked]>
Date: Wed, 27 Feb 2008 16:53:49 -0000

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-masked]] 
Sent: Wednesday, February 27, 2008 10:46 AM
To: Elad Chomsky; [email-masked]
Subject: MID Policing; RE: [Megaco] Parse error at the message level

I'm tending to option 2.

-Albrecht

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 27 Feb 2008 17:35:06 -0500

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-masked]] 
Sent: Wednesday, February 27, 2008 11:54 AM
To: Schwarz Albrecht; Boyle, Kevin (NCRTP:0Q10); [email-masked]
Subject: RE: MID Policing; RE: [Megaco] Parse error at the message level

Hi Kevin and Albrecht,

Thanks,
Elad

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

I'm tending to option 2.

-Albrecht