<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">

</head>

<body bgcolor="#ffffff" text="#000000">

Hmm.... I'll have to check this out.<br>

<br>

anorexicpoodle wrote:

<blockquote cite="mid:1257978568.2377.61.camel@poodle-x300" type="cite">

  <pre wrap="">Actually I would be far more concerned about the spoofing of refer

messages, which is one of the message types it doesn't auth. It struck

me as unusual that it would auth a bye and not a refer. 

On Wed, 2009-11-11 at 16:20 -0600, Lee Riemer wrote:

  </pre>

  <blockquote type="cite">

    <pre wrap="">I agree.  Shouldn't be too hard if you're sniffing the line, say on a 

wi-fi connection.  Listen for INVITEs, pull dialog info, spoof CANCELs.  

Nice little DOS attack.

Alex Balashov wrote:

    </pre>

    <blockquote type="cite">

      <pre wrap="">Lee Riemer wrote:

      </pre>

      <blockquote type="cite">

        <pre wrap="">What's wrong with authenticating BYEs and CANCELs?  I see them as 

just as important as an INVITE.  Anyone can some around, sniff the 

dialog and spoof a BYE or CANCEL.

        </pre>

      </blockquote>

      <pre wrap="">They'd have to spoof a Call-ID, From and To tags, correct CSeqs, any 

loose-routing parameters present in the Route and/or Record-Route 

headers, and the Route header itself.

I suppose it *could* be done... but...

      </pre>

    </blockquote>

  </blockquote>

  <pre wrap=""><!---->

  </pre>

</blockquote>

</body>

</html>