[MMUSIC] Review of draft-saito-mmusic-sdp-ike-06

[Eric Rescorla <[e-mail]>]

This document describes a mechanism whereby a SIP/SDP exchange can
be used to kick off an IPsec association. The idea seems to be
that I have the AOR for some machine behind a NAT or a firewall
and I want to set up an IPsec tunnel. So, I use SIP address
resolution and then SIP to signal to it and then set up an
IPsec SA as if it were a media connection.


GENERAL COMMENTS
1. Use Cases
When I reviewed this document back in 2007, I was sort of
lukewarm on it. The authors list some use cases, but I don't
find them that convincing:

   o  Sharing media using a framework developed by Digital Living
      Network Alliance (DLNA) or similar protocols over VPN between two
      user devices.

   o  Remote desktop applications over VPN initiated by SIP call.  As an
      additional function of click-to-call, a customer service agent can
      access a customer's PC remotely to troubleshoot the problem while
      talking with the customer over the phone.

   o  Accessing and controlling medical equipment (medical robotics)
      remotely to monitor the elderly in a rural area (remote care
      services).

   o  Local area network (LAN)-based gaming protocol based on peer-to-
      peer rather than via a gaming server.

My skepticism is that setting up a VPN for applications like this
seems like overkill. VPNs have a bunch of ancillary security
implications that aren't really necessary for these applications.
It's important to remember that IPsec provides not only a network
connectivity function but also a firewalling function.  (RFC 4301 S 2.1),
and I worry that we're confusing these two to some extent. Consider
the last case, the gaming system. In this case, we don't want to
open a generic VPN connection, we want to open a connection directly
to the gaming up. Why is IPsec a good mechanism here? The
other examples seem to raise the same issue.


2. Coordination Of Multiple Elements
This brings me to another issue, the tight coordination required
between multiple elements on the home network. Again, in the
gaming setting, we have:

  - The IPsec Security Policy Database (SPD)
  - The user's SIP stack (e.g., softphone)
  - The gaming app which is consuming the traffic

As I understand the current proposal, what has to happen here is:

- A call comes into the SIP stack
- The SIP stack somehow notifies the gaming app (or maybe it
  has preexisting policy)
- The gaming app agrees to accept the connection
- The gaming app then generates the appropriate SPD entry(s)
- The gaming app notifies the SIP stack that it's OK
- The SIP call is accepted
- ICE is run to establish connectivity
- The IKE stack runs to set up the IKE channel.

This seems like a heck of a lot of interlocking pieces to set up what's
basically an app-to-app connection. Of course, you could also put
the SIP stack into the gaming app, but that's ridiculously heavyweight
for this purpose.

I should also mention that in terms of implementation complexity,
ICE seems like a real problem. The issue here is file descriptor
and channel management. The obvious way to implement an ICE stack
(and the way that mine works) is that the stack opens socket(s)
locally and then presents an abstraction to the application which
it can then use to read and write on. However, in this case, we
have three separate pieces of code (and probably execution contexts)
which all need to send/receive data on the same socket:

- The ICE stack
- The IKE stack
- The IPsec stack

And the demultiplexing between these is data dependent. Doesn't this
mean that we'll need a central dispatcher process whose job it is
to hand off the packets to each other module? I'm having trouble
visualizing this being something people are willing to implement.


3. Security Model
As I understand it, the way that this system is intended
to work is that the home system has an ACL indexed by remote
AOR. If a SIP call comes through allegedly from a permitted AOR
(via RFC 4474) it allows the VPN connection to be established.
That seems to place a very large amount of trust in the SIP
proxy. In essence you're giving the SIP proxy the keys to your
firewall. I can't really see any circumstances in which I would
be willing to do that.

By contrast, classic IPsec/SSH/SSL VPNs rely on credentials
that are immediately on the the remote side. That seems far
more secure. 

I am also concerned about the fairly loose coupling between the
authentication at the IKE layer and the firewall hole punching.
As I understand it, the SIP/ICE system doesn't do any authentication
at all: it just punches a hole and then propagates the packets to
the IKE/IPsec system without looking at them at all. I don't
see any immediate way to exploit this, but it's not clear to me
that it's safe either.


4. Multiplexing
Why are you using the same channel for IKE and IPsec tunnelling?
IKE supports multiple media channels. This seems like an architectural
issue, which is why I have it in general comments.


5. Grammar/Writing
This document has a lot of writing/grammatical errors. It really
needs a copy-edit pass.


DETAILED COMMENTS
TECHNICAL
S 3.
I'm not sure I understand what information the remote host/app
has. Is it going to be making calls to my ordinary SIP AOR or
to some specialized AOR connected to the app...

   Forking to multiple registered instances is outside the scope in this
   use case, so there is only one registered instance for each side.

How do you guarantee this? See above about which AOR...

S 4.
This set of definitions seems clumsy. How do I know if I should be
establishing ike-esp or ike-esp-udpencap? Should I be establishing
two media channels in parallel?

S 8.2.
This PSK mechanism seems to introduce a weakness not present in 
the original IKE-PSK spec: in RFC 4306, you only do the PSK exchange
over an encrypted channel established via a DH exchange. That means
that an attacker must actively intercept the channel in order to
mount a dictionary attack on a PSK which is actually a password.
Sending a PSK hash enables an attack by any attacker who can 
see the data on the SIP channel. 

Why are you allowing MD2 and MD5?



EDITORIAL
Abstract:
   This document specifies how to establish secure media sessions over a
   virtual private network using Session Initiation Protocol for the
   purpose of on-demand media/application sharing between peers.  It

You're not establishing a secure media session over a vpn, right?
You're establishing a media session to use a vpn over.


S 2.2.
      SIP has a cross-NAT rendezvous mechanism, such as ICE
      [I-D.ietf-mmusic-ice].  This effective function can be used for

"such as ICE"? SIP *is* a cross-NAT rendezvous mechanism. ICE
is a mechanism for opening ports through the NAT. Also, since
this is the only IETF mechanism "such as" seems weird.


   specifies the method to exchange the fingerprint of a self-signed

specifies a method

-Ekr