[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

 

> -----Original Message-----
> From: Richard Barnes [mailto:rbarnes at bbn.com] 
> Sent: Monday, August 13, 2007 11:17 AM
> To: MMUSIC; SIPPING
> Subject: [Sipping] Review of draft-saito-mmusic-sdp-ike
> 
> Draft:  draft-saito-mmusic-sdp-ike-01
> Reviewer: Richard Barnes
> Review Date: 13 Aug 07
> 
> 
> General Comments:
> --------------------------------------------------------------
> ----------
> 1. This document seems to be doing two things: (1) Using SDP 
> carried in SIP to initiate an IKE session, and (2) Defining 
> how SIP Identity can be used in lieu of IKE authentication.

In *conjunction* with IKE authentication.  IKE authentication
still occurs, even with draft-saito-mmusic-sdp-ike -- very much
like comedia-tls (RFC4572) uses TLS for authentication and
also conveys the certificate fingerprint in SDP (a=fingerprint).

What the draft says is that instead of using certificates
for your identity assertion (a meaningful subjectAltName,
validation of the CA signature, and checking CRLs), you could
instead use SIP-Identity's assertion of identity.


> 1.1. With respect to signaling IKE in SIP/SDP:
>
> 1.1.1 What is this document trying to get out of SIP/SDP?   If it's 
> trying to get redirection to various IP addresses, there's 
> already the 
> DNS for that.  If it's trying to do NAT traversal, IKE already has 
> mechanisms for that. (RFC 3497)

The advantage of SIP over Dynamic DNS is explained in
slide 3 of http://www3.ietf.org/proceedings/07jul/slides/sipping-11.ppt,
namely;

  * Name resolution to a floating IP address (admittedly, this
    is also possible with DynDNS, as indicated in the slide).
  * ability to delegate user authentication (identity) to a 
    3rd party (rely on SIP-Identity's signature rather than
    a meaningful subjectAltName).
  * 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.
  * re-use of existing SIP infrastructure, which takes advantage
    of the above features for VoIP, to deploy a new, non-VoIP service

> 1.1.2.  SDP attributes defined by this document provide an incomplete 
> definition of the resulting traffic stream. The document doesn't say 
> anything about how IPsec traffic negotiated by this 
> mechanisms should be 
> handled.  As Ekr has pointed out, if you're going through NATs you'd 
> probably want to do something like ICE for IPsec or 
> encapsulating IPsec 
> in UDP.  Whatever the solution is, even if it's just doing 
> RFC 3947 NAT 
> traversal, this document should say how the negotiated IPsec traffic 
> should be carried.

I agree it should be clearer about what happens after IKE is 
negotiated, and if we switch to RFC3948 (IPsec-over-UDP) or try
to do plain IPsec (protocol 50).

> 1.2. With respect to re-using SIP Identity & self-signed certificates:
> 
> 1.2.1. The security model you're using here is not clear.  
> This document should describe in detail (referring to RFC 4474 
> and RFC 4306) how the two parties authenticate each other, both 
> at the SIP layer and at the IKE and IPsec layers.

Thanks.  We'll improve that.

> 1.2.2. This document does not address how the authenticated 
> identity is 
> connected to IPsec's authorization mechanism, i.e., the PAD.  
> RFC 4301 
> defines the contents of PAD entries, including specific sets of 
> acceptable identifiers, and acceptable authentication protocols and 
> mechanisms.  In order to use SIP identity to identify IPsec 
> peers, you 
> need to define how one constructs and retrieves the relevant 
> PAD entries.

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?

> 1.2.3. Likewise, the IPsec authorization process uses either 
> the remote 
> IP address or the content of the IKE ID payload as an identifier.  So 
> you'll need to fill the authenticated identity into the IKE 
> ID payload, 
> but you'll need to make sure this doesn't cause IKE 
> authentication to fail.

IKE still works as-is.

> 2. The document suggests several times a relationship between the 
> lifetime of the SIP-negotiated session, the lifetime of the IKE 
> exchange, and the lifetime of the IPsec SA.  Please clarify this.

I only found one such discussion in section 2, Protocol Overview:

   If the high-level application thinks a VPN session as the media
   session, it will discard the security policy and terminate IKE when
   that media session is terminated by BYE request. 

> 3. There's no reason to limit the mechanisms here to tunnel mode (and 
> hence no need to involve VPNs).  I think this can be mostly fixed by 
> changing instances of "VPN tunnel" to "IPsec SA".

That would be a worthwhile enhancement.  Thanks for suggesting it!

-d

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