[VOIPSEC] Actual Attacks - UA handling

[Geoff Devine]

That's not quite what I said.  I said that 256 isn't quite enough but something around 1K (1300 is the upper limit) makes sense in a memory limited implementation.  Consider running SIP in a 3G cell phone.  You're in an incredibly MIPS and RAM-limited environment where power consumption is the primary design consideration.  Bandwidth is scarse so the protocol is kept as terse as possible.  It's hard to imagine a 3G network that encourages, or even allows, a 64K PDU.  In my opinion, there will be far more SIP mobile devices than wireline devices 5 years from now.

 

As far as TCP goes, Vonage claims to be adding 15,000 subscribers every day.  They use UDP.  I don't think I've ever seen a message on the Vonage network that approached 1K.  I haven't seen any other widely deployed network that used TCP.  Can you point me to one that can validate your TCP claim?

 

As an aiside, TCP & TLS causes a lot of issues when you're trying to build a high-density carrier-class solution.  It's difficult to built a TCP that is redundant.  If TCP isn't redundant and you pull the card that is running TCP for 100,000 connections, all the connections bounce and you end up with what looks like a SYN attack.  I've been looking for a bump in the wire security processor that can cope with TLS.  It's easy to find one that can cope with IPSec at any speed you can imagine so that scales well at reasonable cost.  I haven't been able to solve that for TLS yet.

 

Geoff

-------------------------------------------------------------------------------

Unless you know your product will only be used on a network with an MTU of
1500, and you know it will never be used with TCP, then 1300 or so bytes per
message might be reasonable.

VERY few devices, if any, know this.   TCP is being used increasingly with
SIP, and I would not be surprised if most SIP is TCP in a couple of years.

It is legal to send, for example, a RequestURI that is path MTU minus a few
dozen bytes.  If you are rejecting messages with RequestURIs that are longer
than 256 bytes, you are non compliant with the spec.

Even the smallest embedded processor has enough memory to cope with 64K
messages, and it's not hard to code so that any component can be that big
without using megabytes to preallocate data structures at maximum size.  I
think it is a serious mistake to assume 1300 byte packets and 256 byte
components.

Brian

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Geoff Devine
> Sent: Monday, March 07, 2005 11:19 PM
> To: Voipsec at voipsa.org
> Subject: Re: [VOIPSEC] Actual Attacks - UA handling
>
> Brian Rosen writes:
> > Basically, the size of most text fields should not be limited anything
> close
> > to 256.  Generally, the spec allows text fields of any length, but in
> > practice a message has to fit in a packet, and thus you have an
> effective
> > limit of 64K for the message.  It's theoretically possible to have
> headers
> > in a message sent with TCP be longer than that, but I don't think you
> will
> > see anyone complain about limiting total message length to 64K.
>
>
> If you look at RFC 3261, you'll see:
>
>    "If a request is within 200 bytes of the path MTU, or if it is larger
>    than 1300 bytes and the path MTU is unknown, the request MUST be sent
>    using an RFC 2914 [43] congestion controlled transport protocol, such
>    as TCP."
>
> And
>
>    "However,
>    implementations MUST be able to handle messages up to the maximum
>    datagram packet size.  For UDP, this size is 65,535 bytes, including
>    IP and UDP headers."
>
> Given that most SIP implementations only run over UDP, an overall
> 1300-ish byte maximum PDU limit is what you'd expect to see in
> operational networks.  You'd size internal data structures assuming
> that's the "typical" biggest PDU you'll see.  256 might not be quite big
> enough but it doesn't make much sense in a memory-limited environment to
> build something that is optimized to deal with objects bigger than 1K or
> so.  You have to code defensively to meet the 64K normative requirement
> but that's not the real world.
>
> Geoff
>
>
>
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>