<!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">
On 02/03/11 01:32, Justin Uberti wrote:
<blockquote
cite="mid:AANLkTi=JqAa=Cc1mfVikwPAyegf=-YaW+RF6j=Mb0ZD_@mail.gmail.com"
type="cite">
<div>I would expect that the APIs that this group creates would
handle the details of obtaining any needed addresses (whether
they be local, server reflexive, or relayed endpoints). Do we
think there is a significant security concern here (above and
beyond exposing the ability to send audio and video from your
computer)?</div>
</blockquote>
Apart from the known security concerns that come automatically from
sharing IP addresses (such as revealing your network attachment
location to whoever gets the IP address), I don't see any huge ones.<br>
<blockquote
cite="mid:AANLkTi=JqAa=Cc1mfVikwPAyegf=-YaW+RF6j=Mb0ZD_@mail.gmail.com"
type="cite">
<div><br>
<div class="gmail_quote">On Wed, Feb 2, 2011 at 7:49 PM, Bernard
Aboba <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:bernard_aboba@hotmail.com">bernard_aboba@hotmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div>
Alternatives can be explored for how to represent the
information provided by SDP, but the enumeration and
testing of potential endpoints within an offer-answer
exchange is at the core of ICE (RFC 5245), and is also a
potential means for demonstrating media authorization. If
the Javascript limitations on enumeration of physical or
logical addresses can't be overcome, we might have to live
with server reflexive and relayed endpoint identifiers
(assuming that server reflexive and relayed endpoint
identifiers don't trigger similar concerns). Replacing
addresses with names could be done prior to the
offer/answer exchange but this might introduce
vulnerabilities (e.g. voice hammer attacks based on DNS
cache poisoning). <br>
<hr>Date: Wed, 2 Feb 2011 16:09:48 -0800<br>
From: <a moz-do-not-send="true"
href="mailto:harald@alvestrand.no" target="_blank">harald@alvestrand.no</a><br>
To: <a moz-do-not-send="true"
href="mailto:rtc-web@alvestrand.no" target="_blank">rtc-web@alvestrand.no</a><br>
Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a
signaling protocol?
<div>
<div class="h5"><br>
<br>
On 02/02/11 11:19, Henry Sinnreich wrote:
<blockquote> <font face="Calibri, Verdana, Helvetica,
Arial"><span style="font-size: 13pt;">Is there
some understanding on the list on how the IP
addresses in SDP can be reconciled with the USAF
RFC 3424?<br>
</span></font></blockquote>
Nit: UNSAF, not USAF.<br>
<blockquote><font face="Calibri, Verdana, Helvetica,
Arial"><span style="font-size: 13pt;"> <a
moz-do-not-send="true"
href="http://www.rfc-editor.org/rfc/rfc3424.txt"
target="_blank">http://www.rfc-editor.org/rfc/rfc3424.txt</a>
<br>
<br>
“...</span></font><font size="2"><font
face="Times, Times New Roman"><span
style="font-size: 12pt;">a process whereby
some<br>
originating process attempts to determine
or fix the address (and<br>
port) by which it is known - e.g. to be
able to use address data in<br>
the protocol exchange, or to advertise a
public address from which it<br>
will receive connections.<br>
There are only heuristics and workarounds to
attempt to achieve this<br>
effect; there is no 100% solution. Since
NATs may also dynamically<br>
reclaim or readjust translations,
"keep-alive" and periodic re-<br>
polling may be required. Use of these
workarounds MUST be considered<br>
transitional in IETF protocols, and a
better architectural solution<br>
is being sought. The explicit intention is
to deprecate any such<br>
workarounds when sound technical approaches
are available.”<br>
</span></font></font></blockquote>
In our case, the answer that has proved workable is
called STUN.<br>
<blockquote><font size="2"><font face="Times, Times
New Roman"><span style="font-size: 12pt;"> </span></font></font><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 13pt;"><br>
Obviously there is much more dead stuff in SDP
besides using the misleading IP addresses, but
this seems to be a deep architectural flaw.<br>
There were some early attempts to do SDPng and
we know today much more:<br>
<a moz-do-not-send="true"
href="http://tools.ietf.org/html/draft-ietf-mmusic-sdpng-07"
target="_blank">http://tools.ietf.org/html/draft-ietf-mmusic-sdpng-07</a><br>
<br>
Why not replace SDP, since it deals only with
a/v codec negotiation with a more general,
standards based metadata approach?<br>
For example including Web conferencing displays
and UI control capabilities.<br>
Of course such a new approach must be easily
mapped to the existing global SIP VoIP
infrastructure. <br>
<br>
Or are the no “</span></font><font size="2"><font
face="Times, Times New Roman"><span
style="font-size: 12pt;">sound technical
approaches</span></font></font><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 13pt;">” available at all?</span></font><br>
</blockquote>
I'm all in favour of replacing SDP, but would not like
to require that before we can produce any output from
this group.<br>
<br>
Justin's idea of sorting out what information we need
and specifying how that maps into SDP (just like is
currently done by Jingle) might be a reasonable
approach that can allow us to not fossilize SDP's
misfeatures forever.<br>
<br>
Harald<br>
<br>
<br>
</div>
</div>
_______________________________________________
RTC-Web mailing list
<a moz-do-not-send="true"
href="mailto:RTC-Web@alvestrand.no" target="_blank">RTC-Web@alvestrand.no</a>
<a moz-do-not-send="true"
href="http://www.alvestrand.no/mailman/listinfo/rtc-web"
target="_blank">http://www.alvestrand.no/mailman/listinfo/rtc-web</a>
</div>
<br>
_______________________________________________<br>
RTC-Web mailing list<br>
<a moz-do-not-send="true"
href="mailto:RTC-Web@alvestrand.no">RTC-Web@alvestrand.no</a><br>
<a moz-do-not-send="true"
href="http://www.alvestrand.no/mailman/listinfo/rtc-web"
target="_blank">http://www.alvestrand.no/mailman/listinfo/rtc-web</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>