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

["Dan Wing" <dwing at cisco.com>]

> A couple of responses inline:
> 
> > The advantage of SIP over Dynamic DNS is explained in
> > slide 3 of 
> http://www3.ietf.org/proceedings/07jul/slides/sipping-11.ppt,
> > namely;
> <snip>
> >   * ability to delegate user authentication (identity) to a 
> >     3rd party (rely on SIP-Identity's signature rather than
> >     a meaningful subjectAltName).
> 
> You can already delegate authentication to a CA in IKE.  You're just 
> replacing the CA key with the Authentication Service's key.

To delegate authentication to a CA in IKE, you need a certificate
whose subjectAltName matches something that makes sense -- such
as being the hostname or username or friendly name.  This is what
we're trying to avoid.

> >   * hole punching.  RFC3497 won't work if both endpoints are behind
> >     NATs; RFC3497 only works if the IKE initiator is behind a NAT
> >     and the IKE 'server' (VPN concentrator, most typically) has a 
> >     public IP address and its IKE UDP port is not firewalled.
> 
> I'm not sure of the utility of this.  It's not like IKE uses a whole 
> bunch of different ports like RTP does 

RTP only needs one port, now-a-days (draft-ietf-avt-rtp-and-rtcp-mux).

> -- it's always on port 
> 500.  If you want to allow IKE, just open port 500.

IKE doesn't always have to run on 500, it could run on any port
you want.  And, certainly, if two hosts are behind their own
respective NATs and want to establish IKE between themselves
(and thereafter IPsec), it is very unlikely either of them will
get UDP/500 from their NAT.

RFC3974 (section 4) explains that using UDP/500 can, itself,
be problematic because IKE-aware NATs try to be overly helpful
but instead cause more problem for IKE.  

To your argument, though, DNS SRV records (in conjunction with
dynamic DNS) could also advertise a non-UDP/500 port.  However,
if you're behind a NAT, and you don't have NAT-PMP or UPnP,
it's difficult to keep that port open.  Existing SIP techniques
(SIP-Outbound) keep SIP signaling active, allowing a SIP-
initiated call to the device which can then, for that call,
open the pinholes through the necessary NATs.

> >   * re-use of existing SIP infrastructure, which takes advantage
> >     of the above features for VoIP, to deploy a new, 
> non-VoIP service
> 
> This is irrelevant -- "SIP infrastructure" includes DNS 
> infrastructure 
> (to support REFC 3693 routing), so if you've got SIP 
> infrastructure, you 
> might as well use the DNS.  And conversely, not using SIP (just DNS) 
> allows people who only have DNS to do the same redirection.

Dynamic DNS doesn't provide the same functionality.

> > draft-saito-mmusic-sdp-ike does not replace or supercede IKE,
> > so I don't understand what needs to be said.  Can you provide
> > additional guidance on what you'd like to see here?
> 
> Sure.  Section 4.4.3 of RFC 4301 defines the authorization 
> mechanism for 
> IPsec -- the Peer Authorization Database, or PAD.  The PAD 
> has entries 
> that contain:
> 1. An identifier or set of identifiers
> 2. Authentication protocol(s) (e.g. IKE, KINK)
> 3. Authentication method(s) (either X.509 or PSK)
> 4. Authentication data (either X.509 trust anchor or the PSK)
> 
> When an request for a new SA comes in (via IKE), the IPsec endpoint 
> checks (in order) that
> 1. The authenticated identifier (e.g. X.509 DN) has a PAD entry
> 2. The authentication parameters in the PAD match what actually 
> happened, e.g., the identifier was authenticated through IKE with a 
> certificate verified by the included trust anchor.
> 
> With respect to the first check, you need to specify how 
> identifiers are 
> derived from the self-signed certificate (i.e., where the SIP 
> identity needs to be placed)
> 
> Without more explanation, I'm not sure how you would handle 
> the second 
> check: You're obviously not using a PSK, and there's no trust 
> anchor to 
> verify a self-signed certificate.  You may want to look into the work 
> that the BTNS working group is doing.

Ok, thanks.

> > I only found one such discussion in section 2, Protocol Overview:
> 
> That paragraph seems to imply that the IPsec (Child) SA should be 
> terminated when the BYE request is accepted, and that any IKE 
> negotiations in process should be terminated.  (Note that it's the SA 
> that's discarded, not the policy!)  Is this what you meant to say?
> 
> If so, you need to address two issues:
> 1. IKE has its own mechanisms for negotiating SA lifetimes, so you'll 
> need to specify how to set IKE parameters to be compatible with this.
> 2. How should IKE SAs be handled?  Should they be terminated 
> on the BYE as well?

Yes, I don't see any reason to keep IKE active after the SIP BYE.

-d

_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic