Subject: [Sipping] VPN session established by SIP

From: YOSHIKAWA Tomoyuki <[email-masked]>
Date: Fri, 13 Jan 2006 17:07:30 +0900

Hello All,

I'd like to establish VPN session by using SIP control.
I think it is very convenient the establishment of Virtual Private
Network (VPN) through some NAT equipments under-controlling by Session
Beorder Controller of SIP.
In the establishment of VPN by SIP,
there might be the SIP level security mechanism and VPN own level
security mechanism. 

Are there some mechanism of establishing VPN sessions
such as L2TP or PPTP by SIP already?
I'd like to make a document if there isn't 
document about such kind of mechanism.

Or Making VPN by SIP mechanism might be enhancing
concerning SDP description as like as RFC2848(PINT Service)?
 exam:  m=application 42124 udp l2tp
        a=fmtp:l2tp protocol=ppp,role=client

Please let me know your comment.

Does this topic match to the mmusic mailing list more?
I apologize if this subject is off-topic for this mailing list.

Best regards,
------
YOSHIKAWA Tomoyuki <[email-masked]>
NEXT GENERATION NETWORK STRATEGY
RESEARCH AND DEVELOPMENT CENTER
NETWORK BUSINESS HEADQUARTERS
NTT EAST

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Jan 2006 08:19:56 -0500

There is no specification for this. SIP has been designed for 
establishment of communications sessions, not really for VPN establishment.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Dean Willis <[email-masked]>
Date: Fri, 13 Jan 2006 14:10:39 -0600

Jonathan's right, of course.

But . . .

Y'all are going to keep thinking I'm crazy, but I kind of like this  
idea.

SIP establishes communications sessions, especially for multimedia  
communications.

What could possibly be more of a "multimedia communications session"  
than an end-to-end IP tunnel (possibly encrypted) is? And what is a  
VPN but a a tunnel (possibly encrypted) with some routing information  
attached to it?

Now, as I see it, one doesn't need any change to SIP. A tunnel is  
just another flow, not all that different from an RTP stream, between  
one or more contacts. All that one would really need would be a way  
to describe the tunnel characteristics in a negotiable way. Defining  
SDP for the tunnel might provide a way to do this. And that would be  
done by MMUSIC, I believe. Describing the routing information might  
get a little tricky, but it would be an interesting research project.  
I believe a basic address-pair in the autoconfiguration range with a / 
30 mask could be exchanged in a fairly straightforward way,  
completely consistent with offer-answer.

Thinking about this some more, we're basically talking SIP to set up  
a wide-area zeroconf relationship across a dynamically created  
tunnel. SIP is providing the rendezvous mechanism and supporting the  
negotiation of session characteristics, which it does admirably.  
Application discovery within that relationship could then be handled  
by the zeroconf mechanism, or out-of-band. There may be a much better  
way to do all this, of course, but I don't know what it is right off- 
hand.

This would be SO handy for dealing with those folks who are trying to  
use complex architectures piled on top of SIP to prevent open end-to- 
end communications. Of course, they could still apply media policy to  
block any particular codec, but they MIGHT have to explain to  
regulators why they were choosing to block the tunnel codec. And that  
would be fun to watch.

--
Dean

On Jan 13, 2006, at 7:19 AM, Jonathan Rosenberg wrote:

>> security mechanism. Are there some mechanism of establishing VPN  
>> sessions
>> I'd like to make a document if there isn't document about such  
>> kind of mechanism.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 13 Jan 2006 16:37:53 -0500

My bet is that as soon as the Security Area Directorate hears of this 
they'll yell STOP! Anything that smacks of a substitute for IKEv2 won't 
go down at all well.

Dean Willis wrote:
> Y'all are going to keep thinking I'm crazy, but I kind of like this  idea.
> 
> than an end-to-end IP tunnel (possibly encrypted) is? And what is a  VPN 
> but a a tunnel (possibly encrypted) with some routing information  
> attached to it?
> 
> Now, as I see it, one doesn't need any change to SIP. A tunnel is  just 
> another flow, not all that different from an RTP stream, between  one or 
> more contacts. All that one would really need would be a way  to 
> describe the tunnel characteristics in a negotiable way. Defining  SDP 
> for the tunnel might provide a way to do this. And that would be  done 
> by MMUSIC, I believe. Describing the routing information might  get a 
> little tricky, but it would be an interesting research project.  I 
> believe a basic address-pair in the autoconfiguration range with a / 30 
> mask could be exchanged in a fairly straightforward way,  completely 
> consistent with offer-answer.
> 
> Thinking about this some more, we're basically talking SIP to set up  a 
> wide-area zeroconf relationship across a dynamically created  tunnel. 
> SIP is providing the rendezvous mechanism and supporting the  
> Application discovery within that relationship could then be handled  by 
> the zeroconf mechanism, or out-of-band. There may be a much better  way 
> to do all this, of course, but I don't know what it is right off- hand.
> 
>>> I'd like to make a document if there isn't document about such  kind 
>>> of mechanism.

---

From: Richard Shockey <[email-masked]>
Date: Fri, 13 Jan 2006 16:59:14 -0500

> Y'all are going to keep thinking I'm crazy, but I kind of like this idea.

So do I real "out of the box" thinking ..... especially if the tunnel 
eventually can carry the communication session.

You are right Dean... this would give certain nameless service providers 
who want to charge twice for net access, or are fond of deep packet 
inspection forms of packet routing something to think about.

The issue IMHO is not why but why not?

> more contacts. All that one would really need would be a way to describe 
> the tunnel characteristics in a negotiable way. Defining SDP for the 
> tunnel might provide a way to do this. And that would be done by MMUSIC, 
> I believe. Describing the routing information might get a little tricky, 
> but it would be an interesting research project. I believe a basic 
> address-pair in the autoconfiguration range with a /30 mask could be 
> exchanged in a fairly straightforward way, completely consistent with 
> offer-answer.
> 
> wide-area zeroconf relationship across a dynamically created tunnel. SIP 
> is providing the rendezvous mechanism and supporting the negotiation of 
> session characteristics, which it does admirably. Application discovery 
> within that relationship could then be handled by the zeroconf 
> mechanism, or out-of-band. There may be a much better way to do all 
> this, of course, but I don't know what it is right off-hand.
> 
> use complex architectures piled on top of SIP to prevent open end-to-end 
> communications. Of course, they could still apply media policy to block 
> any particular codec, but they MIGHT have to explain to regulators why 
> they were choosing to block the tunnel codec. And that would be fun to 
> watch.
> 
> 
> -- 
> Dean
> 
> 
>> --Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>> _

-- 

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Richard Shockey <[email-masked]>
Date: Fri, 13 Jan 2006 17:01:07 -0500

> they'll yell STOP! Anything that smacks of a substitute for IKEv2 won't 

Right, but how much of IKE have we seen deployed recently. This is the 
problem with 80% of the IETF security protocol suite ..they are so 
"elegant" and secure no one wants to deploy them.

--

---

From: "Patrick Melampy" <[email-masked]>
Date: Fri, 13 Jan 2006 17:01:33 -0500

I sort of like the idea of "proxying" a request to establish a VPN. This
would allow a VPN to be established between two parties ad-hoc.
Additionally, the parties could have mobility. Not sure why IPSEC would be
preferred over TLS.

For conference floor support and other reasons, TCP connections are being
proposed as part of a SIP established session. No reason TLS with mutual
authentication couldn't be used to establish the VPN using SIP. This should
work with ICE/TURN/STUN or Session Border Controllers -- as long as the TCP
connection can be established.

I'm sure the mutual authentication will meet the needs of the VPN.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tom-PT Taylor
Sent: Friday, January 13, 2006 4:38 PM
To: Dean Willis
Cc: [email-masked] List
Subject: Re: [Sipping] VPN session established by SIP

---

From: "Brijesh Kumar" <[email-masked]>
Date: Fri, 13 Jan 2006 18:07:02 -0500

From: "Tom-PT Taylor" <[email-masked]> wrote:

> they'll yell STOP!

Oh-  really. Let us see how loud they can shout :-)

I  presented a paper in just concluded IEEE CCNC 2006 (in parallel with much
talked about CES) in Las Vegas - " Mobility Support for Universal Plug and
Play (UPnP) Devices using Session Initiation Protocol (SIP)".

I actually used SIP not only as a tunnel set up protocol, but also as a data
transport protocol for transporting UPnP messages. It is actually a better
solution for mobile devices than porting IPSEC/IKE, L2TP and Mobile-IP or
whatever combo of tunneling protocols one can think  since SIP will be
readily available on 3G mobile devices.

Will it faint some sip purists, may  be. I hope their medical insurance
covers such instances ;-)

cheers,

--brijesh
----- Original Message ----- 
From: "Tom-PT Taylor" <[email-masked]>
To: "Dean Willis" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, January 13, 2006 4:37 PM
Subject: Re: [Sipping] VPN session established by SIP

idea.

---

From: Dean Willis <[email-masked]>
Date: Fri, 13 Jan 2006 21:56:35 -0600

> they'll yell STOP! Anything that smacks of a substitute for IKEv2 won't 

Of course they will. But nothing says that the endpoints, now that 
they've "found" each other using SIP, can't start an IKE exchange to set 
up keying for IPSEC. IKEv2 is about key management, not correspondent 
discovery. Or they can do a TLS VPN. Or even (watch more ADs explode) a 
VPN over MSRP relays.

I'd best stop now before they come to take me away.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 13 Jan 2006 21:59:24 -0600

> covers such instances ;-)

