Subject: [MMUSIC] Comments on ICE version 06

From: Magnus Westerlund <[email-masked]>
Date: Sat, 05 Nov 2005 20:28:55 +0100

Hi,

I have reviewed the draft and have a number of comments. I will divide 
them into technical and editorial ones. However the draft has made 
substantial improvement. I think we are almost there now. A few more 
minor details.

Technical:

T1. Section 7.1, last paragraph:
"   Once the allocations are complete, any redundant candidates are
    discarded.  A candidate is redundant if its transport addresses for
    each component match the transport addresses for each component of
    another candidate."

What is the procedure for when you get several transport addresses that 
are identical but different associated local addresses? With multiple 
address realms and same selection methods in the private address space 
this may occur.

So should really discard the redundant copies? To maximize the 
possibilities to connect the gathering agent should keep all its local 
transport address and local associated addresses for the redundant 
transport address. If one does this, doesn't the agent need to do either 
of these things:
1. Use the same user-name and  password for all of these associated 
addressed?
2. Actually present the different candidates with their respective 
candidate names and passwords

As I understand each peer candidate can only send to one of the 
potential candidates as they have the same address, but one doesn't know 
which will be the receiving one. A complication is that with multiple 
candidates only a single component may be a doublet in address sense. 
But I guess that complication was intended to be avoided by the 
formulation that a redundant candidate is only redundant if all components

So does 1 work and should be recommended in case the candidate is truly 
redundant?

T2. Section 7.3: What is really meant with 128 bits of randomness? To 
truly achieve it you would need to have a random number generator that 
generates 128 of random bits. In addition all the fields this randomness 
used needs to be at least ceil(128/6) = 22 characters in length. I think 
there is need to be more explicit on what the requirements are here.

T3. Section 11. message transfer 9: Is L's source really L-priv-1? 
Shouldn't this be L-priv-3?

T4. Section 11. Why isn't R initiated with a high Q for its public 
address? Isn't the fact that one has a public IP address quite a good 
heuristic?

T5

Editorial:

E1. Section 1, third paragraph: At the reference to TURN the 
abbreviation is not written out "(TURN)".

E2. Section 3, last paragraph:
"As a
    consequence, in order to have no impact on the call setup time or
    post-pickup delay for SIP, these offer/answer exchanges and checks
    happen while the call is ringing."

Wouldn't "minimal impact" be more correct than No impact. Sure there 
exist cases where no impact will occur, but there will be cases where 
there will be some impact, thus I think minimal is more correct.

E3. Section 7.5, second paragraph:

"Amongst candidates with the same
    qvalue, they are ordered based on candidate ID, using lexicographic
    order where C1 is placed before C2, if C2 precedes C1."

I may be a little dense here, but what is the criteria that makes C2 
precede C1, the lexicographical order? I think more clear language would 
be good here.

E4. Figure 4: I have some problem with that retransmission of STUN 
requests are not included when basically all other operations are 
present. As the state transactions are closely related to the reception 
of messages I think including the retransmissions on the two

E5. T3. Section 7.6, page 26:
"   In any state, if the STUN transaction results in an error, the state
    machine moves into the invalid state."

I don't think this statement is very clear. It is certainly not an STUN 
error message. So I would reformulate this. First I would like to have 
some explanation on what type of errors, like unrecoverable or so. 
Secondly a reference to where this is defined would be good to avoid 
misinterpretation.

E6. figure 5. Has a lot of empty lines. Please compress it to fit on a 
single page.

E7. Section 7.12. fourth paragraph. Talks about TCP despite only UDP is 
discussed in the rest of the specification.

E8. Section 8, "However,
    the updated offer with the highest priority valid candidate promoted
    to the m/c-line cannot occur until after the 200 OK, in which case it
    SHOULD be done with a re-INVITE."

This sentence is a bit hard to parse. Is it not possible to promote a 
new candidate before the 200, or is the sentence missing an if?

E9. Section 11. The number of candidates. The text is quite confusing 
one the number of candidates for R. First is establish that there will 
be three candidates on both sides. Then two paragraphs R only has two 
without explanation. As the reason for this is explained 10+ pages later 
it would be good to mention this upfront.

E10. The use of symmetric NAT. Would it be a good idea to replace all 
usage of symmetric NATs with the more precise BEHAVE terminology?

E11. Section 11, second paragraph: There are a lot of ">" that has been 
mangled into escaped versions.

E12. Section 11: I think the example would benefit from being split and 
have the explanations put in directly after the messages it relates to. 
That way it will be easier to follow and one doesn't have to turn pages 
like crazy.

E13. Section 11: I am missing the priority table for the candidates at 
certain key points. After the answer the initial table could be 
presented and then after either L or R has builds it modified with 
peer-derived candidate it should also be presented.

E14. Section 11. "Validate Turn-Pub-4 to Turn-Pub-2 has been strangely 
broken over the lines.

E15. Section 12. "The candidate attribute MUST be present within a media 
block of the SDP."

I think this sentence can be seriously misinterpreted. The must can be 
interpreted such that the candidate attribute must always be present. 
Why not use "The candidate attribute is a media-level attribute only."?

E16. 13.1 In the first sentence there is misplaced "also", please remove.

E17. I think the text could be improved by clarifying that the shared 
secret used in STUN is the password present in the candidate attribute.

E18. Reference [6] is not used in the text.

E19. Reference [11] has been updated into RFC 4234.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Nov 2005 11:05:20 -0500

Magnus,

Thanks as always for the very detailed review and excellent comments. 
Responses inline.

> address realms and same selection methods in the private address space 

Actually, I don't see when this can happen:

a. for local transport addresses, it doesn't happen by definition
b. for stun-derived transport addresses, the source IP address/port is 
different so the nat will create different bindings. If there is more 
than one nat, each would have its own IP anyway, so you'd get different 
bindings
c. for turn-derived, the same turn server won't hand out the same 
IP/port for different connections

> transport address. 

Even if this could happen, I'm not sure you would gain anything by 
keeping these. I need to see a real use case to be convinced.

> If one does this, doesn't the agent need to do either 
> of these things:

If you wanted to do this, I think you'd need different username/password 
for each of the candidates.

> which will be the receiving one.

Right - thats why the username fragments are in there.

> A complication is that with multiple 

I don't follow what you are saying here, sorry.

> T2. Section 7.3: What is really meant with 128 bits of randomness? 

Something that generates 128 random bits.

To
> there is need to be more explicit on what the requirements are here.

Yes, it would be 22 characters. Perhaps this is overkill. The randomness 
is needed for these reasons:

1. uniqueness amongst candidates from a particular UA
2. collision avoidance in the prioritization algorithm (if two candidate 
pairs have the same priorities, they are sorted based on which has the 
lowest candidate ID)
3. uniqueness across other hosts that might receive the STUN 
connectivity check

I think that 128 bits might be overkill here since none of these are for 
the purposes of security per se. The password, of coure, is different - 
thats for security. What we COULD do (and someone had suggested it to me 
- maybe you?) was to make the password shared across all candidates 
within a session, and just signal the username per candidate.

> Shouldn't this be L-priv-3?

No. You can reuse the existing local transport address L-PRIV-1 for the 
TURN allocation. We USED to require a separate local transport address a 
few revisions back....

> address? Isn't the fact that one has a public IP address quite a good 

Hmm, I don't follow. The answer generated by R does indeed contains its 
public address as the highest q-value candidate:

     v=0
        o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP
        s=
        c=IN IP4 $TURN-PUB-4.IP
        t=0 0
        m=audio $TURN-PUB-4.PORT RTP/AVP 0
        a=rtpmap:0 PCMU/8000
        a=rtcp:$TURN-PUB-5.PORT
        a=candidate $R1 1 $R-PASS1 UDP 1.0 $R-PUB-1.IP $R-PUB-1.PORT
        a=candidate $R1 2 $R-PASS2 UDP 1.0 $R-PUB-2.IP $R-PUB-2.PORT
        a=candidate $R2 1 $R-PASS3 UDP 0.3 $TURN-PUB-4.IP $TURN-PUB-4.PORT
        a=candidate $R2 2 $R-PASS4 UDP 0.3 $TURN-PUB-5.IP $TURN-PUB-5.PORT

> abbreviation is not written out "(TURN)".

fixed.

> there will be some impact, thus I think minimal is more correct.

OK, changed to minimal.

> precede C1, the lexicographical order? I think more clear language would 

Yes, this is needed. I'm kind of hoping there is a spec somewhere that 
has a nice definition for how to order base64 character sequences. I 
started to write some text on this and it turned out to be non-trivial.

> of messages I think including the retransmissions on the two

I don't see what benefit that brings; the state machines reflect the 
starts and completions of stun transactions. Why bother including the 
transaction FSMs themselves?

