Subject: [MMUSIC] ICE-16 Comments

From: "Zingerle, Meinrad" <[email-masked]>
Date: Mon, 9 Jul 2007 09:32:50 +0200

#1)Section 4.2. states that a ICE-Lite agent should allocate 
 "one IPv4 candidate, one link local and one global IPv6 address".
 
Since a Router MUST NOT forward packets with a link-local source and/or
destination address (see RFC 3513, section 2.5.6 Local-Use IPv6 Unicast
Addresses) and RFC3484 prefers smaller scopes over larger scopes, I
guess the usage of link-local addresses in this context may be
problematic (each agent would have to check if its partner is really on
the same link).
Thus, I would suggest that an ICE-Lite agent allocates a link-local IPv6
address only in that case there is no IPv6 address of global scope
available. 
Or even disallow the usage of link-local addresses at since their
applicability in this context is very limited. 

#2) Section 8.2.2
    "... Two candidates are paired up when 
	they are for the same component, utilize the same transport
protocol
 	(UDP in this specification), and are from the same IP address
family
 	(IPv4 or IPv6)."
In my understanding addresses of local scope (e.g. IPv6 linl-local,
auto-configured IPv4 169.254.0.0/16) should not be paired with those of
global scope. 

#3)For clearness I would suggest to add the following sentence to
section 7.2. STUN Server Procedures
"The agent MUST include the USERNAME and MESSAGE-INTEGRITY attributes in
its responses to
 connectivity checks."
In my understanding that would be in line with
   "7.1.1.4. Forming Credentials
 	...
	Agent L included a username fragment of LFRAG for its
candidates, and
	a password of LPASS. Agent R provided a username fragment of
RFRAG
	and a password of RPASS. A connectivity check from L to R (and
its
	response of course) utilize the username RFRAG:LFRAG and a
password
	of RPASS. A connectivity check from R to L (and its response)
	utilize the username LFRAG:RFRAG and a password of LPASS."
and 
   "17.1. Attacks on Connectivity Checks (page 84, 2nd paragraph)
	... Fortunately, this attack is mitigated completely
	through the STUN message integrity mechanism. The attacker needs
to
	inject a fake response, and in order for this response to be
	processed, the attacker needs the password. ..."

#4) 7.2. STUN Server Procedures
    "...    It is possible (and in fact
	very likely) that an offerer will receive a Binding Request
prior to
	receiving the answer from its peer. If this happens, the agent
MUST
	generate a response (including computation of the mapped address
as
	described in Section 7.2.1.2
Is it correct that at time of receiving the Binding Request the agent
cannot send the response (due to lack of <ice-ufrag> and <ice-pwd> of
the answerer)? If so, I assume that the agent must not discard the
Binding request but store it (or even prepare the response) and send the
response as soon as the SDP answer (with <ice-ufrag> and <ice-pwd> of
the answerer) has been received, correct?
 	
Meinrad 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 09 Jul 2007 15:13:50 -0400

Thanks for the comments. Responses inline.

> applicability in this context is very limited. 

Right, good point. They can be used with full ICE since a connectivity 
check is performed to validate it. But not with ICE-lite since there may 
not be connectivity checks.

> auto-configured IPv4 169.254.0.0/16) should not be paired with those of

Hmm, well if two IPv6 hosts are on the same link, I believe one can send 
from its link local address to the global v6 address of the other host. 
So it should work in those cases. When it doesn't work, the ICE checks 
will fail. So I think it does make sense, in the case of full ICE at 
least (link locals are only used for full ICE per your above comment).

> 	processed, the attacker needs the password. ..."

This text has been reworked in its alignment with the newly revised and 
I think much clearer rfc3489bis. rfc3489bis fully specifies this short 
term credential mechanism, so ICE does not need to say anything about 
when to include these attributes.

> the answerer)? 

No, it can send a response. It has the username (copied from the 
request), and the password is its own password. I added a sentence to 
clarify this.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Zingerle, Meinrad" <[email-masked]>
Date: Wed, 11 Jul 2007 09:01:28 +0200

