Subject: [MMUSIC] Requirements for IPsec Negotiation

From: Makoto Saito <[email-masked]>
Date: Mon, 11 Jul 2005 21:43:42 +0900

Hello everyone,

I submitted a new individual I-D which I think MMUSIC WG would be
a proper place to discuss.

You can get the I-D from the following URL.

http://www.ietf.org/internet-drafts/draft-saito-mmusic-ipsec-negotiation-req-00.txt

-------------------------------------------------------------------
Title	: Requirements for IPsec Negotiation in the SIP Framework
Filename: draft-saito-mmusic-ipsec-negotiation-req-00.txt
Abstract:

It is effective to connect the networked home appliances securely
using IPsec. Generally, such devices cannot have the rich
calculation resources, and may use the dedicated transport protocol
for the media session. The advantages of IPsec are that it doesn't
require the rich resources, and is independent of the upper layer
protocol. In other words, it is applicable to the various
applications. On the other hand, same as the typical usage of IPsec,
these network devices should be connected to each other only when
they need. Therefore it is desired they can generate the IPsec
connections dynamically. Considering above, it makes sense to take
advantage of SIP mechanism to build such framework.
This document describes the issues in applying IPsec dynamically to
the media session of the SIP application, and defines the necessary
requirements in order to solve them.
-------------------------------------------------------------------

Actually, I'm trying to use the SIP framework for various P2P
applications. And I'm aloso forcusing on the networked home
appliances.
Because such devices don't always have rich resources, and
various upper layer protocols will be used, I think it is
desirable to use IPsec for the security protocol.
But unfortunately, there is no specification meeting this requirement
now.
That's why I wrote the requirement I-D, and I'll be happy
if I can discuss this issues in MMUSIC WG.

Thanks,

-- 
--------------------------------------------------------
Makoto Saito

NTT Communications Corporation

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Mark Baugher <[email-masked]>
Date: Tue, 12 Jul 2005 08:09:14 -0700

Greetings,
    Thanks for posting this I-D, I think it is an interesting problem  
area.  I have some comments and will start with just two:  In the  
interests of brevity, I'll list the two comments that I think are most  
important.

1. The protocols used in a home network will carry licensed media works  
such as movies as well as personal data such as home movies.  In the  
former case, these media will use licensed systems such as DTCP/IP.   
For consumer electronics applications, moreover, I expect that DLNA  
protocols, such as UPnP will be the most common found on home networks.  
  For these reasons, I don't see much likelihood of your proposals being  
accepted at least in North America.  I can't speak for Asia or even  
Europe, but Sony Electronics plays a prominent role in the DLNA as does  
Philips, Samsung, and other consumer electronics vendors from around  
the world.

2. I really like the idea of running IPsec between every device on a  
home network.  Application security may also be useful for any-to-any  
communications (i.e. among devices on the home network or any network).  
  It might be that IPsec AH is the right protocol to use on the home  
network and simply rely on application-level encryption when an  
application determines that encryption is needed.  In either case, I  
don't see the need for application-layer signaling like SIP or anything  
beyond IPsec IKE, which gets triggered by a policy or two in the SPD.

Best regards, Mark

---

From: Makoto Saito <[email-masked]>
Date: Wed, 13 Jul 2005 18:08:02 +0900

Dear Mark,

Thank you very much for your comments.
I'll reply in-line.

> Philips, Samsung, and other consumer electronics vendors from around  

Actually the framework of DLNA is one of the promising method,
and I agree to use it inside the home network.
However so far, DTCP/IP seems to focus on inside the home network only,
and not to be designed for the communication via the Internet.
If there is the case that the outdoor terminal connects to the indoor
terminal, it may be similar to the concept of VPN remote access.
So I think it has some meaning to use IPsec for the security and use
SIP for resolving locations.
But anyway, I'm sorry, DRM may not be a proper example.
We wanted to express that home appliances often use the vendors'
dedicated protocols for their additional functions or services,
and such situation would remain.

> beyond IPsec IKE, which gets triggered by a policy or two in the SPD.

I also thought to use IKE, but it isn't sufficient if we think the
scenarios such as remote access to the home network, p2p communication
with friends via the Internet, and so on.
In such cases, it is difficult to configure SPDs of all the terminals
in advance.
In the SIP framework, the media protocol and IP addresses are
determined during the SDP negotiation, so that I thought it convenient
to set the proper SP dynamically and synchronously with that
negotiation.

Best regards,

Makoto Saito

---

From: Mark Baugher <[email-masked]>
Date: Wed, 13 Jul 2005 15:00:05 -0700

hi,

On Jul 13, 2005, at 2:08 AM, Makoto Saito wrote:

>> 1. The protocols used in a home network will carry licensed media 
>> works  such as movies as well as personal data such as home movies.  
>> In the  former case, these media will use licensed systems such as 
>> DTCP/IP.   For consumer electronics applications, moreover, I expect 
>> that DLNA  protocols, such as UPnP will be the most common found on 
>> home networks.   For these reasons, I don't see much likelihood of 
>> your proposals being  accepted at least in North America.  I can't 
>> speak for Asia or even  Europe, but Sony Electronics plays a 
>> prominent role in the DLNA as does  Philips, Samsung, and other 
>> consumer electronics vendors from around  the world.
>

Yes, I agree that SIP might have a role to play here and I think it can 
bring up TCP and UDP sessions up as well as RTP sessions.
> terminal, it may be similar to the concept of VPN remote access.

Yes, I agree.
> SIP for resolving locations.

There are potential security issues here because this 
location-resolution works through proxies that handle the signaling 
message.  If communications is not real time, then I'd recommend a 
two-step process of resolution followed by IKE.  Alternatively, IPsec 
could be configured through its Security Policy Database (SPD) to 
always run an IKE exchange prior to establishing a transport 
connection.  So when the SIP completes and a TCP or UDP connection 
commences, the first packet triggers an IKE transaction.  That's one 
way to do it, I think.
> and such situation would remain.

Yes I agree that DRM is a poor example.  But I have not seen too many 
video devices that don't accept camera input to handle the photographs, 
home movies, and other personal media belonging to the device user.  
Since people typically don't read licenses, a security system is better 
than a DRM system for personal information.  Thus, personal security 
(e.g. privacy) is a good example.
>>  communications (i.e. among devices on the home network or any 
>> network).   It might be that IPsec AH is the right protocol to use on 
>> the home  network and simply rely on application-level encryption 
>> when an  application determines that encryption is needed.  In either 
>> case, I  don't see the need for application-layer signaling like SIP 
>> or anything  beyond IPsec IKE, which gets triggered by a policy or 
>> two in the SPD.
>
> scenarios such as remote access to the home network,

I'd expect that an IPsec VPN would be useful to this and so would IKE.

> p2p communication
> with friends via the Internet,

I don't know if IPsec is the right type of security for this kind of 
application.  We have found application-layer (SRTP) to be better 
suited than IPsec for many telephony applications.

> and so on.

I think there is a place for IPsec, particularly in associating devices 
within a household or home network, including mobile access.  And there 
is a place for application-layer security, particularly when 
communicating through servers and to groups, when special compression 
is needed, etc.

Mark

---

From: Makoto Saito <[email-masked]>
Date: Thu, 14 Jul 2005 15:28:09 +0900

Dear Mark,

> could be configured through its Security Policy Database (SPD) to always 
> run an IKE exchange prior to establishing a transport connection.  So 
> when the SIP completes and a TCP or UDP connection commences, the first 
> packet triggers an IKE transaction.  That's one way to do it, I think.
> 

Yes, I also think that's the one way.
I think if the location-resolution is unreliable, at least we must use
the reliable key-exchange.
In such a meaning, IKE can be used or extended MIKEY might be also applied.
And, if there is the assumption that real time communication is needed
and SDP is protected, I think the method of Security Descriptions I-D
can be used. Is that right?

> (e.g. privacy) is a good example.

Indeed. I'd like to replace the DRM example with it. Thank you.

> application.  We have found application-layer (SRTP) to be better suited 
> than IPsec for many telephony applications.
> 

I agree. I don't want to upset the present mechanism.
I just think the case that two terminals establish a lot of media
except RTP at the same time. In such a case, it seems easy to establish
the IPsec tunnel simply rather than preparing the security methods
for each media respectively.

> communicating through servers and to groups, when special compression is 
> needed, etc.
> 

Certainly. A place for IPsec might be the case such as launching
p2p-vpn tunnel taking advantage of SIP mechanism.

Best regards,

Makoto Saito

---

From: Mark Baugher <[email-masked]>
Date: Thu, 14 Jul 2005 05:28:24 -0700

hi

> can be used. Is that right?

Anytime you use SIP, you may use SDP security descriptions, which is 
comparable to MIKEY in terms of identification and authentication 
techniques.
>> video devices that don't accept camera input to handle the 
>> photographs, home movies, and other personal media belonging to the 
>> device user.  Since people typically don't read licenses, a security 
>> system is better than a DRM system for personal information.  Thus, 
>> personal security (e.g. privacy) is a good example.
>
>>>> 2. I really like the idea of running IPsec between every device on 
>>>> a  home network.  Application security may also be useful for 
>>>> any-to-any  communications (i.e. among devices on the home network 
>>>> or any network).   It might be that IPsec AH is the right protocol 
>>>> to use on the home  network and simply rely on application-level 
>>>> encryption when an  application determines that encryption is 
>>>> needed.  In either case, I  don't see the need for 
>>>> application-layer signaling like SIP or anything  beyond IPsec IKE, 
>>>> which gets triggered by a policy or two in the SPD.
>>>
>>>
>> I think there is a place for IPsec, particularly in associating 
>> devices within a household or home network, including mobile access.  
>> And there is a place for application-layer security, particularly 
>> when communicating through servers and to groups, when special 
>> compression is needed, etc.
>

hm.  I don't know why an invitation protocol is necessarily the best 
way of launching a vpn tunnel.  As I said above, I think this can be 
done using existing mechanisms, such as the SPD method for IPsec.

cheers, Mark

---

From: Makoto Saito <[email-masked]>
Date: Fri, 15 Jul 2005 11:34:34 +0900

Dear Mark,

> 
> hm.  I don't know why an invitation protocol is necessarily the best way 
> of launching a vpn tunnel.  As I said above, I think this can be done 
> using existing mechanisms, such as the SPD method for IPsec.
> 

Of course the method of static SPD which always triggers IKE is a
possible approach.

On the other hand, the presupposed application uses SDP negotiation anyway.
Therefore if necessary IPsec SAs were ready at the same time
the negotiation succeeded, it would realize the speedy start
of media transaction (and we may reduce the implementation of IKE).

And second, the application wants to judge the authentication
and control the security. Therefore it makes sense to merge
the SDP (which will include the identity information of the peer)
with IPsec configuration. If using IKE, we have to transmit the
identity information to IKE. It may be the certificate, or pre-shared
key, or any other methods particular to the application.

By the way, I have a little question about using the SPD-IKE approach.
If SPD always launches IKE, even the trivial packets other than
the media generated by SIP boot the IKE transaction?
If so, I'm afraid of overusing IKE that may be unnecessary as a result.

I don't deny the SPD-IKE approach itself, on the other hand,
from above reasons we wish the approach based on SIP, too.

Best regards,

Makoto Saito