Subject: [MMUSIC] ICE-19: Forking issue

From: "Rafael Kiel" <[email-masked]>
Date: Tue, 13 Nov 2007 11:13:02 +0200

Hi 

I think the standard needs to address the processing of STUN requests
("7.2 STUN Server Procedures") in case of forking in some more
descriptive manner.

Let consider the ICE session (Offerer) at the stage where the answer has
already arrived. Now, there is a STUN request received on one of the
local HOST candidates with username fragment which does not match any of
the usernames published by ICE peer in its answer. Apparently this STUN
request belongs to the different, probably "forked" ICE session whose
answer has not yet arrived. 

Currently the standard does not describe what needs to be done in this
situation. 

Regards,

Rafael

 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 13 Nov 2007 15:13:39 -0800

> -----Original Message-----
> From: Rafael Kiel [mailto:[email-masked]] 
> Sent: Tuesday, November 13, 2007 1:13 AM
> To: [email-masked]
> Subject: [MMUSIC] ICE-19: Forking issue
> 
> Hi 
>
> I think the standard needs to address the processing of STUN 
> requests ("7.2 STUN Server Procedures") in case of forking in 
> some more descriptive manner.
> 
> Let consider the ICE session (Offerer) at the stage where the 
> answer has already arrived. Now, there is a STUN request 
> received on one of the local HOST candidates with username 
> fragment which does not match any of the usernames published 
> by ICE peer in its answer. Apparently this STUN request 
> belongs to the different, probably "forked" ICE session whose 
> Currently the standard does not describe what needs to be 
> done in this situation. 

It can only partially validate the STUN request.  The partial
validation that it can perform is against its half of the
username (up to the ":").  If that matches, it knows it came
from a legitimate remote peer (or an attacker that is on the
signaling path or on the media path).  Only once the SDP 
answer arrives can it validate the second half of the 
username and validate the Message-Integrity, and send a 
STUN Response (using the password in the SDP Answer to 
create the Message-Integrity for the STUN Response).

This is already described in ICE,
http://tools.ietf.org/html/draft-ietf-mmusic-ice-19#section-7.2:

  "...
   The agent MUST
   consider the username to be valid if it consists of two values
   separated by a colon, where the first value is equal to the username
   fragment generated by the agent in an offer or answer for a session
   in-progress. 
   ...
   In cases where multiple STUN requests are received before 
   the answer, this may cause several pairs to be queued up 
   in the triggered check queue.
   ..."

-d

---

From: "Rafael Kiel" <[email-masked]>
Date: Wed, 14 Nov 2007 09:05:30 +0200

The Message-Integrity validation of the STUN request (as part of STUN
response generation) can and MUST be performed without the relevant SDP
answer. 

7.2 says:
"  If this happens, the agent MUST immediately generate
   a response (including computation of the mapped address as described
   in Section 7.2.1.2.  The agent has sufficient information at this
   point to generate the response; the password from the peer is not
   required. "

The STUN response utilizes the same password as the request did.

7.1.1.3 says:
"A connectivity check from L to R (and its
   response of course) utilize the username RFRAG:LFRAG and a password
   of RPASS."

My question is whether an offering agent has to create another ICE
session instance when it receives STUN request containing unknown
username fragment (different from the username fragment received in the
answer) or it has to wait till the relevant answer indeed arrives. 

Rafael

<-----Original Message-----
<From: Dan Wing [mailto:[email-masked]] 
<Sent: Wednesday, November 14, 2007 1:14 AM
<To: Rafael Kiel; [email-masked]
<Subject: RE: [MMUSIC] ICE-19: Forking issue

<> -----Original Message-----
<> From: Rafael Kiel [mailto:[email-masked]] 
<> Sent: Tuesday, November 13, 2007 1:13 AM
<> To: [email-masked]
<> Subject: [MMUSIC] ICE-19: Forking issue
<> 
<> Hi 
<>
<> I think the standard needs to address the processing of STUN 
<> requests ("7.2 STUN Server Procedures") in case of forking in 
<> some more descriptive manner.
<> 
<> Let consider the ICE session (Offerer) at the stage where the 
<> answer has already arrived. Now, there is a STUN request 
<> received on one of the local HOST candidates with username 
<> fragment which does not match any of the usernames published 
<> by ICE peer in its answer. Apparently this STUN request 
<> belongs to the different, probably "forked" ICE session whose 
<> answer has not yet arrived. 
<> 
<> Currently the standard does not describe what needs to be 
<> done in this situation. 
<
<It can only partially validate the STUN request.  The partial
<validation that it can perform is against its half of the
<username (up to the ":").  If that matches, it knows it came
<from a legitimate remote peer (or an attacker that is on the
<signaling path or on the media path).  Only once the SDP 
<answer arrives can it validate the second half of the 
<username and validate the Message-Integrity, and send a 
<STUN Response (using the password in the SDP Answer to 
<create the Message-Integrity for the STUN Response).

<This is already described in ICE,
<http://tools.ietf.org/html/draft-ietf-mmusic-ice-19#section-7.2:
<
<  "...
<   The agent MUST
<   consider the username to be valid if it consists of two values
<   separated by a colon, where the first value is equal to the username
<   fragment generated by the agent in an offer or answer for a session
<   in-progress. 
<   ...
<   In cases where multiple STUN requests are received before 
<   the answer, this may cause several pairs to be queued up 
<   in the triggered check queue.
<   ..."
<
<-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 14 Nov 2007 08:19:04 -0800

> answer) or it has to wait till the relevant answer indeed arrives. 

It can generate a response immediately.  

But it also puts the IP address and port (of that received STUN 
request) into its list of 'triggered checks'.  When the offering
agent receives the SDP answer, the offering agent begins doing 
its own connectivity checks, including its triggered checks.

-d