> Secondly a reference to where this is defined would be good to avoid 

Yeah, this is confusing. Its actually defined later on, where certain 
response codes are considered an "error". I'll add a forward reference.

> E6. figure 5. Has a lot of empty lines. Please compress it to fit on a 

fixed.

> discussed in the rest of the specification.

fixed.

> new candidate before the 200, or is the sentence missing an if?

Repaired to:

However, placing it in a 18x gives the offerer
an early preview of the answer, and allows the connectivity checks to
all occur prior to the user answering the call. However, the answer
doesn't actually occur until the 200 OK. This means that a new
offer/answer exchange (which would be used to promote the highest
priority validated candidate to active) cannot begin until after the
200 OK.

> it would be good to mention this upfront.

fixed.

> usage of symmetric NATs with the more precise BEHAVE terminology?

Yes, excellent point. Will do.

> mangled into escaped versions.

fixed.

> That way it will be easier to follow and one doesn't have to turn pages 

errr, I appreciate this, but that would be a huge amount of work for me 
to do....

> peer-derived candidate it should also be presented.

OK, that is a good idea. Will do.

> E14. Section 11. "Validate Turn-Pub-4 to Turn-Pub-2 has been strangely 

I have no control over this, unfortunately.

> Why not use "The candidate attribute is a media-level attribute only."?

OK, fixed.

> E16. 13.1 In the first sentence there is misplaced "also", please remove.

fixed. Artifact of an older ordering of subsections here.

> secret used in STUN is the password present in the candidate attribute.

Will do.

> E18. Reference [6] is not used in the text.

wow, great catch. Removed.

> E19. Reference [11] has been updated into RFC 4234.

fixed.

Thanks!

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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: Magnus Westerlund <[email-masked]>
Date: Thu, 10 Nov 2005 03:03:59 +0100

Hi Jonathan,

See response inline.

>> What is the procedure for when you get several transport addresses 
>> that are identical but different associated local addresses? With 
>> multiple address realms and same selection methods in the private 
>> address space this may occur.
> 
> 

Lets assume two layer of NATs. Then the client's local interface could 
be private address 10.10.10.10 and as the NAT closest to the client 
would also be in a private address space, THUS the NAT or TURN server 
might also have been assigned 10.10.10.10. You could potentially end up 
with a STUN, TURN or peer derived address(es) that is the same as a 
local interface address.

It seems that the important case here is that the client correctly 
determines the associated local transport address for a valid 
connectivity check.

If one only announces a single candidate for the multiple addresses, 
then the other sides usage of remote-candidate attribute will not be 
possible to correctly indicate which candidate and corresponding 
associated local address that was reached. Because of this I don't think 
compressing away identical transport addresses. Also I don't think it is 
that likely in a multi-component candidate all transport addresses are 
identical. Because of this the more likely case would be to have some 
component have identical address than all of them.

> keeping these. I need to see a real use case to be convinced.

The reason would be to ensure that the local client can correctly 
determine which of its candidate and associated local addresses should 
be used when connectivity is established.

> 
> 
>> If one does this, doesn't the agent need to do either of these things:
>> potential candidates as they have the same address, but one doesn't 
>> know which will be the receiving one.
> 
> 

Which would mean that all possible usernames must be indicated to the 
other end as candidate. Removing them as you propose would mean that the 
peer wouldn't know the different usernames used and could not correctly 
indicate them.

> 
>> A complication is that with multiple candidates only a single 
>> component may be a doublet in address sense. But I guess that 
>> complication was intended to be avoided by the formulation that a 
>> redundant candidate is only redundant if all components
> 
> 

I think the point I was trying to make is that. You already taken care 
of the cases when a single component in a candidate has a duplicate 
transport address.

> 
>>
>> So does 1 work and should be recommended in case the candidate is 
>> truly redundant?
>>
>> generates 128 of random bits. In addition all the fields this 
>> randomness used needs to be at least ceil(128/6) = 22 characters in 
>> length. I think there is need to be more explicit on what the 
>> requirements are here.
> 
> 

I don't think that was me. But it sounds like a good idea. We probably 
should have usernames that has a minimal length but at least 8 or so 
characters.

>        a=candidate $R2 2 $R-PASS4 UDP 0.3 $TURN-PUB-5.IP $TURN-PUB-5.PORT

I meant the address put into the m/c line. Why isn't a public IP address 
put into m/c line per default?

Cheers

Magnus Westerlund