Subject: [Sipping] DTLS-SRTP / ICE and gating/latching policy controls

From: "Brian Stucker" <[email-masked]>
Date: Mon, 12 Nov 2007 00:06:05 -0600

There was some discussion about this over on the SIP list, but since
this is going to be submitted to SIPPING I'll start the discussion over
here.

The draft explains a couple of mechanisms (gating/latching) that can
complicate establishing an end-to-end media path, and hence has
interactions with media path signaling protocols like ICE or DTLS-SRTP.
It further goes into giving examples of such complications and gives a
few preliminary recommendations to dealing with these interactions.

If you're following the DTLS-SRTP threads, you'll want to give this a
look.

http://www.ietf.org/internet-drafts/draft-sipping-stucker-media-path-mid
dleboxes-00.txt

Regards,
Brian
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Fischer, Kai" <[email-masked]>
Date: Mon, 12 Nov 2007 11:30:42 +0100

Hi Brian,
thanks for discussing this problem in your draft.
By reading the text I have missed some discussions about the problems
and requirements to the signaling channel  part of media based key
management resp. DTLS-SRTP. Draft-fischl-sipping-media-dtls-03 proposes
to transport the certificate fingerprint as attribute in SDP to identify
the key that will be presented during the DTLS handshake. Integrity
protection of the signaling channel is achieved by RFC 4474, i.e. a
signature is formed about some SIP header fields and the complete body.
Since middle boxes acting as NAT entities manipulate the m and c lines
within SDP, a signature created on the path before the middle box will
be broken. Consequently, this would lead to the requirement, that the
middle box acting as outbound proxy is capable to act as Authentication
Service a la RFC 4474.

In Figure 4 Step 4 I think that the port in the m-line should be 50000
since the inbound port in the relay is also 50000.

Kai

> -----Original Message-----
> From: Brian Stucker [mailto:[email-masked]] 
> Sent: Montag, 12. November 2007 07:06
> To: Eric Rescorla; Hannes Tschofenig; Dan Wing; Francois 
> Audet; Fries, Steffen; Mary Barnes; Fischer, Kai; Elwell, John
> Cc: [email-masked]
> Subject: DTLS-SRTP / ICE and gating/latching policy controls
> 
> There was some discussion about this over on the SIP list, 
> but since this is going to be submitted to SIPPING I'll start 
> the discussion over here.
> 
> The draft explains a couple of mechanisms (gating/latching) 
> that can complicate establishing an end-to-end media path, 
> and hence has interactions with media path signaling 
> protocols like ICE or DTLS-SRTP. It further goes into giving 
> examples of such complications and gives a few preliminary 
> recommendations to dealing with these interactions.
> 
> If you're following the DTLS-SRTP threads, you'll want to 
> give this a look. 
> 
> http://www.ietf.org/internet-drafts/draft-sipping-stucker-medi
a-path-middleboxes-00.txt <http://www.ietf.org/internet->
drafts/draft-sipping-stucker-media-path-middleboxes-00.txt>

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 12 Nov 2007 12:32:40 +0100

Hi,
 
A small question for clarification.
 
Recommendation #2 talks about the media path being open before the
session has been established, in order to allow media plane signalling.
 
Does it recommend the MIDCOM agent to open the media path even before it
has received an SDP answer, or is it assumed that it will not happen
until the SDP answer has been received?
 
Regards,
 
Christer

________________________________

	From: Brian Stucker [mailto:[email-masked]] 
	Sent: 12. marraskuuta 2007 8:06
	To: Eric Rescorla; Hannes Tschofenig; Dan Wing; Francois Audet;
Fries, Steffen; Mary Barnes; Fischer, Kai; Elwell, John
	Cc: [email-masked]
	Subject: [Sipping] DTLS-SRTP / ICE and gating/latching policy
controls

	There was some discussion about this over on the SIP list, but
since this is going to be submitted to SIPPING I'll start the discussion
over here.

	The draft explains a couple of mechanisms (gating/latching) that
can complicate establishing an end-to-end media path, and hence has
interactions with media path signaling protocols like ICE or DTLS-SRTP.
It further goes into giving examples of such complications and gives a
few preliminary recommendations to dealing with these interactions.

	If you're following the DTLS-SRTP threads, you'll want to give
this a look. 

http://www.ietf.org/internet-drafts/draft-sipping-stucker-media-path-mid
dleboxes-00.txt
<http://www.ietf.org/internet-drafts/draft-sipping-stucker-media-path-mi
ddleboxes-00.txt>  

	Regards, 
	Brian

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 12 Nov 2007 10:23:11 -0600

That seems to be the case, but from my reading of the DTLS-SRTP draft,
it's not clear if the requirement to use RFC 4474 is in all cases or
only if a self-signed certificate is used. 