Jonathan,

thanks for your response. 
Just one remark regarding your answer to #3):
Section "10.1.2. Receiving a Request or Indication" of rfc3489bis says:
 "....
	o If the message does not contain both a MESSAGE-INTEGRITY and a
	  USERNAME attribute:
	  * If the message is a request, the server MUST reject the
request
	    with an error response. This response MUST use an error code
	    of 400.
	o If the USERNAME does not contain a username value currently
valid
	  within the server:
	  * If the message is a request, the server MUST reject the
request
          with an error response. This response MUST use an error code
          of 401.
  ..."
Thus, in case an agent receives a STUN Binding request before the SDP
answer containing the <ice-ufrag> of the answerer, I would expect that
the agent rejects this Binding request due to unknown username.
However, I think you have already a solution therefore ;-)

Regards,
  Meinrad

> Rosenberg, Jonathan wrote:
> 
> > #1)Section 4.2. states that a ICE-Lite agent should allocate  "one 
> > IPv4 candidate, one link local and one global IPv6 address".
> >  
> > Since a Router MUST NOT forward packets with a link-local source 
> > and/or destination address (see RFC 3513, section 2.5.6 
> Local-Use IPv6 
> > Unicast
> > problematic (each agent would have to check if its partner 
> is really 
> > on the same link).
> > Thus, I would suggest that an ICE-Lite agent allocates a link-local 
> > IPv6 address only in that case there is no IPv6 address of global 
> > scope available.
> Right, good point. They can be used with full ICE since a 
> connectivity check is performed to validate it. But not with 
> ICE-lite since there may not be connectivity checks.
> 
> > 
> > #2) Section 8.2.2
> > 	they are for the same component, utilize the same 
> transport protocol
> >  	(UDP in this specification), and are from the same IP 
> address family
> >  	(IPv4 or IPv6)."
> > auto-configured IPv4 169.254.0.0/16) should not be paired 
> with those 
> > of global scope.
> 
> Hmm, well if two IPv6 hosts are on the same link, I believe 
> one can send from its link local address to the global v6 
> address of the other host. 
> So it should work in those cases. When it doesn't work, the 
> ICE checks will fail. So I think it does make sense, in the 
> case of full ICE at least (link locals are only used for full 
> ICE per your above comment).
> 
> > 
> >

---

From: "Zingerle, Meinrad" <[email-masked]>
Date: Wed, 11 Jul 2007 11:37:03 +0200

Jonathan,

some question concerning ICE Restarts:

#1)If an agent has an active session ICE had been in use, and it
receives a re-INVITE with no SDP, the agent should generate an offer in
the same way as for an initial INVITE. Under the assumption that there
are no changes concerning the media streams and their local candidates,
may the agent use <ice-ufrag> and <ice-pwd> from the active session or
must it use new values for these attributes an restarting ICE overall?

#2)Is it correct that an agent has to restart ICE for a media stream
when it adds a new candidate - also in that case when ICE has not been
completed for that media stream? 
In other words: What happens if an agent receives a new candidate for a
media stream the ICE processing is already finished but restarting ICE
for that media stream is not requested by means of <ice-ufrag> and
<ice-pwd>?

#3) Is it correct that the receipt of an updated offer with no ICE
attributes would cause all ICE procedures to be stopped immediately?

#4) 9.1.1.1. ICE Restarts
     "...
	These rules imply that setting the IP address in the c line to
	0.0.0.0 will cause an ICE restart.   ..."

Why would 0.0.0.0 in the c-line cause an ICE restart (for this media
stream) an how would an agent receiving such a c-line handle it?
Note that this condition is not mentioned in section "9.2.1.1. Detecting
ICE Restart".

#5) 9.1.1.1. ICE Restarts
     "...
	To restart ICE, an agent MUST change both the ice-pwd and the
iceufrag
	for the media stream in an offer. Note that it is permissible
	to use a session-level attribute in one offer, but to provide
the
	same ice-pwd or ice-ufrag as a media-level attribute in a
subsequent
	offer.   ..."
Is it allowed to include a changed ice-pwd and a changed ice-ufrag at
session-level in an updated offer in order to restart ICE for all media
streams?  

#6) 9.1.2.2. Existing Media Streams with ICE Completed
     "...
	In addition, if the agent is controlling, it MUST include the
	a=remote-candidates attribute for each media stream whose check
list
	is in the Completed state. The attribute contains the remote
	candidates from the highest priority nominated pair in the valid
list
	for each component of that media stream.    ..."
I thought that in case the normal nomination algorithm is used the
controlling agent is free to select another than the highest priority
nominated pair in the valid list. Is that incorrect?

Regards,
  Meinrad

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 11 Jul 2007 08:47:07 -0400

inline.

> However, I think you have already a solution therefore ;-)

The text above says 'valid' and not 'unknown'. So ICE is careful about 
definition of validity:

<t>
The agent MUST use a short term credential to authenticate the request
and perform a message integrity check. 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. It is possible (and in fact very likely) that an offerer
will receive a Binding Request prior to receiving the answer from its
peer. If this happens, the agent MUST immediately generate a response
(including computation of the mapped address as described in
<xref target="sec-compute-mapped"/>. The agent has sufficient
information at this point to generate the response; the password from
the peer is not required. Once the answer is received, it MUST proceed
with the remaining steps required, namely
<xref target="sec-learn-peer-server"/>,
<xref target="sec-triggered"/>, and <xref target="sec-up-fav"/> for
full implementations. 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.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 11 Jul 2007 08:56:07 -0400

inline.

> must it use new values for these attributes an restarting ICE overall?

MUST restart. From Section 12.5:

<t>
The flows for continued operation, as described in Section 7 of RFC
3725, require additional behavior of ICE implementations to
support. In particular, if an agent receives a mid-dialog re-INVITE
that contains no offer, it MUST restart ICE for each media stream and
go through the process of gathering new candidates. Furthermore, that
list of candidates SHOULD include the ones currently being used for media.
</t>

this is required for 3pcc to work. It completely fails if you don't restart.

> for that media stream is not requested by means of <ice-ufrag> and

If ICE has finished and selected a candidate, but an agent somehow gets 
a new candidate (not sure how it would just 'get' one), it would need to 
do an ICE restart if it wants to try it out.

> attributes would cause all ICE procedures to be stopped immediately?

Yes.

> Note that this condition is not mentioned in section "9.2.1.1. Detecting

A change of the target causes an ICE restart. From the text immediately 
above:

<t>
An agent MUST restart ICE for a media stream if:
</t>

<list style="symbols">
<t>The offer is being generated
for the purposes of changing the target of the media stream. In other
words, if an agent wants to generated an updated offer which, had ICE
not been in use, would result in a new value for the destination of a
media component.
</t>

Since 0.0.0.0 is a new destination, an agent sending this has to restart 
ICE. Thats why usage of 0.0.0.0 for hold with ICE is a really bad idea.

> session-level in an updated offer in order to restart ICE for all media

Yes.

> nominated pair in the valid list. Is that incorrect?

Its free to select any valid pair it likes, yes. Once it does it sends 
an updated STUN check, with the nominated flag set. Thus, making it the 
only nominated pair in the valid list. The word 'nominated' is important 
in the above sentence.

-Jonathan R.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 11 Jul 2007 18:08:08 -0700

> If ICE has finished and selected a candidate, but an agent 
> somehow gets a new candidate (not sure how it would just 'get' 
> one),

You might be on WiFi and have the opportunity to switch to
another network (e.g., EDGE), which has a different IP 
address.  You would like to test connectivity with that 
new network's candidate address before abandoning the 
previous network connection.

-d

> it would need to do an ICE restart if it wants to try 
> it out.
> 
> >

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Jul 2007 08:59:55 -0400

OK. You can do that. When there is an ICE-restart, you continue using 
the old candidate and switch over only when the restart completes. This 
way there is no gap in media continuity during the restart.

-Jonathan R.