I view this as an "optimization" of the original draft.
The real question is "Are there cases where the original draft would
work, but not Frank's draft". At first glance, one may say, "yes, with
symmetric NATs for example". But in this case, media wouldn't work
either (unless you have a TURN server). If you have that luxyry, then it
may be better. However, there are cases like IM that only use a
signalling channel where the first draft would be simpler.
My gut feel is that we should try to use Frank's optimization when
possible (i.e., when plain STUN works), and then decide if we keep the
existing mechanism (tunnelling through proxies or use a seperate TURN
server) later.
Interestingly enough, this is quite analogous to the ICE vs.
"hole-punching" debate of a few weeks ago.
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 15, 2007 07:40
To: Dean Willis; Richard Barnes
Cc: sip List; Sandy Murphy
Subject: Re: [Sip] Question on SIP Security considerations for
future extensions
With all due respect, I don't agree with this. Its my opinion
that the current model is well-understood and unsatifactory for many
applications. While I think its fine to spend some time clarifying the
current model, I don't think that should hold up the development of an
end-to-end mechanism as well. That development can proceed in parallel
and the sipsec draft is a good start in that direction.
To that end, after receiving the blessing of the majority of the
authors, I'm posting a proposal I made to them regarding a mod to the
sipsec draft that I believe would improve its ability to address true
end-to-end security.
The idea is simple, rather than having the CONNECT message
establish a "tunnel" through a series of proxies, CONNECT is used to
trade addressing information between the UAs that then signal each other
directly. This proposal was made as modifications to the sipsec draft.
The draft is available as a standalone and as a diff to the current
sipsec draft at the following links. Comments are hoped for...
Thanks,
FM
https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/sipsec-fm
iller/
http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://svn.resipro
cate.org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.
txt&url2=http://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/s
ipsec-fmiller/draft-gurbani-sip-sipsec-fmiller-00.txt
On Wed Aug 15 9:37 , Richard Barnes sent:
I'm replying to Dean's original message so that I'm not
deep down in the
thread, but I'd like to point to one of Dean's later
comments:
> Look, my question about security documentation for SIP
extensions had
> nothing to do with SIPSEC and everything to do with
documenting the
> current please-molest-me proxy-mediated
transitive-faith-in-goodness
> I-believe-my-operator-cares-for-me model of SIP
security. And we DO
> need to document this model better -- the question is
how.
Here's my proposal:
First, we need to document the situation as it stands,
given the proxy
model and security mechanisms defined in RFC 3261 and
relevant
extensions. I.e., in the current system, here's the base
(please-molest-me) model, here's what proxies can do to
screw you up in
this model, and here's the sorts of assurances you can
get by employing
some security features.
Second, rather than requiring boilerplate in documents
defining new
extensions, they should comment on how the extension
affects the model
described in the above document -- either providing
additional security
(e.g., by limiting proxy capabilities like SIPSEC) or by
introducing
additional risks (e.g., by increasing proxy
capabilities, like
answer-mode). This discussion could be a required
subsection of the
Security Considerations section.
I think that this would encourage people to give
explicit consideration
to the sorts of risks Sandy noted in the answer-mode
draft, and to think
about how they might fix or avoid them.
--Richard
Dean Willis wrote:
>
> I'm having quite an interesting conversation with
Sandy Murphy (cc'd)
> who was tasked by sec-dir to review one of our drafts
> (draft-ietf-sip-answermode). This draft has some
rather interesting
> security issues, since if implemented incorrectly and
then abused it
> could allow an attacker to "bug your phone" -- that
is, turn it into a
> remote listening device. Similar attacks could also be
used to run up
> the victim's connectivity bill, run down the device's
battery, aggravate
> the "voice hammer" DOS attack, and so on.
>
> This lead us into a discussion of the SIP security
model in general.
> Most SIP practitioners who have been at it for awhile
know that if the
> proxies we have decided to trust suddenly decide to
get malicious, then
> we're very much at their mercy. They can do all sorts
of things,
> including routing our media through interceptors,
mangling SDP payloads,
> injecting (or blocking) instant messages, altering
presence information,
> and so on.
>
> But this aspect of SIP is not obvious to naive
implementors, or even to
> less naive security types.
>
> Maybe every SIP extension document should include a
boiler-plate
> reminder about the sensitivity of proxies, then go on
to enumerate and
> describe the new ways that malicious proxies (should
there be such a
> thing) can wreak havoc using the extension being
documented.
>
> what do you folks think?
>
> 1) Could a reasonable "How you could be violated by
trusted proxies that
> turn rogue" boilerplate be drafted?
> 2) Would the practice of repeating this in drafts help
or hurt us?
> 3) Would it be useful for us to document how each
extension could be
> used by a rogue proxy?
>
> --
> Dean
>
>
>
> _______________________________________________
> Sip mailing list
https://www1.ietf.org/mailman/listinfo/sip
<http://sitemail.hostway.com/sitemail6/parse.pl?redirect=https%3A%2F%2Fw
ww1.ietf.org%2Fmailman%2Flistinfo%2Fsip>
> This list is for NEW development of the core SIP
Protocol
> Use [EMAIL PROTECTED]
<javascript:top.opencompose('[EMAIL PROTECTED]','','','')
> for questions on current sip
> Use [EMAIL PROTECTED]
<javascript:top.opencompose('[EMAIL PROTECTED]','','','')> 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 [EMAIL PROTECTED]
<javascript:top.opencompose('[EMAIL PROTECTED]','','','')
> for questions on current sip
Use [EMAIL PROTECTED]
<javascript:top.opencompose('[EMAIL PROTECTED]','','','')> 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
