[dispatch] Charter Proposal

"Shintaro Mizuno" <mizuno.shintaro@lab.ntt.co.jp> Mon, 25 May 2009 21:58 UTC

Return-Path: <mizuno.shintaro@lab.ntt.co.jp>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 494E13A6A6A for <dispatch@core3.amsl.com>; Mon, 25 May 2009 14:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.11
X-Spam-Level: ***
X-Spam-Status: No, score=3.11 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8layFSsEjFio for <dispatch@core3.amsl.com>; Mon, 25 May 2009 14:58:56 -0700 (PDT)
Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id A31C03A67D2 for <dispatch@ietf.org>; Mon, 25 May 2009 14:58:52 -0700 (PDT)
Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id n4PM0V5b022823; Tue, 26 May 2009 07:00:31 +0900 (JST)
Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id E7A336603; Tue, 26 May 2009 07:00:30 +0900 (JST)
Received: from img.m.ecl.ntt.co.jp (img.m.ecl.ntt.co.jp [129.60.5.231]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id D0F136600; Tue, 26 May 2009 07:00:30 +0900 (JST)
Received: from gwras.ecl.ntt.co.jp (webras.ecl.ntt.co.jp [129.60.57.68]) by img.m.ecl.ntt.co.jp (8.13.8/8.13.8) with SMTP id n4PM0U4D016114; Tue, 26 May 2009 07:00:30 +0900 (JST)
Message-Id: <200905252200.n4PM0U4D016114@img.m.ecl.ntt.co.jp>
From: Shintaro Mizuno <mizuno.shintaro@lab.ntt.co.jp>
To: dispatch@ietf.org
X-Mailer: Html Mime Mail Class
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
MasGrpSmtpServerHost: img.m.ecl.ntt.co.jp
MasGrpSmtpServerPort: 25
MasGrpPolicyRtgTable: main
Date: Tue, 26 May 2009 07:00:29 +0900
Cc: ma.saito@nttv6.jp
Subject: [dispatch] Charter Proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 May 2009 21:58:57 -0000

Dear WG Chair, ML members,

We would like to propose the following charter for on-demand Media/Application sharing between peers over VPN.
We've been discussing on this topic with authors of "draft-saito-mmusic-sdp-ike-04" and we thought this WG would be suitable place for further discussion.

We appreciate any feedback.

---------
"Charter Proposal for on-demand Media/Application Sharing between peers over VPN"

Intent:
 The intent of this charter is to see interests in documenting what's being deployed as an informational for on-demand Media/Application sharing between peers over VPN using SIP and discuss what in the overall effort may be standardized at IETF in the future.


Problem Statement: 
 Home servers or network-capable consumer electronic devices are becoming widely deployed and people using such devices are wanting to share contents or applications and are seeking a way to establish multitudes of communication with each other.  

 In order to allow two people to share contents or application securely using popular LAN based communication tool such as DLNA on devices that are sitting at home, secure LAN (VPN) establishments between these user devices are necessary. 
 Applications that use proprietary or multi-session protocols such as in some of LAN-based gaming will also benifit from VPN connections when users attempt to communicate remotely.

 For a deployment that's underway and considered by several other standard bodies, problem of establishing VPN between these user devices were that current standards for establishing VPN didn't provide all the toolset necessary to overcome some of the obstacles. 

 Namely following issues were found;
  (1) Name resolution mechanism under floating IP addresses and port numbers
  (2) NAT traversal and hole-punching of firewall
  (3) Authentication/authorization of users.
  (4) Pre-sharing of key for establishing VPN isn't easy when VPN is to be established on-demand between two user devices without any previous affiliation.

As a result current deployment based on "draft-saito-mmusic-sdp-ike-04" and other standard bodies are looking at the use of SIP for the following reasons. 

 (1)Name resolution can be achieved by using REGISTER method and SDP negotiation
 (2)NAT traversal and hole-punching of firewall can be achieved by applying SIP+ICE.
 (3)Authentication/authorization can be achieved by having trusted SIP proxy and user friendly SIP-URIs.

Use-cases that may see use for such standard effort;
  - Media sharing using DLNA or similar protocol over VPN between 2 users' devices.
  - Remote desktop sharing for Customer service over VPN initiated via SIP call.
    * Similar to click to call, customer service agent can access user's pc remotely to troubleshoot the problem customer is facing from the call.
  - Accessing medical equipments(medical robotics) remotely and possibly controlling medical equipments to monitor elders in a rural area that (remote care services). 
  - LAN based gaming protocol to be established peer to peer rather than via gaming server.


Discussion Point:
 - To see interests in documenting what's being deployed based on "draft-saito-mmusic-sdp-ike-04" as an  informational document. 
http://tools.ietf.org/html/draft-saito-mmusic-sdp-ike-04
 - To see interests in standardizing toolset for realizing use-cases similar to what's mentioned above, even contemplating the possibility of defining a guideline for SIP usage where SIP is used only as a rendezvous  protocol.

------------


Best Regards,

Shintaro

-----------------------------
Shintaro Mizuno
NTT Information Sharing Platform Laboratories
NTT Corporation
mizuno.shintaro@lab.ntt.co.jp