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

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: EKR [mailto:[e-mail]] 
> Sent: Saturday, March 10, 2007 1:46 PM
> To: [e-mail]
> Subject: [MMUSIC] Review of draft-saito-mmusic-sdp-ike-00
> 
> $Id: draft-saito-mmusic-sdp-ike-00-rev.txt,v 1.1 2007/03/10 
> 21:57:28 ekr Exp $

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.

> 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?

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.

> 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.

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.

> Finally, my impression was that NATs weren't that great about
> 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,
> 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...

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

> -Ekr
> 
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mmusic

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