Re: [Sip] Outbound Issues: slides 3 and 4

["Bob Penfield" <[e-mail]>]

Setting phaser to "kill" ;)

Seriously, If the first thing a non-STUN-supporting proxy sees for a new 
connection is a STUN message, It may see it as an attack and tear down the 
connection and possibly black-list the UA.

IMO, the requirement is that the UA be able to verify that the proxy 
supports STUN before it sends a STUN packet.

I am happy with Rohan's proposal.

Now, if I were implementing a UA, I would certainly have it stop STUNing if 
it never saw a STUN response. Maybe the draft should say such to handle the 
case where a UA ends up connecting directly to a non-STUN-supporting 
registrar that thinks it has outbound proxies to handle the STUNing.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[e-mail]


----- Original Message ----- 
From: "Dean Willis" <[e-mail]>
To: "Rohan Mahy" <[e-mail]>
Cc: "IETF SIP List" <[e-mail]>
Sent: Tuesday, August 08, 2006 4:02 PM
Subject: Re: [Sip] Outbound Issues: slides 3 and 4


>
> On Aug 8, 2006, at 9:38 AM, Rohan Mahy wrote:
>
>>
>> The specific proposal works like this.  A UAC which has an outbound  URI 
>> indicating with ;keepalive=stun that the next hop can support  STUN 
>> messages on the SIP port, needs to verify the first hop  supports STUN 
>> before sending any STUN messages. The UAC sends its  first SIP message to 
>> the next hop with a Proxy-Require: sip-stun.   If the URI was correct 
>> (STUN was supported), and the first-hop is  an intermediary, the 
>> first-hop removes the Proxy-Require and  forwards the SIP request 
>> (probably a REGISTER request) along adding  no additional delay.  A 
>> positive response to a REGISTER or OPTIONS  with Supported: outbound and 
>> no error counts as positive  confirmation that either the registrar 
>> supports STUN or expects to  never receive a request without getting it 
>> from an outbound proxy  which did not complain about the Proxy-Require 
>> [1]. If the UAC was  misconfigured (the first-hop intermediary does not 
>> support STUN  keepalives), either the first hop will reject the SIP 
>> request (if  it is an intermediary), or the registrar will not include an 
>> indicator that it supports outbound (if the first hop was the 
>> registrar).
>>
>
> Cullen suggested an alternate possibility that might work.
>
> I'll try and paraphrase:
>
> A UAC which has an outbound URI indicating with ;keepalive=stun that  the 
> next hop can support STUN messages on the SIP port needs to  verify the 
> first hop supports STUN before repeatedly sending STUN  messages.  The UAC 
> may initially try sending STUN messages to the SIP  port of the first hop 
> node. If the UAC does not receive a correct  STUN response (within some 
> timer?)  then it must assume that this  mode does not support STUN, and 
> proceed without using STUN until it  has some evidence that the first-hop 
> node might have changed, in  which case it retries the STUN requests as 
> per the initial attempt.
>
> I think it's probably okay to stun a server a few times before  deciding 
> it doesn't like being stunned -- after all, the primary risk  is one of 
> slowing down service for the user doing the stunning, not  shutting down 
> the server being stunned. What I object to is a  specification that says 
> you go on stunning it indefinitely, perhaps  millions of times over the 
> course of an association, with no way to  discover that you really 
> shouldn't be stunning it.
>
> Set phasers on "stun", Mr. Sulu!
>
> --
> Dean
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip