Re: [MMUSIC] WGLC for draft-ietf-mmusic-ice-tcp-13
Flemming Andreasen <fandreas@cisco.com> Thu, 12 May 2011 21:05 UTC
Return-Path: <fandreas@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A19E07F9; Thu, 12 May 2011 14:05:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUAOIveRBU1z; Thu, 12 May 2011 14:05:18 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 10C4AE07F8; Thu, 12 May 2011 14:05:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=19242; q=dns/txt; s=iport; t=1305234318; x=1306443918; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=B7Se01zD8vtIJo/5BmmJpTWIcFCJ6ErFkeBdy98l8HU=; b=JVryAAllPgyoJ7WoyHtyHTJUIWCNXaex3YrJeqrNQ3f7SAzWyw2LaarL kp/MPT1KHbtWMXhcOVGPDUQhjlWLSb7hqx5aWvj7Lgb3X/iSh3qCtu0jd i+bkFYch5H55ATN7fR7tRag2WU3d+7sOlkAqIuHJhafhyZ/vwPu4eyGa7 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAHdKzE2tJXG9/2dsb2JhbACCZKMVd4hwoXKeJ4YVBI97jwU
X-IronPort-AV: E=Sophos; i="4.64,360,1301875200"; d="scan'208,217"; a="314471743"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-3.cisco.com with ESMTP; 12 May 2011 21:05:17 +0000
Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4CL5Gek006222; Thu, 12 May 2011 21:05:16 GMT
Message-ID: <4DCC4B8C.9040104@cisco.com>
Date: Thu, 12 May 2011 17:05:16 -0400
From: Flemming Andreasen <fandreas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11
MIME-Version: 1.0
To: Ari Keranen <ari.keranen@nomadiclab.com>
References: <4DA86A44.9040909@cisco.com> <4DC89DB6.70008@cisco.com> <56FA6861-542E-422F-AEE2-5B987014E8A4@nomadiclab.com>
In-Reply-To: <56FA6861-542E-422F-AEE2-5B987014E8A4@nomadiclab.com>
Content-Type: multipart/alternative; boundary="------------000203050607070706090909"
Cc: mmusic-chairs@ietf.org, mmusic <mmusic@ietf.org>, draft-ietf-mmusic-ice-tcp@tools.ietf.org
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-ice-tcp-13
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2011 21:05:20 -0000
On 5/11/11 11:55 AM, Ari Keranen wrote: > > Hi Flemming, > > Thanks for the thorough review! See inline. > > On May 10, 2011, at 5:06 AM, Flemming Andreasen wrote: > [...] > > - Section 7.1, third paragraph > > <quote> > > If the TCP connection cannot be established, the check is considered > > to have failed, and a full-mode agent MUST update the pair state to > > Failed in the check list. > > </quote> > > a) How long do you wait before determining it cannot be established > ? Need some considerations around this > > I have considered this as an implementation/platform detail: you do > connect() and wait until it succeeds or fails. Or do you have > suggestions what additional to recommend here? > Does RFC 5389 Section 7.2.2 simply apply directly here and hence we should just reference that ? > > b) Also, how fast do you attempt to establish additional TCP > connections ? Timer Ta considerations would seem to apply to the TCP > connection establishment here. > > Yes, the agents pace the start of the checks like for UDP. The end of > section 4.1 says "Like its UDP counterparts, TCP-based STUN > transactions are paced out at one every Ta seconds." It could be a bit > confusing that the comment is under "Gathering candidates" section, > but it refers to all STUN transactions. > I think we should mention it in Section 7.1, however looking at it again, I assume we simply following Section 5.8 from RFC 5245 (Scheduling Checks), and hence a reference to that effect would suffice. > > > - Section 11.1 > > The section seems to be written under the assumption that both sides > are full ICE Implementations. Need to consider lite implementations as > well. > > This seemed OK to me. What would you change here to accommodate also > lite agents? > You have the following text for example <quote> If the TCP connection is established, the framing of RFC 4571 is utilized. If the agent opened the connection, it MUST send a STUN connectivity check. </quote> That latter sentence would presumably only apply if the agent is a full implementation. Similarly <quote> If an agent receives a connectivity check after re- establishment of the connection, it MUST generate a triggered check over that connection in response if it has not already sent a check. Once an agent has sent a check and received a successful response, the connection is considered Valid and media can be sent (which includes a TLS or DTLS-SRTP session resumption or restart) </quote> seems to assume full ICE implementations. > > > - Section 12 > > I believe there is a TCP amplification attack similar to the STUN > amplification attack that requires consideration, since the TCP > connection is established prior to any STUN/ICE checks and involves > TCP state creation on the part of the attacked party. > > I guess you're right. We should document that, but any ideas for > mitigation? > I'm not sure - maybe we can limit the number of outstanding TCP connection attempts to the same IP-address ? It would probably be worthwhile asking some of the security experts here. > > > - Section 13 > > I was surprised to see no IANA considerations since "TCP" is defined > as a new transport-extension value here, however upon checking RFC > 5245, there apparently is no registry defined for this. RFC 5245 > Section 14 appears to indicate this was not an oversight at the time, > however with ice-tcp, I think we should define a registry. > > Good point; we'll add one in the next revision. > Ok. > > Editorial/Nits > > ========== > snipped the ones we're in sync on > > - Section 3, Figure 1 > > It would be helpful to either expand the figure to cover the > non-(D)TLS case as well or have another figure showing that for comparison > > Do we really need one, considering the non-(D)TLS case is fairly > trivial, right? The "strangeness" in the (D)TLS case comes from the > fact that STUN is used outside of the (D)TLS connection. > > Although, the figure caption should be updated to reflect the fact > that this is the (D)TLS case; now it says "ICE TCP Stack with (D)TLS". > You don't *need* it, but it would have been helpful to me the first time I read it at least. > > > - Section 4.2 > > <quote> > > The direction-pref MUST be between 0 and 7, with 7 being the most > > preferred. The other-pref MUST be between 0 and 8191, with 8191 > > being the most preferred. > > </quote> > > Rephrase to make clear that 0 and 8191 (presumably) are both valid > values in these ranges. > > OK, now it says: > > The direction-pref MUST be between 0 and 7 (inclusive), with 7 being > the most preferred. The other-pref MUST be between 0 and 8191 > (inclusive), with 8191 being the most preferred. > I'd say "both inclusive". > > > > - Section 4.5 > > <quote> > > The connection-address and port encoded into the candidate attribute > > for active candidates MUST be set to the IP address that will be used > > for the attempt, but the port(s) MUST be set to 9 (i.e., Discard). > > </quote> > > - Delete the "and port" part. > > Why? The "port" refers to the "port" and "rel-port" parts in the > candidate-attribute. > The sentence reads <quote> The connection-address and port encoded into the candidate attribute for active candidates MUST be set to the IP address that will be used for the attempt, </quote> You can only set the connection-address to the IP address, not the port. It's a nit. > > > - Section 15.2 > > RFC 3261, 5389, 5766, and 6062 should all be normative rather > informative. > > Fixed the first two, but 5776 (TURN) and 6062 (TURN TCP) are > intentionally informative since TURN is just one of the possible > techniques for relaying. > Except from http://www.rfc-editor.org/rfc-editor/instructions2authors.txt <quote> Within an RFC, references to other documents fall into two general categories: "normative" and "informative". Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. An informative reference is not normative; rather, it provides only additional information. For example, an informative reference might provide background or historical information. Material in an informative reference is not required to implement the technology in the RFC. </quote> In other words, just because you don't mandata the use of TURN doesn't automatically turn it into an informative reference (as I've been told I think the TURN text in e.g. Section 1, Section 4.1, Section 11.2 etc makes RFC 5766 a Normative reference per the above. RFC 6062 is perhaps more debatable. Thanks -- Flemming
- [MMUSIC] WGLC for draft-ietf-mmusic-ice-tcp-13 Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-ice-tcp-13 Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-ice-tcp-13 Simon Perreault
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-ice-tcp-13 Ari Keranen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-ice-tcp-13 Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-ice-tcp-13 Ari Keranen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-ice-tcp-13 Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-ice-tcp-13 Ari Keranen