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.
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? 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.
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
(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.
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? 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 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
