[RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?

[Bernard Aboba]

Given that people have been using workarounds to obtain IP addresses, the value of keeping this out of Javascript seems marginal. 

However, since the W3C will be handling APIs, not the IETF, this does raise the question of how issues like this will be coordinated.

Date: Thu, 3 Feb 2011 08:50:27 -0800
From: harald at alvestrand.no
To: juberti at google.com
CC: bernard_aboba at hotmail.com; rtc-web at alvestrand.no
Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?



  


    
  
  
    On 02/03/11 01:32, Justin Uberti wrote:
    
      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)?
    
    
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.

    
      

        On Wed, Feb 2, 2011 at 7:49 PM, Bernard
          Aboba <bernard_aboba at hotmail.com>
          wrote:

          
            
              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).  

              Date: Wed, 2 Feb 2011 16:09:48 -0800

              From: harald at alvestrand.no

              To: rtc-web at alvestrand.no

              Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a
              signaling protocol?
              
                

                  

                  On 02/02/11 11:19, Henry Sinnreich wrote:
                   Is there
                        some understanding on the list on how the IP
                        addresses in SDP can be reconciled with the USAF
                        RFC 3424?

                      
                  Nit: UNSAF, not USAF.

                   http://www.rfc-editor.org/rfc/rfc3424.txt
                        

                        

                        “...a process whereby
                          some

                             originating process attempts to determine
                          or fix the address (and

                             port) by which it is known - e.g. to be
                          able to use address data in

                             the protocol exchange, or to advertise a
                          public address from which it

                             will receive connections.

                          There are only heuristics and workarounds to
                          attempt to achieve this

                             effect; there is no 100% solution.  Since
                          NATs may also dynamically

                             reclaim or readjust translations,
                          "keep-alive" and periodic re-

                             polling may be required.  Use of these
                          workarounds MUST be considered

                             transitional in IETF protocols, and a
                          better architectural solution

                             is being sought.  The explicit intention is
                          to deprecate any such

                             workarounds when sound technical approaches
                          are available.”

                        
                  In our case, the answer that has proved workable is
                  called STUN.

                   

                        Obviously there is much more dead stuff in SDP
                        besides using the misleading IP addresses, but
                        this seems to be a deep architectural flaw.

                        There were some early attempts to do SDPng and
                        we know today much more:

                        http://tools.ietf.org/html/draft-ietf-mmusic-sdpng-07

                        

                        Why not replace SDP, since it deals only with
                        a/v codec negotiation with a more general,
                        standards based metadata approach?

                        For example including Web conferencing displays
                        and UI control capabilities.

                        Of course such a new approach must be easily
                        mapped to the existing global SIP VoIP
                        infrastructure. 

                        

                        Or are the no  “sound technical
                          approaches” available at all?

                  
                  I'm all in favour of replacing SDP, but would not like
                  to require that before we can produce any output from
                  this group.

                  

                  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.

                  

                                         Harald

                  

                  

                
              
              _______________________________________________
              RTC-Web mailing list
              RTC-Web at alvestrand.no
              http://www.alvestrand.no/mailman/listinfo/rtc-web
            
            

            _______________________________________________

            RTC-Web mailing list

            RTC-Web at alvestrand.no

            http://www.alvestrand.no/mailman/listinfo/rtc-web

            

          
        
        

      
    
    

  


_______________________________________________
RTC-Web mailing list
RTC-Web at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtc-web 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110203/67e8aec8/attachment-0001.html>