> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Schneider, Peter (NSN - DE/Munich) > Sent: Wednesday, August 06, 2008 3:41 PM > To: Tschofenig, Hannes (NSN - FI/Espoo); > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: [email protected] > Subject: [Sip] Some comments on draft-ietf-sip-dtls-srtp-framework-02 > > 1) The draft currently states in section 5: > > " The endpoint MUST use the setup attribute defined in [RFC4145]. > The endpoint which is the offerer MUST use the setup attribute > value of setup:actpass and be prepared to receive a client_hello > before it receives the answer. The answerer SHOULD use > the setup > attribute value of setup:active and will send the > client_hello in > the media path." > > My proposal is to replace the last sentence by "The answerer MUST use > the setup > attribute value of setup:active or the setup attribute value of > setup:passive." > > With this, if the receiver takes up the active role, as recommended in > the original text, he can start the handshake and if the handshake has > been carried out successfully before the SDP answer, he can send > encrypted early media (before the SDP answer). Obviously, > with the usage > of self signed certificates, the offerer can authenticate the > origin of > the early media only retrospectively, after he has received the SDP > answer, which somewhat reduces the value of encrypting the > early media. > Early media as well as a handshake at that point in time will however > not work in an environment, where middleboxes are present > that will not > let traffic pass in the media plane before the answer has been sent. > > So if the receiver assumes such an environment, he may decide > to take up > the passive role. By this, the offerer will start the > handshake as soon > as he receives an answer, which would typically be close to the first > point in time at which the handshake messages will be able to pass the > middleboxes.
But this will cause an SRTP-enabled call to suffer user-noticable call setup delay (due to DTLS-SRTP handshake that needs to occur). This is the R-CLIPPING requirement from draft-ietf-sip-media-security-requirements. To avoid this clipping, we would need draft-ietf-sip-dtls-srtp-framework to require the SDP answer be sent reliably before 200 Okay -- perhaps using a technique similar to what ICE does to send SDP reliably in 18x messages. For DTLS-SRTP, this would mean re-transmitting the 18x with the SDP answer until a DTLS Client Hello is seen. Would that be acceptable? > I feel it's quite reasonable to do the handshake after offer > and answer > have been exchanged, because the offerer can check the fingerprint of > the certificate received in the handshake immediately; and he will not > accept encrypted media that may be sent by an attacker. So he is less > vulnerable to DoS. This does not allow encrypted early media to be > received, but is this so essential? There are some apparently-legitimate uses of early media, at least from the perspective of some network operators, to deliver things like "Than you for using <operator>", advertisements, colorful ringback (music as ringback), and so on. Brian did a great write-up of many scenarios in the (now expired) draft-stucker-sipping-early-media-coping-03.txt. I expect that SRTP offers will, for a looong time (perhaps forever), need to offer both RTP and SRTP (using draft-ietf-mmusic-sdp-capability-negotiation). Endpoints will have to figure out what they want to do with RTP that arrives before the answer. If attackers start taking advantage of this, endpoints will necessarily evolve to be more restrictive (only accept incoming RTP if the UDP port matches the SDP answer [thus requiring symmetric RTP], only accepting incoming SRTP if the the fingerprint matches, etc.); in order to reduce user-noticable call setup delay, this will also require reliably delivery of SDP answers before the 200 Ok. I view much of this as evolution. > In fact, accepting only encrypted > early media could be harmful, as it would prevent a caller to receive > e.g. an announcement that is sent by some server in the network that > only sends unsensitive announcements and therefore does not support > encryption at all. I suppose. Depends on if the worry is being attacked with spam or the worry is listening to RTP that 'the network' is attempting to deliver to the endpoint. > 2) With respect to unmanaged (e.g. residential) stateful firewalls the > draft currently states in section 6.6 that if ICE is not used and the > handshake could not be completed (until offer and answer have been > exchanged) > > "the passive side MUST > do a single unauthenticated STUN [I-D.ietf-behave-rfc3489bis] > connectivity check in order to open up the appropriate > pinhole. All > implementations MUST be prepared to answer this request during the > handshake period even if they do not otherwise do ICE." > > And later, in the message flow on page 13 and the respective > explanations it becomes obvious that the idea is that the > sender of this > STUN connectivity check in fact waits for an answer before he proceeds There is no choice: until the SDP answer arrives, the endpoint doesn't know the IP address or port to send a STUN connectivity check. > (although implementations must only *be prepared* to answer a > connectivity request - I wonder whether "be prepared" should rather be > removed from this sentence). However, if there are middleboxes on the > path that block the STUN connectivity check, an answer will > never come, > although the purpose of the connectivity check - to establish > a session > in the residential firewall and open it up for incoming traffic - may > already have been achieved. Could you draw a diagram of such a network, and the location of such a middlebox? > So instead of making the sending of the STUN connectivity check > mandatory in this situation, I propose rather to recommend that the > passive UA in the connection setup should try to make sure that a > firewall protecting the UA does not block the client hello > starting the > handshake. This could be done by STUN or other means. This is exactly > what is recommended also in > draft-ietf-mmusic-media-path-middleboxes-01, > section 7, REC #1. > > 3) More generally, I propose that the draft should mention possible > problems with middleboxes, and should advise implementors to > follow the > recommendations in draft-ietf-mmusic-media-path-middleboxes. > > 4) Concerning the possible sequence of messages used to establish > sessions that use DTLS-SRTP, the draft IMO should give clearer > recommendations. This is currently mostly treated in the section > "example message flow", which indeed explains two flows > currently. It is > unclear, to which degree this is normative, and what variants of such > flows would also be considered compliant to the draft. > > 5) Another topic where information is only given in the > example flows is > the treatment of RTCP. If RTP/RTCP multiplexing on a single > port is not > used, at which time should the handshake for RTCP be done - > immediately > after the handshake for RTP, so that sender reports could be sent for > early media? RTP early media (which isn't not SRTP), RTCP would be sent to whatever draft-ietf-mmusic-sdp-capability-negotiation said. > Or only after the SDP answer, when both sides know which > ports are used on both sides? This becomes even more complex, if > non-symmetric RTP/RTCP would be applied, which is not excluded in > draft-ietf-avt-dtls-srtp-02. I agree that draft-ietf-avt-dtls-srtp and/or draft-ietf-sip-dtls-srtp-framework do need to mandate symmetric RTP and symmetric RTCP. -d > I propose to describe these issues in a dedicated section. > > Peter > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
