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

[Eric Rescorla <[e-mail]>]

At Tue, 22 Dec 2009 00:36:49 +0900,
Makoto Saito wrote:
> > 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.
> 
> Actually, joining the same local network makes DLNA perform very
> effectively.
> 
>   We are particularly focusing on LAN-based applications
> so that it is not necessarily an overkilling to set up VPN for those
> applications. For example, DLNA is used to share private contents
> inside the LAN but it doesn't have sufficient security mechanisms
> for the use over the Internet. So we think VPN is a simple solution
> for that purpose. Anyway, we already have the implementation for
> this application and start to deploy them.

So, this likely is bad design by DLNA--the distinction between LAN and
WAN just isn't strong enough security-wise to support this. ISTM
better to fix this issue than to perpetuate it.


> > 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.
> 
> The demultiplexing process is simply a combination of existing
> demultiplexing processes of ICE and IKE-NAT-T. That is,
>     if bits 0..31 == 0, dispatch to IKE module
>     else if bits 32..63 == magic-cookie, and parsing packet yields
>        STUN fingerprint, dispatch to ICE module
>     else dispatch to IPsec module
> 
> Anyway, it is true that the combination of ICE and IKE/IPsec is
> complicated because ICE by its nature complicated. We don't think
> ICE should be a MUST in this specification. In fact the environment
> where we are deploying this we actually don't need ICE, but we
> foresee a need for ICE despite its complexity in different
> environment where this specification may be deployed.

I think you're missing my point, which is that intermixing 
IPsec packets with STUN/ICE/IKE packets requires a fairly
inconvenient system architecture.



> > 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. 
> 
> SIP proxy is not necessarily given a strong authority to
> establish a VPN into a home network.
> This draft does not eliminate other authorization or
> authentication that a user or an implementation might
> want to perform before bringing up the VPN.  For example,
> password authentication can be used in addition to what
> is described in the draft.  This is described in Section 8.

Wait, so I now need two separate authentication mechanisms
plus I have to worry about coordinating my firewall and IPsec
with the SIP authentication? This seems problematic.


> > 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.
> 
> I'm afraid that there is a misunderstanding here, and likely
> there is a text in the draft that is misleading.
> In our use cases, a home router is a SIP UA and it doesn't
> open a hole to the home network until IPsec tunnel is established.
> The holes which SIP/ICE try to open are on external routers such
> as a large scale NAT on ISP network. In either case, the home network
> never sees a packet until both SIP and IKE negotiations have completed
> successfully.

I'm not talking about the home network. I'm talking about the
interaction between the NAT/firewall on the home router
and the rest of the networking system on the same router.


> > 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.
> 
> RFC3947 and 3948 specify the method of IPsec NAT traversal and
> it uses the same channel for IKE and IPsec. We don't try to do
> anything special here.

Hmm... I'm surprised to hear that, but I guess if/when this goes up
for IETF LC the IPsec experts can weigh in if there is a problem.

-Ekr