Subject: Re: [dispatch] Charter Proposal

From: Shintaro Mizuno <[email-masked]>
Date: Mon, 8 Jun 2009 18:20:16 +0900

Dear DISPATCH Chair, ML members,

I've finalized the charter proposal for on-demand media/application
sharing.
Added milestone/deliverables section and some descriptions on the usage
of SIP, but most of the text remains the same.

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

 SIP/SDP will be used to negotiate parameters necessary to establish
IKE/IPsec such as IP address, port numbers and authentication
information of peers. Current deployment uses SIP also to manage IPsec
connection, e.g. use BYE to shut down media sessions for IKE/IPsec,
however, further discussions can be made to find out if there are
intrests or use cases in using SIP only as a rendezvous protocol.

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 be minor-updated to -05 to conform with this charter proposal)
 - 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.

Milestone/Deliverables:
 - Aug 09 Issue Internet-Draft
    (by updating "draft-saito-mmusic-sdp-ike-05")
 - Nov 09 Submit I-D to IESG for publication as an RFC (Informational)

--------------------------------------------------
Best Regards,
Shintaro

----------------------------------------
Shintaro MIZUNO
[email-masked]

NTT Information Sharing Platform Laboratories
NTT Corporation
----------------------------------------

---

From: Eric Burger <[email-masked]>
Date: Mon, 8 Jun 2009 06:38:20 -0400

Given the proposal is not really for an Internet standard, and the  
product is not a protocol or standards track document, why are we  
working on it here?

On Jun 8, 2009, at 5:20 AM, Shintaro Mizuno wrote:

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Shintaro Mizuno <[email-masked]>
Date: Tue, 9 Jun 2009 22:02:42 +0900

Mr. Burger,
 Thank you for the comment.

 We don't necessary see a need for a WG to be formed to document the  
informational document we have listed, the document is there to see if
the proposed way forward (informational document possibly
as an independent submission) for the document listed is on track or  
whether something should be done at the WG level.

 On the other hand, we believe that use of SIP similar to what we  
have done for VPN will likely to happen more. And on that point, we are
wanting to see whether IETF is interested in documenting a guideline
for dealing with application that's not voice or video. 
As written in the discussion point of the charter, the question is how
much should SIP be involved.

 1. Should SIP just be used as a rendezvous protocol and leave the  
rest of the negotiation to whatever application?
 2. Should SIP involve in management of the established session as it
does for audio/video?
 3. Should use of SIP not be standardized for peer to peer application 
beside audio/video?

Regards,
Shintaro

On Mon, 8 Jun 2009 06:38:20 -0400

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 9 Jun 2009 06:31:52 -0700

You may also want to consider HIP, since it solves NAT traversal for all application layer protocols, including SIP.

http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-07.txt

It also takes care of the IPv4 to IPv6 transition for endpoints, mobility and multi-homing.
Open source code is plentifully available for reference implementations.

http://www.ietf.org/html.charters/hip-charter.html

Henry

On 6/9/09 8:02 AM, "Shintaro Mizuno" <[email-masked]> wrote:

Mr. Burger,

Regards,
Shintaro

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 11 Jun 2009 09:05:16 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Henry Sinnreich
> Sent: Tuesday, June 09, 2009 6:32 AM
> To: Shintaro Mizuno; Eric Burger
> Cc: [email-masked]
> Subject: Re: [dispatch] Charter Proposal
> 
> You may also want to consider HIP, since it solves NAT 
> traversal for all application layer protocols, including SIP.
> 

Yes, I am aware of HIP's NAT traversal capabilities, as I 
encouraged its adoption of ICE methodologies.

> http://www.ietf.org/html.charters/hip-charter.html

There are always new protocols.  But it is often pragmatic to leverage the
investment of deployed protocols -- much like TCP which continues to evolve
even though SCTP and DCCP provide superior functionality, much like how IPsec
was originally intended for IPv6 but was then supported on IPv4, etc.

We are interested in using SIP for establishing VPN sessions in much the same
way that SIP has embraced TLS (RFC4572) and embraced file transfer (RFC5547).

-d

> 	> > Added milestone/deliverables section and some 
> descriptions on the 
> 	> > usage
> 	> > "Charter Proposal for on-demand Media/Application 
> Sharing between 
> 	> > peers
> 	> > over VPN"
> 	> >
> 	> > Intent:
> 	> > using popular LAN based communication tool such as 
> DLNA on devices 
> 	> > that
> 	> > are sitting at home, secure LAN (VPN) 
> establishments between these 
> 	> > user
> 	> > benifit from VPN connections when users attempt to 
> communicate 
> 	> > remotely.
> 	> >
> 	> > standard bodies, problem of establishing VPN 
> between these user 
> 	> > devices
> 	> > were that current standards for establishing VPN 
> didn't provide all 
> 	> > the
> 	> > As a result current deployment based on 
> "draft-saito-mmusic-sdp-
> 	> > ike-04"
> 	> > pc remotely to troubleshoot the problem customer is 
> facing from the 
> 	> > call.

---

From: Shintaro Mizuno <[email-masked]>
Date: Mon, 15 Jun 2009 19:50:19 +0900

Mr. Sinnreich,

 Besides the fact that SIP is a well-deployed infrastructure, we also think that SIP has an advantage for its capabilities to negotiate parameters using SDP offer/answer. In case of IKE, these parameters are, for example, authentication parameters (fingerprint of a certificate) and role of IKE sessions (e.g. server/client in remote access), which usually need to be exchanged previously by the peers.
 This enables IKE to be established in a peer-to-peer situation.

Best Regards,
Shintaro

On Thu, 11 Jun 2009 09:05:16 -0700