Subject: [MMUSIC] Comment on draft-ietf-mmusic-ice-00.txt

From: Magnus Westerlund <[email-masked]>
Date: Fri, 07 Nov 2003 16:48:50 +0100

Hi Jonathan,

I had a late night reading session yesterday that produce some comments.

1. I think there are still maybe a few places where ICE is to situation 
specific towards SIP. I will not go so long to require that mapping of 
transport addresses are not IP + transport protocol ports as this is 
what our NAT problem causes. However the constant reference to RTP 
should probably be removed, there are at least other proprietary media 
protocols. So I think one should talk about media protocol instead of 
RTP + RTCP.

2. I think some better motivation why the openly available password in 
the STUN request is acceptable. And then why the integrity protection 
gives advantages or not.

3. When the responder performs his connectivity checks and succeed, why 
does the initiator need to perform a counter check also? Some more 
should probably be spent on this. The initiator knows the source address 
as it sees it to send any packets to. The only piece of information 
missing is what responder connection interface it goes to. This could be 
identified using STUN supplements and the response message connection IDs.

Then the only reasons for doing a counter check is to possibly enable 
connectivity over a more prioritized connection. OR have I missed 
something about this.

4. Of course not doing it both way will not provide full protection 
against the RTP DOS attack. However you have not at all discussed the 
applicability of ICE for RTP DOS prevention.

5. I also are not finding anything about the retrying in the 
transmission of STUN request. Should these be done in any special way 
for ICE? Also there is very little discussion about timer consideration 
for performing the connectivity checks.

6. In example 6.2 i think it can be easily expanded to show one 
important functionality of ICE, the possibility to open up restricted 
NAT through the usage of multiple ICE cycles. If A is behind a 
restricted NAT it will be able to determine its outermost address and 
port. However in cycle 1, B will not be able to reach A. When then A 
tries B over the cycle this may succeed. Then B can verify this by 
STUNNING a second time. These possibilities are rather tuned down.

7. I think the XML description should be more generic and include 1..N 
transport addresses for each media session.

8. If anyone missed the other message, the usage of "alt" has a conflict 
with 3GPP TS 26.234, Rel 6 preliminary specification.

9. I think there should be some example of the complete mesh ICE 
actually tries. I know it will be a hard thing to draw using ASCII art.

10. If one uses ICE for other purposes then UNSAF mechanism it suddenly 
will not have any exit strategy for that purpose. However it should 
still be true that if no relays, etc. are need when people has migrated 
to IPv6, etc., then it will simply reduce the complexity of doing ICE.

11. When one performs ICE, are there any congestion control 
considerations to make? If one digs up a number of address locally the 
local interface might need to send a lot of packets in a short time as 
it is desired to perform this in parallel.

Best Regards

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