Subject: [MMUSIC] Review of draft-saito-mmusic-sdp-ike-00

From: EKR <[email-masked]>
Date: Sat, 10 Mar 2007 13:46:13 -0800

$Id: draft-saito-mmusic-sdp-ike-00-rev.txt,v 1.1 2007/03/10 21:57:28 ekr Exp $

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.

There's no ladder diagram, but I think it looks something like
this:

Alice               Proxy                   Bob
-----------------------------------------------
INVITE (IP=A.B.C.D) ->  
Fingerprint=XXXX 
                         INVITE (IP=A.B.C.D) ->  
                         Fingerprint=XXXX 
                         
                        <-  200 OK (IP=W.X.Y.X) 
                               Fingerprint=XXXX 

<-  200 OK (IP=W.X.Y.X) 
       Fingerprint=XXXX 

<-------------  IKE exchange ----------------->

<=============== IPsec tunnel ================>

My first question here is what the use case for this technique
is. When would I want to set up a VPN to a machine behind a 
NAT?

That said, this draft seems to solve two problems:

1. Discovery of the current IP address of a given machine.
2. Using SIP to authenticate the certificates of the client
   and server as per comedia.

So, given that there is a use case for this, (1) seems legitimate.
(2) strikes me as not quite right, though. Under what circumstances
are you going to set up a VPN tunnel to a machine that you've never
talked to before? Surely you already have its public key or some
way of authenticating it. I would think this would go double for
the receiver. I'm not about to let someone set up a VPN tunnel
to me (especially since the claimed purpose here is NAT traversal!)
without knowing who they are. So, I'm not sure what the fingerprint
exchange buys you.

Finally, my impression was that NATs weren't that great about
passing IKE and IPsec in general. Aren't you going to want to
use ICE to establish that you have a clear channel. Actually,
while we're on the topic, wouldn't ICE need to establish not
only that UDP traffic can pass through (for IKE) but also
whether plain IPsec can pass or whether it needs UDP wrapping
I'm not actually sure that ICE can do that now...

-Ekr

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

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 11 Mar 2007 14:27:01 -0700

> -----Original Message-----
> From: EKR [mailto:[email-masked]] 
> Sent: Saturday, March 10, 2007 1:46 PM
> To: [email-masked]
> Subject: [MMUSIC] Review of draft-saito-mmusic-sdp-ike-00
> 

You may recall a presentation by Makoto Saito an IETF or two back,
which did something similar (it did the IPsec key exchange in SIP,
similar to sdescriptions).  At the microphone, you said the approach
wasn't reasonable.  This document provides a new approach that is
similar to comedia-tls and dtls-srtp.

> There's no ladder diagram, but I think it looks something like

It's not necessarily to a machine behind the NAT, but could also
be to the NAT itself (if the NAT itself implements 
draft-saito-mmusic-sdp-ike).  The idea being you could be on
the road with your fancy wireless device, could "call home"
(using draft-saito-mmusic-sdp-ike), and after the IPsec tunnel
is established with your NAT (or, if you prefer, with a device
that is behind your NAT), you can then interact with every 
device within your home as if you were at home ---- those
devices don't need to understand SIP or IPsec tunnels or 
any of that; they just need an IP stack.

> talked to before?
> Surely you already have its public key or some

For the use-case described in the draft, it's probably not 
necessary.  However, it's reasonable to expect there are other
use cases we haven't yet envisioned, and exchanging the fingerprint
seems valuable.

> passing IKE and IPsec in general.

They aren't, but that's what IPsec-over-UDP solves.  And if
draft-saito-mmusic-sdp-ike is implemented in the NAT device
itself (rather than in a device behind the NAT), this concern
is diminished.  Of course, the concern comes back if the ISP
is NATting their subscribers.

> Aren't you going to want to
> use ICE to establish that you have a clear channel.

Probably, but that's orthogonal.  The main goal of this 
specification is setting up IPsec using SIP.

> Actually,

No, ICE can't do that now, but a connectivity check would be
pretty useful to determine if you could do native IPsec or
if you needed to do IPsec-over-UDP or IPsec-over-TCP.

-d

---

From: Makoto Saito <[email-masked]>
Date: Tue, 13 Mar 2007 02:59:33 +0900

Thank you for the review.
As Dan said, this draft takes advantage of a mechanism of comedia-tls
and introduces the simple approach to establish VPN to some device
with IPsec.
Of course this idea could apply to IPsec-over-UDP, but the draft
deals with the simplest case for now.

-- 
Makoto Saito