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

[Makoto Saito <[e-mail]>]

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

Dan Wing wrote:
>  
> 
> 
>>-----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
> 

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