Subject: Re: maximum size of a VALUE

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 3 Feb 2000 12:25:56 -0600

Your security argument presumably applies to messages from the MG, which is
the end which might be in the hands of an user (e.g. a residential gateway).
I think there is a more general issue here -- even without large message
sizes, the MG could emit a large number of individual messages if it wants
to flood the MGC.  We may want an implementation note that the MGC be able
to defend itself from such attacks, but I don't think we should limit the
protocol just for this reason.

I'd say at this point that we should raise the limit.  As a precedent, here
is what SIP (RFC 2543) has to say:

   Unlike HTTP, SIP MAY use UDP. When sent over TCP or UDP, multiple SIP
   transactions can be carried in a single TCP connection or UDP
   datagram. UDP datagrams, including all headers, SHOULD NOT be larger
   than the path maximum transmission unit (MTU) if the MTU is known, or
   1500 bytes if the MTU is unknown.

> -----Original Message-----
> From: Rayhan, Abdallah [CAR:5N00:EXCH] [SMTP:[email-masked]]
> Sent: Thursday, February 03, 2000 10:07 AM
> To:   Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]
> Cc:   [email-masked]
> Subject:      Re: maximum size of a VALUE
>
>
> Not too fast. I believe couple of the issues were considered when 64 was
> decided; efficiency and security. We dont have max msg size restriction. A
>
> user could cause buffering flooding intentionally if VALUE is huge, not to
>
> mention parsing a msg with huge VALUEs. This could reduce the efficiency
> dramatically. Also, what if VALUE is used to pass malicious code through
> a firewall. If VALUE is unlimited, we could be jeopardizing security. If
> 64 is
> too small we could increase it to 128 or 256 but not unlimited.
>
> Abdallah Rayhan
>
> "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:
>
>
>
>       Looks like a good one for "errata".
>
>               -----Original Message-----
>       From:   Steven Magnell [SMTP:[email-masked]]
>       Sent:   Wednesday, February 02, 2000 7:20 PM
>       To:     [email-masked]
>       Subject:        maximum size of a VALUE
>
>               This may be minor compared to other issues, but it seems
> that the maximum
>       size of a VALUE is 64 characters (not including quotes) in the ABNF
> syntax.
>       It should be larger, perhaps arbitrary. The ASN.1 definition of
> Value does
>       not have this limitation.
>
>               While this does not seem to be a concern with the basic
> packages, looking
>       ahead to upcoming packages such as the display and text telephone
> packages
>       in the otherpkgs draft and the cromwell ARF draft, there is a need
> to
>       support longer strings. The text telephone package, for example,
> defines
>       string parameters with a maximum of 256 characters and the others
> have
>       strings of arbitrary length where some larger string, such as a
> display or
>       text-to-speech announcement, would certainly be reasonable.
>
>               steve magnell
>

---

From: Chuong Nguyen <[email-masked]>
Date: Thu, 3 Feb 2000 13:59:42 -0600

>    1500 bytes if the MTU is unknown.

This blows the use of ALL in Audit or Subtract of the water.

--
  Alcatel USA, Inc             Internet: [email-masked]
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

---

From: David Oran <[email-masked]>
Date: Sun, 6 Feb 2000 09:48:25 -0500

RE: maximum size of a VALUEA small point, but a large number of messages has
not in practice been as big a threat as oversized messages, because of the
pernicious nature of buffer-overflow bugs in numerous implementations of
numerous protocols. However, just writing words in a standard limiting the
size of something is actually worse than writing nothing - implementers
might naively believe that the limits are observed, hence opening the barn
doors for the malicious to send something bigger. If you want to limit
something in a pragmatically useful way, limit the size of the length field
that describes it in the protocol if a binary protocol, and make the limit a
power of 10 in a text protocol. Unfortunately, thise two techniques conflict
:-) and don't confer much protection anyway.

Dave.
  -----Original Message-----
  From: Media Gateway Control (megaco)
[mailto:[email-masked]]On Behalf Of Tom-PT Taylor
  Sent: Thursday, February 03, 2000 1:26 PM
  To: [email-masked]
  Subject: Re: maximum size of a VALUE

  Your security argument presumably applies to messages from the MG, which
is the end which might be in the hands of an user (e.g. a residential
gateway).  I think there is a more general issue here -- even without large
message sizes, the MG could emit a large number of individual messages if it
wants to flood the MGC.  We may want an implementation note that the MGC be
able to defend itself from such attacks, but I don't think we should limit
the protocol just for this reason.

  I'd say at this point that we should raise the limit.  As a precedent,
here is what SIP (RFC 2543) has to say:

    -----Original Message-----
    From:   Rayhan, Abdallah [CAR:5N00:EXCH]
[SMTP:[email-masked]]
    Sent:   Thursday, February 03, 2000 10:07 AM
    To:     Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]
    Cc:     [email-masked]
    Subject:        Re: maximum size of a VALUE

    Not too fast. I believe couple of the issues were considered when 64 was
    decided; efficiency and security. We dont have max msg size restriction.
A
    user could cause buffering flooding intentionally if VALUE is huge, not
to
    mention parsing a msg with huge VALUEs. This could reduce the efficiency
    dramatically. Also, what if VALUE is used to pass malicious code through
    a firewall. If VALUE is unlimited, we could be jeopardizing security. If
64 is
    too small we could increase it to 128 or 256 but not unlimited.

    Abdallah Rayhan

              -----Original Message-----
      From:   Steven Magnell [SMTP:[email-masked]]
      Sent:   Wednesday, February 02, 2000 7:20 PM
      To:     [email-masked]
      Subject:        maximum size of a VALUE

              This may be minor compared to other issues, but it seems that
the maximum
      size of a VALUE is 64 characters (not including quotes) in the ABNF
syntax.
      It should be larger, perhaps arbitrary. The ASN.1 definition of Value
does
      not have this limitation.

              While this does not seem to be a concern with the basic
packages, looking
      ahead to upcoming packages such as the display and text telephone
packages
      in the otherpkgs draft and the cromwell ARF draft, there is a need to
      support longer strings. The text telephone package, for example,
defines
      string parameters with a maximum of 256 characters and the others have
      strings of arbitrary length where some larger string, such as a
display or
      text-to-speech announcement, would certainly be reasonable.

              steve magnell