Re: draft-zourzouvillys-sip-via-cookie-00

Henry Sinnreich <[email protected]>
Newsgroups gmane.ietf.sip
Message-ID <C5C4BF9C.B77D%[email protected]>
Please correct me, but these and previous other discussions on related topics, such as forking, early media and race conditions seem to confirm the fact that no formal and reliable routing protocol has been developed as yet to route between a larger number (more than 2 in the trapezoid model) of SIP proxies and various (Oh so many) other feature and media servers.

If there were a reliable routing protocol between all the SIP network elements these discussions would not take place for so long and there would be just one RFC describing something like "The SIP Network Routing Protocol". And some open source implementation to prove it.

As is, every SIP network must be manually engineered, for every configuration instance and adding yet another new "network service" requires starting all over again.

Is this view embarrassingly naïve?
It is only meant to defend the view SIP should be used just as a rendezvous and session setup protocol.

Henry


On 2/20/09 3:05 PM, "Theo Zourzouvillys" <[email protected]> wrote:

On Fri, Feb 20, 2009 at 8:28 PM, Dean Willis <[email protected]> wrote:

> Of course, that doesn't help with an attack mode that turns UAs into
> amplifiers . . .

Well, luckily UAs could more easily remain stateless when rejecting
responses than proxies, as they don't need to worry about things like
forking (be it parallel or serial - e.g due to next hop SRV
processing), so should be able to commonly respond to failure
responses statelessly.

This specific attack only arises when a there can be a invite server
transaction created directly by a UDP request that has not been
authenticated, and doesn't contain a "via cookie"

alas, every UA implementation i've played with to date has almost
always been stateful for even failure responses sent over UDP that
havn't required a large amount of processing (or any variance) to
reach it, except for some very low level induced responses like
malformed header fields.

 ~ Theo

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.