> > -----Ursprüngliche Nachricht-----
> > Von: ext Dan Wing [mailto:[EMAIL PROTECTED]
> > Gesendet: Mittwoch, 20. August 2008 21:23
> > An: Schneider, Peter (NSN - DE/Munich); Tschofenig, Hannes
> > (NSN - FI/Espoo); [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Cc: sip@ietf.org
> > Betreff: RE: [Sip] Some comments on
> > draft-ietf-sip-dtls-srtp-framework-02
> >
> > > -----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: sip@ietf.org
> > > 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.
>
> The receiver chooses "passive" because he lives in an
> environment where a managed middlebox blocks the path before
> the SDP answer is transmitted (as described in
> draft-ietf-mmusic-media-path-middleboxes-01). Clipping will
> happen not because of the passive role, but because of the middlebox.
Yes, the clipping is caused by the middlebox. However, due to
the DTLS-SRTP handshake (2 round trips) the clipping for a
DTLS-SRTP session will be more user noticable.
> > 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?
>
> Sending the SDP answer in the first provisional response is a
> good idea and helps in the middlebox scenario. But this is
> not an alternative to allowing the receiver of the offer to
> take the passive role, but an addition. The receiver of the
> offer must have the passive role if he re-transmits "the 18x
> with the SDP answer until a DTLS Client Hello is seen", right?
I have an idea for another approach, which might even be better
than what is in the document right now: leave the DTLS client/server
roles as described in draft-ietf-sip-dtls-srtp-framework-02, and
when the offerer gets the 200 Ok, the offerer sends a DTLS
HelloRequest. This will open NAT bindings and cause an SBC
to 'latch' -- just like an ICE connectivity check would.
(If there are no middleboxes interfering with the media path,
the answerer would have initiated DTLS-SRTP by its own accord
by sending ClientHello message(s).)
> ...
> >
> > > 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.
> >
>
> The connectivity check is not sent by the SDP offerer in the
> draft, but by the answerer - but this is not relevant for my
> point, I think.
Here is the text from -02's Section 6.6, ("ICE Interaction"),
with a correction that is needed in one sentence. Other parts
of the document describe the offerer as having the passive role,
and Section 6.6, it is the offerer has the passive role and
that sends the connectivity check:
If ICE is not being used, then there is potential for a bad
interaction with SBCs via "latching", as described in
[I-D.ietf-mmusic-media-path-middleboxes]. In order to avoid this
issue, if ICE is not being used and the DTLS handshake has not
completed, upon receiving the other side's then the passive side MUST
^
"SDP answer"
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.
> > > (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?
> >
>
> Sorry, I have no diagram at hand. Let me explain better what
> I had in mind: The draft assumes some unmanaged NAT or
> firewall in this scenario, e.g. a residential one, close to
> the UA. IN ADDITION, there still can be the (managed)
> middleboxes described in
> draft-ietf-mmusic-media-path-middleboxes-01. Its them who may
> discard a STUN connectivity check and by this make the
> handshake as described currently stall.
Ok -- so a standard consumer VoIP box connected to a as-typically-deployed
SBC.
-d
_______________________________________________
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
