[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: using mapped addresses from stun in sip-outbound, was: Re: [Sip] Outbound Issues: slides 3 and 4
Also, if you want to use STUN for IP discovery, how you get the address
of the STUN server is out of the scope.
I don't think you can assume that the address of the STUN server and the
outbound server will be the same in that case - you may not even have an
outbound server (Read: SIP entity with STUN support). The address MAY of
course be the same, but I don't think we can make that assumption.
Because, in some cases I don't think you would like to send your STUN
requests to the outbound proxy, e.g. if you want to use STUN relay for
your media.
Also, the outbound proxy is only required to have STUN functionlity in
order to support STUN keepalive (that may be enough also for STUN IP
discovery in some cases, though)
Regards,
Christer
-----Original Message-----
From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg at ericsson.com]
Sent: 10. elokuuta 2006 12:56
To: Hisham Khartabil; Jonathan Rosenberg
Cc: IETF SIP List; Rohan Mahy
Subject: RE: using mapped addresses from stun in sip-outbound,was: Re:
[Sip] Outbound Issues: slides 3 and 4
Hi,
>>changing topics here.
>>
>>Hisham - why would you want to do this? The whole idea of sip-outbound
>>is to make the IP in the Contact irrelevant. It will be ignored
>>anyway. Perhaps you are worried about an outbound proxy that supports
>>stun but a registrar that doesn't support sip-outbound?
>>
>We are looking into supporting stun keepalive first in our network.
>sip-outbound is not being considered to be deployed at the same time.
>If you remember, I did ask for these 2 things to be split into separate
drafts.
I asked for it also. And, I think the decission was that the 2 things
WILL be split, even if they will still be described in the same physical
draft.
But, still, the STUN keepalive usage has nothing to do with STUN IP
address discovery usage. Those are two completely separate STUN usages.
Of course, you can use them together, but you can also use STUN
keepalive without STUN IP discovery - even if you do NOT use outbound.
Regards,
Christer
> There are some pretty sizeable security risks in doing this. In
> particular, as long as the client doesn't actually use the mapped
> address that comes back - but rather uses it as a hint to go do
> something else - you can get away without authenticating the stun
> transactions. If you actually use the mapped address from the stun
> response in the Contact, an attacker can send a spoofed stun response
> can incoming calls get routed to him instead. This is partly (and only
> partly) fixable if you authenticate stun responses. However, once you
> require stun authentication then the whole performance benefit of stun
> goes away.
>
> Thanks,
> Jonathan R.
>
>
>
> Hisham Khartabil wrote:
>
>> I don't like this proposal. I'm still with the camp that says: if
>> configured, then it must be true.
>> My main objection is that in this proposal, you are required to send
>> SIP messages before STUN messages. That's a mandate that I'm not
>> comfortable with since I might want to send STUN first to discover my
>> public IP/port to populate the contact header before I send the first
>> REGISTER.
>> Hisham
>> On Aug 8, 2006, at 4:38 PM, Rohan Mahy wrote:
>>>
>>> We had a very long discussion in Montreal about discovery and
>>> validation of a SIP outbound proxy server's ability to receive STUN
>>> requests. While the vast majority of the room was comfortable that
>>> "keepalive=stun" in a URI was a sufficient indicator that an
>>> outbound proxy supports SIP and STUN over the same port, a small but
>>> extremely vocal minority had significant problems with this
>>> assumption. After a discussion with Dean, I am willing to try a
>>> validation proposal which adds no extra round trips if the SIP UA
>>> was indeed correctly configured.
>>>
>>> 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).
>>>
>>> Note that this proposal is not a full *discovery* mechanism, just a
>>> verification mechanism. For example, if the registrar doesn't
>>> support outbound, but the first-hop does, there is no way described
>>> here to discover that the first-hop can accept STUN keepalives. Do
>>> not confuse support of STUN with support of outbound. Supported:
>>> outbound implies that the registrar supports STUN or is configured
>>> to use an outbound proxy that does. The sip-stun option tag only
>>> means that you can send and receive STUN requests on your SIP port.
>>> While outbound requires STUN, STUN does not require outbound.
>>>
>>> [1] Also Note that there is a caveat that you can still shoot
>>> yourself in the foot if you allow messages to come straight to your
>>> registrar that does not support STUN. I think we agreed that we are
>>> not going to enumerate all the ways you can subtly break things in
>>> SIP though.
>>>
>>> thanks,
>>> -rohan
>>>
>>>
>>> _______________________________________________
>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol Use
>>> sip-implementors at cs.columbia.edu for questions on current sip Use
>>> sipping at ietf.org 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
>> sip-implementors at cs.columbia.edu for questions on current sip Use
>> sipping at ietf.org for new developments on the application of sip
>
> --
> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
> Cisco Fellow Parsippany, NJ
> 07054-2711
> Cisco Systems
> jdrosen at cisco.com FAX: (973) 952-5050
> http://www.jdrosen.net PHONE: (973) 952-5000
> http://www.cisco.com
>
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
sip-implementors at cs.columbia.edu for questions on current sip Use
sipping at ietf.org 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
sip-implementors at cs.columbia.edu for questions on current sip Use
sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip