Subject: [MMUSIC] Review of IKE/IPsec media description in SDP, draft-saito-mmusic-sdp-ike-05

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 9 Oct 2009 08:25:43 -0600

This is a partial review of an individual draft, Media Description for
IKE in the Session Description Protocol,
http://tools.ietf.org/html/draft-saito-mmusic-sdp-ike-05. Note that a
Security Directorate review has been requested via Tim Polk.

It is my understanding that this draft has been around for almost 3
years. Some operators have deployed applications based on the mechanism
described in the document.  

This review is done at the request of the authors who intend to request
publication as an informational RFC.  Additional reviews and comments
are welcome.

--- http://tools.ietf.org/html/draft-saito-mmusic-sdp-ike-05

--- Technical comments and questions

*         General questions

I'm not sure if all the points below need to be addressed in the
document but there are questions that popped up reviewing the draft:

o    Handling of provisional SIP responses:

Is there a need to mandate that the first response from the answering
entity should be a final response, and not a provisional response?  

If a provisional response is allowed, does it need to be sent reliably?

If the SIP UA sending the INVITE receives an unreliable provisional
response containing SDP, what does it do?

o    Handling of multiple SDP media lines

The draft should cover the cases where a Remote Client offers multiple
media lines, for example one with media format of "ike-esp" and another
with media format for an audio codec.

o    Forking

Can the INVITE be forked to multiple registered instances? Probably
doesn't make sense for this application -- so should you add text that
says there is only one registered instance?

If multiple registered instances are allowed, how is forking handled?

o    SIP session and VPN state sync?

There is little bit of text on page-8, para-2 on this but it prompts
more questions.

How does either the Remote Client or Home Router detect when an
established VPN fail? Is there a native "keep-alive" supported by VPN. 

Should the RFC 4028 "SIP session timer" extension be supported?

Is there any need to re-authenticate an established VPN, say if some
security association times out (i.e., can the Remote Client re-INVITE
the session)?

Basically, how are the SIP dialog and VPN states maintained
(independently, does a state change to a SIP termination state implies
the VPN is terminated, vice-versa).

*         Security comments and questions

The mechanism is based on the assumption that the SDP media description
is protected using encryption.  

You have text on page-5 section 1.2 as part of the "background" but it
would be good to call this out in the document, and create a specific
section on it.  It could take the form of an Applicability Statement
(see http://tools.ietf.org/html/rfc3325#section-1) to reinforce the
requirements that must be met in order for the solution to be of any
meaningful use.

On a different note, if the remote client and home router are
pre-configured with a shared secret or a certificate issued by a trusted
CA, is there a need to have a hash fingerprint in the SDP to identify
which certificate or secret to use?

*         Security - authorization and user authentication model

This is related to Page-5, para-2, Page-19 in Security Consideration and
other places in the document.

It is mentioned that SIP is used for name resolution and authorization.
It is unclear to me where it is described who is responsible for
ensuring that only authorized clients can use this mechanism to gain
access the Home Router.

Say there are three Remote Clients; RC-1, RC-2, RC-3, and three Home
Routers (in different homes); HR-a, HR-b, HR-c. And say that only the
following combinations are allowed for IKE: 

 RC-1 to HR-a

 RC-2 to HR-b

 RC-3 to HR-c

If RC-1 attempts to establish an IKE session with HR-2, who blocks it?
Based on what information in the SIP signaling or IKE exchange?

Basically, the model for service authorization needs to be explained in
more details.

In the scenario where service authorization is done by the "SIP cloud",
could the user behind the Remote Client be authorized to initiate an IKE
session independent of the terminating Home Router user? And could the
Home Router user authorize the IKE session independent of the initiating
RC user?  

Some text on this would help.

*         Page-5, para-6:

Do any of the RFC 4474 deficiencies discussed in DISPATCH affect this
document (e.g., issues related to B2BUA traversal)? For more info, see
http://tools.ietf.org/html/draft-rosenberg-sip-rfc4474-concerns-00.

*         Page-7 Section-2 Protocol Overview:

Comments on Figure-1, step 3:

This 3rd step says...

    "After SDP exchange, Remote Client (SDP offerer)

     initiates IKE with the SDP answerer to establish

     IPsec SA." 

This is not accurate, since the offer/answer negotiation can result in
either end initiating the IKE session.  Indicate the active role to
address this comment. 

*         Page-9, section-3 Protocol Identifier:

Given you are re-using the values of the "setup" attribute from RFC
4145, suggest being specific in the sentence below.

Change...

<  The semantics of "active", "passive", and "actpass" in the offer/

<  answer exchange is the same as the definition described in 4.1 of RFC

<  4145. 

To...

>   The semantics for the "udp-setup" attribute values of "active",

>   "passive", and "actpass" in the offer/answer exchange are the same
as 

>   that described for the "setup" attribute in 4.1 of RFC 4145, except
that

>   it applies to an IKE session instead of a TCP connection. 

*         Page-9, section-3 Protocol Identifier:

This section would benefit some rewrite to normatively define what each
new SDP parameter defines.

For example, paragraph 1 could define the new SDP attributes more
clearly:

This document defines two SDP media formats for the "udp" protocol under
the "application" media type, "ike-esp" and "ike-esp-udpencap":
        + "ike-esp" indicates that the media described is IKE for the
establishment of an IPsec security association as described in IPsec ESP
as specified in []... 
        + "ike-esp-udpencap" indicates that the media described is IKE
for the establishment of UDP encapsulation of IPsec packets through NAT
boxes as specified in []...

*         Page-12, section 5.2 Offer and Answer Exchange with ICE:

a) It would be good to add a few sentences to explain that the mechanism
that ICE specifies for keeping NAT bindings open for RTP & RTCP traffic
does work for UDP encapsulated IKE exchanges.

b) The use of "UDP session" in sections 5.2, 5.3 and other parts of the
document is improper.  There are UDP-based media sessions but there is
no such thing as a UDP session.  Consider rewording the sentences that
explain the needs to multiplex several types of UDP packets over the
same UDP ports, something like that.

*         Page 20, section 9 IANA Considerations

 This section must be written to ask IANA to register the attributes.

See the requirements in http://tools.ietf.org/html/rfc4566#section-8.2.8
and a good example in
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-
10#page-72 

--- Editorial and other comments

The document needs to be scrubbed for grammar errors, conversational
phrasing (e.g., "by the way..."), run-on sentences, etc.  I will send a
list of nits directly to the authors.

idnits 2.11.14 reports 4 warnings and 1 comment; check the results at
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-saito-mm
usic-sdp-ike-05.txt

Acknowledgment: David Hancock and Stuart Hoggan provided input into the
above review - many thanks to them.

Regards,

Jean-Francois as an individual contributor.