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-mmusic-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.
RSS Feed