Ok, Brijesh. You just made me faint. Stop!

--
Dean

---

From: Richard Shockey <[email-masked]>
Date: Sun, 15 Jan 2006 18:49:33 -0500

> there might be the SIP level security mechanism and VPN own level

Yoshikawa-san

Despite the sometime strange responses on this list..I for one think 
your concept has considerable merit.

I for one, would be very pleased to see a ID on this subject.

I hope you have time to have something ready before Dallas.

Best Regards,

--

---

From: "Dale R. Worley" <[email-masked]>
Date: Mon, 16 Jan 2006 09:45:56 -0500

> discovery. Or they can do a TLS VPN. Or even (watch more ADs explode) a 

SIP seems to have two advantages here.  One is that the business drivers
will lead to it being widely deployed, with good interoperability, and
workable ways of dealing with NATs, firewalls, and other network
horrors, so piggybacking on SIP has a high probability of working out of
the box in any given situation.

The more technically pleasing advantage is that SIP does not apply any
packet-by-packet wrapper to the "session" data itself, so there's no
penalty relative to the "native" tunneling protocol.

I'm starting to visualize SIP bodies with content-type "application/ike-
setup"...

Dale

---

From: YOSHIKAWA Tomoyuki <[email-masked]>
Date: Tue, 17 Jan 2006 01:00:30 +0900

Hello all !

Thank you very much for your comments and feedbacks.

The "VPN" which I mention here and want to realize is solely
initialising the VPN as an application, and it doesn't mean to
realize the negotiation of several VPN parameters by means of SIP.

The example of VPN which I was thinking is L2TP.

I thought that it might be good idea to establish Packet Transport
(which is UDP path) for L2TP by means of SIP, and to function L2TP
Control Message or L2TP Data Message on this path.

In other words, I thought that the control negotiation of VPN was out
of the focus of SIP and authentication was also realized implicitly.

I just thought, based on the role of SIP, thus SIP can handle the
session and can also handle the VPN session homogeneously. 

Briefly, I think it is practical to establish a UDP-path by
SDP-negotiation, in order to use a VPN session.
(I don't think it is suitable to use a SIP for establishment of PPTP
session. Because that PPTP has not UDP or TCP port from a viewpoint of
NAPT traversal. It would make a complicated negotiation way.)

Unfortunately I am not familiar with IPsec or
IPv6 technologies right now.
But I personally think, it needs sophisticated and
slightly controversial specifications that negotiating
abilities for the establishment of IPsec are replaced with
SIP negotiation for the VPN session.

SIP is a protocol to establish SIP-Dialogue which has the status.
It is built a session which is negotiated by SDP-exchanging riding on
the SIP-Dialogue.

For a session established by SIP, I think that a RTP is commonly used,
but I also think with above mentioned explanation that a session riding
on a SIP-Dialogue is not only a RTP session.
I have understood that the protocol for a session riding on a
SIP-Dialogue is assigned by body parts of INVITE method of SIP.

For the summary, if it has two quality as followings, I think that it
is a suitable application which is handled by SIP protocol.

1. It should behave as a session.
     (if the Content-Disposition is session.)
2. It could be negotiated by SDP. (if SDP is used.)
   And it would behave as same as a RTP
   from a viewpoint of NAPT traversal.
     (It should have port number of TCP or UDP.)

So, I'd like to establish a L2TP VPN session
or a OpenVPN session by SIP.
A L2TP or a OpenVPN behave as an application
which works above a UDP session established by SIP. 
I think a L2TP or a OpenVPN are congruent with
above-mentioned qualities.

I would like to hear your opinion.
Thank you for your comments.

Best Regards,
------

---

From: 藤本 真吾<[email-masked]>
Date: Tue, 17 Jan 2006 09:58:29 +0900

Hello, Yoshikawa-san and other folks.

I am another one who think that SIP is useful framework to setup VPN.

Then my co-author, Saito-san and I submitted the Requirements Internet
Draft which proposed using SIP to setup IPsec VPN between end-users.

- draft-saito-mmusic-ipsec-negotiation-req-01
https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=13310

Since we just started to collect the requirements in MMUSIC-WG, we want
to share the ideas with SIP experts too.

I would appreciate your comments on our draft.

Best.

-- 
======================================
         SHINGO FUJIMOTO
    FUJITSU LABORATORIES LIMITED
E-mail: [email-masked]

---

From: Makoto Saito <[email-masked]>
Date: Tue, 17 Jan 2006 11:01:38 +0900

Hello Yoshikawa-san and all,

I'm the author of the draft indicating the method of
establishing IPsec session using SIP framework,
and as Shingo said, I also think it's a sufficiently possible
way to think of VPN as the session controlled by SDP.

Anyway, I think it needs more discussions, so I'd like
you to share your idea with MMUSIC WG, too.

Best regards,

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

Makoto Saito

NTT Communications Corporation