For instance, if you were to use RFC-3325 to make an anonymous call, you
know certain headers (and perhaps even portions of the SDP body if
you're to do media privacy) will be changed by a middlebox (i.e. the
proxy) such that the signature calculated by the endpoint may not be
correct in that case either.

Eric?

Regards,
Brian

> From: Fischer, Kai [mailto:[email-masked]] 
> Sent: Monday, November 12, 2007 4:31 AM
> To: Stucker, Brian (RICH1:AR00); Eric Rescorla; Hannes 
> Tschofenig; Dan Wing; Audet, Francois (SC100:3055); Fries, 
> Steffen; Barnes, Mary (RICH2:AR00); Elwell, John
> Cc: [email-masked]
> Subject: RE: DTLS-SRTP / ICE and gating/latching policy controls
> 
> Hi Brian,
> By reading the text I have missed some discussions about the 
> problems and requirements to the signaling channel  part of 
> media based key management resp. DTLS-SRTP. 
> Draft-fischl-sipping-media-dtls-03 proposes to transport the 
> certificate fingerprint as attribute in SDP to identify the 
> key that will be presented during the DTLS handshake. 
> Integrity protection of the signaling channel is achieved by 
> RFC 4474, i.e. a signature is formed about some SIP header 
> fields and the complete body.
> Since middle boxes acting as NAT entities manipulate the m 
> and c lines within SDP, a signature created on the path 
> before the middle box will be broken. Consequently, this 
> would lead to the requirement, that the middle box acting as 
> outbound proxy is capable to act as Authentication Service a 
> la RFC 4474.
> 
> In Figure 4 Step 4 I think that the port in the m-line should 
> be 50000 since the inbound port in the relay is also 50000.
> 
> Kai
> 
> Audet; Fries, 
> > Steffen; Mary Barnes; Fischer, Kai; Elwell, John
> > Cc: [email-masked]
> but since 
> > this is going to be submitted to SIPPING I'll start the discussion 
> > over here.
> > 
> that can 
> > interactions with media path signaling protocols like ICE or 
> > DTLS-SRTP. It further goes into giving examples of such 
> complications 
> > and gives a few preliminary recommendations to dealing with these 
> > interactions.
> > 
> give this a

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 13 Nov 2007 14:15:28 +0100

Hi,

>It is assumed that the MIDCOM agent open the media path for signaling
path at the earliest possible moment, but prior to the session being
established (if possible).

Well, "earliest possible moment" can mean different thing to different
people.

>The reason for this is because the UAS may begin sending signaling over
the media path to the UAC immediately upon receipt of the SDP offer
(when the offer is in the INVITE).

Shouldn't we recommend against such procedures?

>Waiting until 200 OK to open the gates would cause (at a minimum)
clipping in all cases. If there is a concern that the amount of policy
signaling would be too high because there is no best-
>effort service available by default between endpoints, then at a
minimum opening the gates upon receipt of the SDP answer is still
recommended.

In that case I think the document should indicate that.
	 
Regards,

Christer	 

		From: Christer Holmberg
[mailto:[email-masked]] 
		Sent: Monday, November 12, 2007 5:33 AM
		To: Stucker, Brian (RICH1:AR00); Eric Rescorla; Hannes
Tschofenig; Dan Wing; Audet, Francois (SC100:3055); Fries, Steffen;
Barnes, Mary (RICH2:AR00); Fischer, Kai; Elwell, John
		Cc: [email-masked]
		Subject: RE: [Sipping] DTLS-SRTP / ICE and
gating/latching policy controls

		Hi,

		Recommendation #2 talks about the media path being open
before the session has been established, in order to allow media plane
signalling.
		 
		Does it recommend the MIDCOM agent to open the media
path even before it has received an SDP answer, or is it assumed that it
will not happen until the SDP answer has been received?
		 
		Regards,
		 
		Christer

			Sent: 12. marraskuuta 2007 8:06
			To: Eric Rescorla; Hannes Tschofenig; Dan Wing;
Francois Audet; Fries, Steffen; Mary Barnes; Fischer, Kai; Elwell, John
			Cc: [email-masked]
			Subject: [Sipping] DTLS-SRTP / ICE and
gating/latching policy controls

			There was some discussion about this over on the
SIP list, but since this is going to be submitted to SIPPING I'll start
the discussion over here.

			The draft explains a couple of mechanisms
(gating/latching) that can complicate establishing an end-to-end media
path, and hence has interactions with media path signaling protocols
like ICE or DTLS-SRTP. It further goes into giving examples of such
complications and gives a few preliminary recommendations to dealing
with these interactions.

			If you're following the DTLS-SRTP threads,
you'll want to give this a look. 

			Regards, 
			Brian

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 14 Nov 2007 12:46:26 +0100

