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

From: Thomas Zeng <[email-masked]>
Date: Wed, 12 Nov 2003 21:52:17 -0800

Hi Jonathan:

I finally got around to go through your draft. As always, I enjoy your
writing style very much, plus that this version is much improved than the
previous one.

Some comments (more or less from RTSP perspective):

1. Section 5.1, last paragraph:

There is a statement:  "However, in
   order to communicate with the peer, at least one of the offered
   addresses has to be guaranteed to work with any peer that might be
   called. This generally requires that at least one of the derived
   addresses be obtained from a relay service (such as TURN) that exist
   within the public Internet."

I don't agree this statement. Consider the case of RTSP streaming, if the
server is in the open, and client behind NAT, 
I fail to see the need to require "relay service (such as TURN)".  

2. Section 5.5, page 13, also on page 14, 3rd paragraph

There is a statement:  "This BindingRequest MUST contain the USERNAME
   attribute, and the value of the USERNAME MUST equal the username from
   that alternate element. Similarly, the BindingRequest MUST contain a
   PASSWORD attribute, and the value of the PASSWORD MUST equal the
   password from the alternate element."
Why can't a USERNAME be globally unqiue for each RTP and RTCP port? That way
USERNAME alone is enough to figure out the alternate.
Inclusion of password in the BindingRequest is a security compromise
(especially that such message is  sent in the clear), and it contradicts
rfc3489,
section 9.3, where the password is not included in the BindingRequest.

It is important not to send password in the open.

3. Also page 13: on the lock down problem,  the solution I see would be to
have multiple TURN servers available, so as to  make it possible to try
alternates in parrellel.
TURN servers in general are not very scalable any way, so it is not
unthinkable to deploy multiple STUN servers ...

4. section 6.2 second paragraph:

The scenario described is not going to work for symetric NAT, am I correct?
If so, it probably is useful to state it explicitly.

5. Section 7: xml schema for ICE Messages:

There is one attribute ("extension base?") called "rtp-info". Does this have
anything to do with "rtp-info" in RFC2326? It doesn't match the parameters
in rfc2326's Rtp-info header.
 I suspect  this to be a name space conflict?

6. It would nice to have a mapping from ICE to RTSP.

thanks,
thomas

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Friday, November 07, 2003 7:49 AM
> To: Jonathan Rosenberg; IETF MMUSIC WG
> Subject: [MMUSIC] Comment on draft-ietf-mmusic-ice-00.txt
> 
> 
> 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
> 

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