[MMUSIC] Review of draft-saito-mmusic-sdp-ike

[Richard Barnes <rbarnes at bbn.com>]

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.

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)

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.

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.

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.

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.

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.

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















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