Hi, 

>There's no way to guarantee an ordering between the SDP 
>answer arriving at any particular node and the STUN check 
>following it unless you require a PRACK to be sent to your 
>SDP answer (if the offer were in the INVITE). ICE does not 
>require PRACK, and specifies that connectivity checks begin 
>upon receipt of an SDP offer for full implementations.

ICE specifies a hack (which I don't like, because it's partly due to
those kind of hacks things get messy and we end up with interop problems
- but that is another issue), where the provisional response is
re-transmitted even if PRACK is not used.

My point is that if the input we have is that gates are at least not
going to be opened before an SDP answer (or a preview of the answer) is
received I think we should recommend against defining procedures which
assume they are opened.

>5.  Receiving the Initial Offer
> 
>When an agent receives an initial offer, it will check if the offerer
>supports ICE, determine its own role, gather candidates, prioritize
>them, choose default candidates, encode and send an answer, and for
>full implementations, form the check lists and begin connectivity
>checks.
> 
>Sending signaling like this seems to be warranted to avoid 
>clipping problems. Perhaps you are concerned about sending 
>actual media packets? 

I am concerend about having to start passing data (no matter whether
it's media, STUN or some media-plane securtiy negotation messages)
without any kind of "indication" where the data will come from.

Regards,

Christer

> > 		To: Stucker, Brian (RICH1:AR00); Eric Rescorla; 
> Hannes Tschofenig; 
> > Dan Wing; Audet, Francois (SC100:3055); Fries, Steffen; 
> Barnes, Mary 
> > 		Does it recommend the MIDCOM agent to open the 
> media path even 
> > before it has received an SDP answer, or is it assumed that it will 
> > not happen until the SDP answer has been received?
> > 		 
> > 		Regards,
> > 		 
> > 		Christer
> > 
> > 
> > since this is going to be submitted to SIPPING I'll start the 
> > discussion over here.
> > 
> > 			If you're following the DTLS-SRTP
> > threads, you'll want to give this a look. 
> > 
> > 	
> a-path-mid

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 15 Nov 2007 00:32:25 -0600

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Wednesday, November 14, 2007 5:46 AM
> Steffen; Barnes, Mary (RICH2:AR00); Fischer, Kai; Elwell, John
> Cc: [email-masked]
> Subject: RE: [Sipping] DTLS-SRTP / ICE and gating/latching 
> policy controls
> 
> 
> Hi, 
> 
> answer arriving 
> >at any particular node and the STUN check following it unless you 
> >require a PRACK to be sent to your SDP answer (if the offer 
> were in the 
> >INVITE). ICE does not require PRACK, and specifies that connectivity 
> >checks begin upon receipt of an SDP offer for full implementations.
> 
> ICE specifies a hack (which I don't like, because it's partly 
> due to those kind of hacks things get messy and we end up 
> with interop problems
> - but that is another issue), where the provisional response 
> is re-transmitted even if PRACK is not used.

I wasn't referring to the use of STUN to replace PRACK, just that the
two are not tied formally together in a WG approved document.

> 
> My point is that if the input we have is that gates are at 
> least not going to be opened before an SDP answer (or a 
> preview of the answer) is received I think we should 
> recommend against defining procedures which assume they are opened.

I agree with your sentiment, but again, I don't see how this is possible
unless PRACK is mandated.

> >Sending signaling like this seems to be warranted to avoid clipping 
> >problems. Perhaps you are concerned about sending actual 
> media packets?
> 
> I am concerend about having to start passing data (no matter 
> whether it's media, STUN or some media-plane securtiy 
> negotation messages) without any kind of "indication" where 
> the data will come from.

RFC-4961 is only a BCP, so you don't really have a formal indication
where data is going to actually come from based off the SDP answer. Even
with ICE you wind up with peer reflexive addresses that are not
initially captured in the SDP. I don't think an SDP answer would satisfy
the need to provide a clear indication as to where data will come from.
Perhaps I'm missing something here?

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 14 Nov 2007 09:14:27 -0800

> without any kind of "indication" where the data will come from.

The username fragment, communicated in ICE's a=ice-ufrag, appears
in the STUN message, and can provide that indication.  This is what
I describe in draft-wing-session-auth-00.txt (now expired).  

Said another way: 

Today, the gating function has logic like this:

  if packet_source_address=sdp_answer && 
     packet_source_udp_port==sdp_answer {
    permit;
  } else {
    deny;
  }

Using ICE, the gating function could have logic like this:

  if packet_ice_uname_frag==sdp_offer_uname_frag {
    permit;
  } else {
    deny;
  }

-d

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 15 Nov 2007 00:40:16 -0600

> Sent: Wednesday, November 14, 2007 4:47 PM
> To: Dan Wing; Stucker, Brian (RICH1:AR00); Eric Rescorla; 
> Hannes Tschofenig; Audet, Francois (SC100:3055); Fries, 
> clipping 
> >>>problems. Perhaps you are concerned about sending actual media 
> >>>packets?
> >>
> >The username fragment, communicated in ICE's a=ice-ufrag, appears in 
> >the STUN message, and can provide that indication.  This is what I 
> >describe in draft-wing-session-auth-00.txt (now expired).
> >
> >Said another way:
> >
> There may be specific mechanisms (ICE etc) where it is 
> possible to get an indication by other means than SDP, but my 
> comment was more generic.
>  
> But, I see at least a couple of potential issues with your proposal:
>  
> First, it requires the gating function to be protocol aware, 
> in order to retrieve the needed information from the STUN messages.
>  
> Second, in case of forking the gating function would pretty 
> much have to pass STUN messages coming from any number of 
> destinations. The gating function may have different kind of 
> restrictions/limitations on how many early dialogs (or, at 
> least the amount of media plane traffic) it is willing to 
> allow at a certain point, and/or it may reserve different 
> amount of bandwidth depending on the number of dialogs, what 
> media plane traffic is expected on the media plane etc. The 
> gating function has no knowledge about the early dialogs 
> until it receives a provisional response.

Which is why I recommend that the gating function allow a nominal amount
of traffic for mechanisms like STUN to complete without requiring the
gating function to become protocol aware. Although arguably, because of
the way information is passed to these functions from the SIP layer,
they are, in effect, already protocol aware to some extent. The gating
function can be provided with clear direction as to what level of
bandwidth and QoS is necessary for this function based off of the
information gathered and conveyed to it by the MIDCOM agent. This can
also include charging rules that can be used to capture and threshold
the difference between ICE or DTLS-SRTP and fraudulent traffic.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 14 Nov 2007 09:14:27 -0800

Said another way: 

-d

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 15 Nov 2007 00:40:16 -0600

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 14 Nov 2007 23:47:00 +0100

Hi,

>  if packet_ice_uname_frag==sdp_offer_uname_frag {

There may be specific mechanisms (ICE etc) where it is possible to get an indication by other means than SDP, but my comment was more generic.

First, it requires the gating function to be protocol aware, in order to retrieve the needed information from the STUN messages.
 
Second, in case of forking the gating function would pretty much have to pass STUN messages coming from any number of destinations. The gating function may have different kind of restrictions/limitations on how many early dialogs (or, at least the amount of media plane traffic) it is willing to allow at a certain point, and/or it may reserve different amount of bandwidth depending on the number of dialogs, what media plane traffic is expected on the media plane etc. The gating function has no knowledge about the early dialogs until it receives a provisional response.
 
Regards,
 
Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Nov 2007 11:44:22 -0500

> From: Dan Wing [mailto:[email-masked]]
> Sent: Wednesday, November 14, 2007 12:14 PM
> To: 'Christer Holmberg'; 'Brian Stucker'; 'Eric Rescorla'; 'Hannes
> Tschofenig'; 'Francois Audet'; 'Fries, Steffen'; 'Mary Barnes'; 'Fischer,
> Kai'; 'Elwell, John'
> Cc: [email-masked]
> Subject: RE: [Sipping] DTLS-SRTP / ICE and gating/latching policy controls
>

But that's only good for ICE, whereas this should be a generic mechanism methinks. (especially since some portion the blocking devices we're talking about will break ICE regardless)

I suggest a new algorithm:
   if packet_intent == benevolent {
     permit;
   } else {
     deny;
   }

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 15 Nov 2007 09:23:29 -0800

> in order to retrieve the needed information from the STUN messages.

Yes, it requires awareness of STUN.  But I'm trying to see how
we might improve things from the current impasse.

> destinations.

It would only pass STUN messages that have the expected
'username' attribute.  STUN messages with different 
'username' attributes would be silently dropped (or ICMP'd,
whichever you prefer).

> The gating function may have different kind of 
> allow at a certain point,

As will the user agent itself.

> and/or it may reserve different 

A two-stage communication to the gating function could
resolve that.  For example, when the offer goes out, the
gating function is told the STUN username and 3-tuple.
The gating function allows incoming ICE connectivity 
checks to pass through, up to some reasonableness limit.

As provisional SDP answers arrive, they probably do not
need to be communicated to the gating function.  But if
there are enough to necessiate allowing a lot more STUN
checks to pass through the gating function, the gating
function could be told to allow more through; this works
reasonably well because the ICE endpoint will retry
failed connectivity checks.

When the 200 Ok SDP answer arrives, the gating function
is updated with that SDP answer's bandwidth, and the
gating function is told to immediately close down the
other pinholes it had opened for the other ICE
connectivity checks (if any).

-d