From nobody Mon Jan 8 19:42:26 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92D61242F5 for ; Mon, 8 Jan 2018 19:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEffSoXgaIX4 for ; Mon, 8 Jan 2018 19:42:22 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9838A1201FA for ; Mon, 8 Jan 2018 19:42:22 -0800 (PST) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w093gLsZ083612 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 8 Jan 2018 21:42:22 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_2246F6CB-02C4-40AB-9676-F480EF78D398"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <505EFEB8-0EEA-4F66-894A-7BD5C02E678D@nostrum.com> Date: Mon, 8 Jan 2018 21:42:20 -0600 To: draft-ietf-ice-rfc5245bis-all@ietf.org, ice@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Ice] AD Evaluation of draft-ietf-ice-rfc5245bis-15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 03:42:25 -0000 --Apple-Mail=_2246F6CB-02C4-40AB-9676-F480EF78D398 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, This is my AD Evaluation of draft-ietf-ice-rfc5245bis-15. Most of my = comments are editorial, but there are enough of them I think we will = need another revision prior to IETF LC. I recognize some of my comments address text that did not change from = 5245. I tried to minimize that, but this is enough of a rewrite that = it=E2=80=99s hard to completely isolate just the updated text. I suspect = that last call reviewers and members of the IESG will also find that = hard in places.) Thanks! Ben. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 Substantive Comments: - 2.1, 2nd to last: Does ICE really prioritize a path with fewer NATs = over a path with more NATs, or is it more a matter of selecting a path = with no NATs over a path with =E2=80=9Csome=E2=80=9D NATs? (If the = former, how does it figure out how many NATs are between an agent and = it=E2=80=99s servers and peers? Is this just a matter of timing?) - 7.2.5.2.3 and 7.2.5.2.4: Why are these SHOULDs not MUSTs? Do you = envision circumstances where it might make sense _not_ to set the state = to Failed? -17, first paragraph: =E2=80=9C If these potential attacks can not be mitigated, the implementation may want to institute controls for which addresses are revealed to the negotiation and/or probing process. Such controls need to be specified as part of the ICE usage.=E2=80=9D This seems ambiguous. Is it the implementation=E2=80=99s decision to = institute such controls, or is each ICE usage spec expected to make a = decision that applies to all implementations of that usage? Should =E2=80=9Csecure signaling techniques=E2=80=9D distinguish between = HBH and E2E techniques, in light of the later discussion about insider = attacks? -17,1, false peer reflexive candidate: Should this mention SRTP (or = DTLS-SRTP) as a mitigating countermeasure? Editorial Comments and Nits: Is there a reason that the Security Considerations and IANA = considerations are not in the conventional locations (i.e. the last two = sections before the references)? (I see that is also true in 5245, so = this is mostly curiosity.) -1, last paragraph: Would it make sense to change =E2=80=9Cexchanged via = mechanisms=E2=80=9D (which seems a tautology) to =E2=80=9Cexchanged via = various mechanisms=E2=80=9D, =E2=80=9Cexchanged by application-specific = mechanisms=E2=80=9D, or something similar? =E2=80=94 Didn't 5245 already deprecate RFC 4091 and 4092? That is, = _this_ document does not do that. -2.1, first paragraph: "Naturally, one viable candidate has a transport = address obtained directly from a local interface=E2=80=9D Shouldn=E2=80=99t that say =E2=80=9Cone or more viable candidates = have=E2=80=A6.=E2=80=9D? or =E2=80=9CAt least one=E2=80=A6=E2=80=9D? -2.1, 4th paragraph from end: It would be helpful to describe what = =E2=80=9Cvalid pair=E2=80=9D means earlier in the document. -2.3, figure 4: The figure still says =E2=80=9Cflag=E2=80=9D, while the = text has been changed in several place to speak of the nominated = =E2=80=9Cattribute=E2=80=9D. Please use one or the other consistently. -4: There are at least a few uses of lower case =E2=80=9Cmust=E2=80=9D = and =E2=80=9Cshould=E2=80=9D that do not appear to have been intended as = keywords. If that is the intent, please update this to use the = boilerplate from 8174. (The 2119 boilerplate is ambiguous on whether = lower case instances count as keywords.) s/=E2=80=9C=E2=80=A6 defined in the STUN=E2=80=A6=E2=80=9D / =E2=80=9C=E2=80= =A6 defined in STUN=E2=80=A6 =E2=80=9C or =E2=80=9C=E2=80=A6 defined in = the STUN protocol =E2=80=A6=E2=80=9D -5, last paragraph: The figure does not actually mention =E2=80=9Cdefault = candidate selection=E2=80=9D. -5.1.1, last paragraph, last sentence: Is the MAY applicable just to the = responding agent, or both agents? -5.1.1.2, first paragraph : =E2=80=9CThose requirements are at SHOULD = strength=E2=80=A6=E2=80=9D I suggest putting =E2=80=9CSHOULD=E2=80=9D in quotes when talking about = a requirement stated elsewhere. (Even if that =E2=80=9Celsewhere=E2=80=9D = is in the same sentence :-) ) -5.1.1.3, first paragraph: "Two candidates MUST have the same foundation = when all of the following are true=E2=80=9D That seems like a statement of fact. (Same for the last paragraph = talking about different foundations.) - 5.1.2.1: Missing article before =E2=80=9CIP Address for which the = candidate=E2=80=A6=E2=80=9D (This section also seems to have a lot of 2119 keywords that are really = statements of fact or definition. But I recognize those come from the = original 5245 text.) -6.1.2, 2nd sentence: =E2=80=9C To form a check list, an ICE agent = (initiating and responding) forms candidate pairs" Consider : =E2=80=9CTo form check lists, initiating and responding ICE = agents form candidate pairs=E2=80=A6=E2=80=9D -7.2.5.2.1: =E2=80=9CMUST be equal the destination IP address=E2=80=9D Consider =E2=80=9CMUST equal=E2=80=9D or =E2=80=9CMUST be equal to=E2=80=9D= -12.3: =E2=80=9C As discussed below, ICE agents are encouraged to = re-adjust jitter buffers=E2=80=A6=E2=80=9D Please cite the specific section(s). - 17, last 3 paragraphs: With the expansion of the security = considerations, this list does not include all the countermeasures = mentioned in the later sections. -17.2, last bullet: Why call out viruses specifically? It seems like = there are a lot of ways a server might be compromised that do not = involve viruses per se. (Same in 17.3). -17.4.1: Since the description of the voice hammer attack has been = removed, can you cite something that does describe it? (Appendix A still = refers to section 17 to describe the voice hammer attack.) -17.4.1, 2nd paragraph: s/they=E2=80=99ll/=E2=80=9Cthey will=E2=80=9D -22: Did you consider making this section an appendix? --Apple-Mail=_2246F6CB-02C4-40AB-9676-F480EF78D398 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpUOhwACgkQgFZKbJXz 1A0enA//Z0Vf17pez7lQdhjwmGCmizGpnzqeQ3ZfOMeSYjZviWj8acYNyXsjj5Ff v0GEeSIazog6ZAsk0LWP4d5TXwXOWtyRtxi0HXRgCSLDPsq5VE1EcdjzrubygngQ foQpCRvrZq7LgqN+Wc4CDcgRcA7F1iToPqP1fTXijL/YvH5ScM08BSQF0dGygn9h m/zAAgB9fKfaXXjZuQbkD6+3lb9sMweC/wG/pFb39JH/ZkHu2XgrCYQI5o1CxKl7 e6fmrkcLbXo9EUpbUqQlQPqry/1unFTKGQ7ygLraBSTXMOYt8iPSjeYeVil4Iqkm 5Ur1CyjGEDCYdv6DeEkaEzSsONtcCJS7LzwozJT0SKegp/wofHZM88pErVbPZ2cK p66isQZDkV4hqxUNJznEAJnyQHcgt4+JOIUCt1eqZzHPsZJKQeYw+4JLyFmFInSW d3mcrsZI7nAZp7rY0Rq7+Xe3OlhqhFCLw+5qUYwtRVeU8cBGJAh4bdX2mjppaU8G 4Y/TCZcPrtkZUUizdocO2InVTeWYsJB0FSDftN3hsRQMm3Kdm10Ye2/7b61X3wKL 1iRcsf1HmImMHJCzvAQ+pdjQIAqzQUCcXn/18eXpAXEA+9Mom/uvnykHFbzDTb9w IRemWqZP5zlOyA5cC+RPS92hOH6vCVSkMy4g7qLLVJPLYsYd/JQ= =qYLe -----END PGP SIGNATURE----- --Apple-Mail=_2246F6CB-02C4-40AB-9676-F480EF78D398-- From nobody Mon Jan 8 19:45:13 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B43126D46; Mon, 8 Jan 2018 19:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebaem_C9KiUr; Mon, 8 Jan 2018 19:45:06 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86AB31242F5; Mon, 8 Jan 2018 19:45:03 -0800 (PST) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w093j2oo083887 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 8 Jan 2018 21:45:03 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_062B2CF7-E66F-4B3C-BFAC-CE1ACA4B76F4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <28E9DD8B-5FEC-468D-B745-30D21E504B9D@nostrum.com> Date: Mon, 8 Jan 2018 21:45:01 -0600 To: ice@ietf.org, draft-ietf-ice-rfc5245bis.all@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Ice] AD Evaluation of draft-ietf-ice-rfc5245bis-15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 03:45:12 -0000 --Apple-Mail=_062B2CF7-E66F-4B3C-BFAC-CE1ACA4B76F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 (Apologies for the repeat. I messed up the =E2=80=9C.all@ietf.org=E2=80=9D= address the first time. ) Hi, This is my AD Evaluation of draft-ietf-ice-rfc5245bis-15. Most of my = comments are editorial, but there are enough of them I think we will = need another revision prior to IETF LC. I recognize some of my comments address text that did not change from = 5245. I tried to minimize that, but this is enough of a rewrite that = it=E2=80=99s hard to completely isolate just the updated text. I suspect = that last call reviewers and members of the IESG will also find that = hard in places.) Thanks! Ben. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 Substantive Comments: - 2.1, 2nd to last: Does ICE really prioritize a path with fewer NATs = over a path with more NATs, or is it more a matter of selecting a path = with no NATs over a path with =E2=80=9Csome=E2=80=9D NATs? (If the = former, how does it figure out how many NATs are between an agent and = it=E2=80=99s servers and peers? Is this just a matter of timing?) - 7.2.5.2.3 and 7.2.5.2.4: Why are these SHOULDs not MUSTs? Do you = envision circumstances where it might make sense _not_ to set the state = to Failed? -17, first paragraph: =E2=80=9C If these potential attacks can not be mitigated, the implementation may want to institute controls for which addresses are revealed to the negotiation and/or probing process. Such controls need to be specified as part of the ICE usage.=E2=80=9D This seems ambiguous. Is it the implementation=E2=80=99s decision to = institute such controls, or is each ICE usage spec expected to make a = decision that applies to all implementations of that usage? Should =E2=80=9Csecure signaling techniques=E2=80=9D distinguish between = HBH and E2E techniques, in light of the later discussion about insider = attacks? -17,1, false peer reflexive candidate: Should this mention SRTP (or = DTLS-SRTP) as a mitigating countermeasure? Editorial Comments and Nits: Is there a reason that the Security Considerations and IANA = considerations are not in the conventional locations (i.e. the last two = sections before the references)? (I see that is also true in 5245, so = this is mostly curiosity.) -1, last paragraph: Would it make sense to change =E2=80=9Cexchanged via = mechanisms=E2=80=9D (which seems a tautology) to =E2=80=9Cexchanged via = various mechanisms=E2=80=9D, =E2=80=9Cexchanged by application-specific = mechanisms=E2=80=9D, or something similar? =E2=80=94 Didn't 5245 already deprecate RFC 4091 and 4092? That is, = _this_ document does not do that. -2.1, first paragraph: "Naturally, one viable candidate has a transport = address obtained directly from a local interface=E2=80=9D Shouldn=E2=80=99t that say =E2=80=9Cone or more viable candidates = have=E2=80=A6.=E2=80=9D? or =E2=80=9CAt least one=E2=80=A6=E2=80=9D? -2.1, 4th paragraph from end: It would be helpful to describe what = =E2=80=9Cvalid pair=E2=80=9D means earlier in the document. -2.3, figure 4: The figure still says =E2=80=9Cflag=E2=80=9D, while the = text has been changed in several place to speak of the nominated = =E2=80=9Cattribute=E2=80=9D. Please use one or the other consistently. -4: There are at least a few uses of lower case =E2=80=9Cmust=E2=80=9D = and =E2=80=9Cshould=E2=80=9D that do not appear to have been intended as = keywords. If that is the intent, please update this to use the = boilerplate from 8174. (The 2119 boilerplate is ambiguous on whether = lower case instances count as keywords.) s/=E2=80=9C=E2=80=A6 defined in the STUN=E2=80=A6=E2=80=9D / =E2=80=9C=E2=80= =A6 defined in STUN=E2=80=A6 =E2=80=9C or =E2=80=9C=E2=80=A6 defined in = the STUN protocol =E2=80=A6=E2=80=9D -5, last paragraph: The figure does not actually mention =E2=80=9Cdefault = candidate selection=E2=80=9D. -5.1.1, last paragraph, last sentence: Is the MAY applicable just to the = responding agent, or both agents? -5.1.1.2, first paragraph : =E2=80=9CThose requirements are at SHOULD = strength=E2=80=A6=E2=80=9D I suggest putting =E2=80=9CSHOULD=E2=80=9D in quotes when talking about = a requirement stated elsewhere. (Even if that =E2=80=9Celsewhere=E2=80=9D = is in the same sentence :-) ) -5.1.1.3, first paragraph: "Two candidates MUST have the same foundation = when all of the following are true=E2=80=9D That seems like a statement of fact. (Same for the last paragraph = talking about different foundations.) - 5.1.2.1: Missing article before =E2=80=9CIP Address for which the = candidate=E2=80=A6=E2=80=9D (This section also seems to have a lot of 2119 keywords that are really = statements of fact or definition. But I recognize those come from the = original 5245 text.) -6.1.2, 2nd sentence: =E2=80=9C To form a check list, an ICE agent = (initiating and responding) forms candidate pairs" Consider : =E2=80=9CTo form check lists, initiating and responding ICE = agents form candidate pairs=E2=80=A6=E2=80=9D -7.2.5.2.1: =E2=80=9CMUST be equal the destination IP address=E2=80=9D Consider =E2=80=9CMUST equal=E2=80=9D or =E2=80=9CMUST be equal to=E2=80=9D= -12.3: =E2=80=9C As discussed below, ICE agents are encouraged to = re-adjust jitter buffers=E2=80=A6=E2=80=9D Please cite the specific section(s). - 17, last 3 paragraphs: With the expansion of the security = considerations, this list does not include all the countermeasures = mentioned in the later sections. -17.2, last bullet: Why call out viruses specifically? It seems like = there are a lot of ways a server might be compromised that do not = involve viruses per se. (Same in 17.3). -17.4.1: Since the description of the voice hammer attack has been = removed, can you cite something that does describe it? (Appendix A still = refers to section 17 to describe the voice hammer attack.) -17.4.1, 2nd paragraph: s/they=E2=80=99ll/=E2=80=9Cthey will=E2=80=9D -22: Did you consider making this section an appendix? --Apple-Mail=_062B2CF7-E66F-4B3C-BFAC-CE1ACA4B76F4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpUOr0ACgkQgFZKbJXz 1A049w/+LNlkaVNLdnZqlcF69raIDbju9zlLWk70XdhsbRiPNQkD69mMCPzr1jws 81+zI81r8b0PFk49LvR2kOvnEzzSTqs2eyq2TapRpdsaz5DjeqUw2W7BiEZ06hGx Ty7xwRgUQNoNWcvbu4NNRN4CdTPrWaIzUXEXdqCZJbdCDEMiIFy3jDjtB1HRYk6N 6N3uJ0VFABlmWtS1Mhmh/6+kVYjagLTo32et5Fav1247sWuvL10s7svwSWKlFtI3 8JClul6LscOm+6n3aeecUV6uRY25zftGbutjlBLdJbeKBS/c75+Kgo+L8T4CVDWV 9M1EyKZBXwQYVG9NC+YVgvGpQwIi+EECEd7nUaHlbUm4tHksPJYgp8BlXACv7TxT WgUFE5RXK++k48rD3rwkzCINspDJ1SOy413P0gOpuPUj3C+7QZgzVEH9KFgWHh5W 4245n7wgg/O/c0mnnQ7LB4MFpSIKXYDzFwsNzhO3zcq976tJKLtZ8FGAE1xn45cl 2agEx4vODlPULUE3CzPGYJpwx8OmyaMo7lMHgCeZT4Bfy5++sawBXNKCwfsuSNDa qhIsHejjfwgvla3BUbGNtMd2xnVHYGfbx/fK8lqskhJ1XYD2SOQEo5w2TR1THOyD kTKpcetiftjEPgdS8yPvX639wVnMGYWlDhcNL23afKa11pq8HOw= =QU1W -----END PGP SIGNATURE----- --Apple-Mail=_062B2CF7-E66F-4B3C-BFAC-CE1ACA4B76F4-- From nobody Tue Jan 9 04:58:18 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B199012D850; Tue, 9 Jan 2018 04:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmfhVrT_afW8; Tue, 9 Jan 2018 04:58:15 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0B612D834; Tue, 9 Jan 2018 04:58:14 -0800 (PST) X-AuditID: c1b4fb30-11d5e9c000006bc7-d2-5a54bc645c79 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 7E.1A.27591.46CB45A5; Tue, 9 Jan 2018 13:58:12 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Tue, 9 Jan 2018 13:58:03 +0100 From: Christer Holmberg To: Ben Campbell , "ice@ietf.org" , "draft-ietf-ice-rfc5245bis.all@ietf.org" Thread-Topic: AD Evaluation of draft-ietf-ice-rfc5245bis-15 Thread-Index: AQHTiPxCRxYiw9L/zEu/jMuzPPo1iKNrlLmA Date: Tue, 9 Jan 2018 12:58:03 +0000 Message-ID: References: <28E9DD8B-5FEC-468D-B745-30D21E504B9D@nostrum.com> In-Reply-To: <28E9DD8B-5FEC-468D-B745-30D21E504B9D@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM2K7im7KnpAog/+3zCzmd55mtzj+4w+7 xbcLtQ7MHkuW/GTymLXzCUsAUxSXTUpqTmZZapG+XQJXxsz23YwFPcEVtx9tYm9gvOTYxcjJ ISFgIjG5dx17FyMXh5DAYUaJVV+Xs4IkhAQWM0qcuOnSxcjBwSZgIdH9TxskLCIwg1Gi/UUo iC0sYCXROuc6G0TcWuL7n5tQtpHEpQkXmUFsFgEViU/9b8FsXqCa3gXr2SHG20m8u3YfrJ5T wF5i5d2PYDajgJjE91NrmEBsZgFxiVtP5jNB3CkgsWTPeWYIW1Ti5eN/YGeKCuhJbDhxmx0i riTxY8MlFoheA4n35+YzQ9jWEkt+TGODsLUlli18DXWPoMTJmU9YJjCKzUKybhaS9llI2mch aZ+FpH0BI+sqRtHi1OKk3HQjI73Uoszk4uL8PL281JJNjMDoOrjlt8EOxpfPHQ8xCnAwKvHw Fm4OiRJiTSwrrsw9xCjBwawkwus7PzhKiDclsbIqtSg/vqg0J7X4EKM0B4uSOO9JT94oIYH0 xJLU7NTUgtQimCwTB6dUA6O+x6tjF3jij210KFWUW7IqLu/GrX0rNCTcbwlrlb1j2Ml9SOO0 TcebSmU+nQk3HsyNPSOunuQV23x6qf5uPYV6m4mvN1ycuiyt5V5kQGKfskvUlL0OAocY4t68 +HOpTKJ8o8xS03+WK/5u2ng7KFqVLyJiXtqC7EV72PLdQlqOu58R38+qUqHEUpyRaKjFXFSc CADnBumSqgIAAA== Archived-At: Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-rfc5245bis-15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 12:58:18 -0000 Hi Ben, Thank You for the review! Please see inline. >Substantive Comments: > >- 2.1, 2nd to last: Does ICE really prioritize a path with fewer NATs >over a path with more NATs, or is it more a matter of selecting a path >with no NATs over a path with =B3some=B2 NATs? (If the former, how does it >figure out how many NATs are between an agent and it=B9s servers and peers= ? >Is this just a matter of timing?) ICE agents can=B9t determine how many NATs there are. I suggest to say: "In general, the priority algorithm is designed so that candidates of similar type get similar priorities and so that more direct routes (that is, routes without data relays or NATs) are preferred over indirect routes (routes with data relays or NATs)." ---- >- 7.2.5.2.3 and 7.2.5.2.4: Why are these SHOULDs not MUSTs? Do you >envision circumstances where it might make sense _not_ to set the state >to Failed? I can=B9t think of any such cases. I suggest to s/SHOULD/MUST. ---- >-17, first paragraph: =B3 If these > potential attacks can not be mitigated, the implementation may want > to institute controls for which addresses are revealed to the > negotiation and/or probing process. Such controls need to be > specified as part of the ICE usage.=B2 > >This seems ambiguous. Is it the implementation=B9s decision to institute >such controls, or is each ICE usage spec expected to make a decision that >applies to all implementations of that usage? I think we could allow both ICE usage-specified and implementation-specific mechanisms. Maybe re-write as following: "If these potential attacks can not be mitigates, ICE usages can define mechanisms for controlling which addresses are revealed to the negotiation and/or probing process. Individual implementations may also have implementation-specific rules for controlling=20 which addresses are revealed." >Should =B3secure signaling techniques=B2 distinguish between HBH and E2E >techniques, in light of the later discussion about insider attacks? Later down in the reply I suggest to remove the bullet list. --- >-17,1, false peer reflexive candidate: Should this mention SRTP (or >DTLS-SRTP) as a mitigating countermeasure? The list itself does not describe the countermeasures. SRTP is mentioned in the last paragraph of the section. =3D=3D=3D=3D >Editorial Comments and Nits: > >Is there a reason that the Security Considerations and IANA >considerations are not in the conventional locations (i.e. the last two >sections before the references)? (I see that is also true in 5245, so >this is mostly curiosity.) No reason. I suggest to move the sections. --- >-1, last paragraph: Would it make sense to change =B3exchanged via >mechanisms=B2 (which seems a tautology) to =B3exchanged via various >mechanisms=B2, =B3exchanged by application-specific mechanisms=B2, or >something similar? The document introduces the =B3ICE usage=B2 concept, so I suggest to say =B3exchanged with ICE usage-specific mechanisms=B2. --- >=8B Didn't 5245 already deprecate RFC 4091 and 4092? That is, _this_ >document does not do that. I suggest to remove the sentence, and the RFC references. --- >-2.1, first paragraph: "Naturally, one viable candidate has a transport >address obtained directly from a > local interface=B2 > >Shouldn=B9t that say =B3one or more viable candidates have=8A.=B2? or =B3A= t least >one=8A=B2? I suggest to say =B3At least one=B2. --- >-2.1, 4th paragraph from end: It would be helpful to describe what =B3vali= d >pair=B2 means earlier in the document. I assume you mean section 2.2? I suggest to following modification: "The agent works through the check list by sending a STUN request for the next candidate pair on the list periodically. These are called ordinary checks. When a STUN transaction succeeds, one or more candidate pairs will become so called valid pairs, and will be added to a candidate pair list called the valid list. =20 As an optimization, as soon as R gets L's check message, R schedules a connectivity check message to be sent to L on the same candidate pair. This is called a triggered check, and accelerates the process of finding valid pairs." I would not like to add more details to section 2 (I think it=B9s too detailed already), but I suggest to add the following to section 4: "Valid Pair: A candidate pair whose local candidate equals the mapped address of the connectivity check response, and whose remote candidate equals the destination address to which the connectivity check request was sent." Related to this, I note that the document uses both =B3valid pair=B2 and =B3valid candidate pair=B2 terminology. Perhaps it=B9s enough to say =B3val= id pair=B2 everywhere. Related to this, there is a bug in section 2.3. The text shall say: "For each component of a data stream, the controlling agent nominates a valid pair from the valid list to be used for data." --- >-2.3, figure 4: The figure still says =B3flag=B2, while the text has been >changed in several place to speak of the nominated =B3attribute=B2. Please >use one or the other consistently. I will s/flag/attribute in the figure. Elsewhere the usage of =B3flag=B2 is correct. --- >-4: There are at least a few uses of lower case =B3must=B2 and =B3should= =B2 that >do not appear to have been intended as keywords. If that is the intent, >please update this to use the boilerplate from 8174. (The 2119 >boilerplate is ambiguous on whether lower case instances count as >keywords.) I suggest we keep the 2119 boilerplate, but I will go through the lower case instances and see whether they should be capitalized. --- >s/=B3=8A defined in the STUN=8A=B2 / =B3=8A defined in STUN=8A =B3 or =B3= =8A defined in the >STUN protocol =8A=B2 In order to be aligned with the rest of the document, I suggest to simply say =B3defined in [RFC5389]=B2. --- >-5, last paragraph: The figure does not actually mention =B3default >candidate selection=B2. I suggest to remove that part, and say: "As shown, the agents involved in the candidate exchange perform (1) candidate gathering, (2) candidate prioritization, (3) redundant candidate elimination and (4) sending of the candidates to the peer." As shown, I also removed the last sentence regarding lite implementations. I don=B9t think it is needed, since the picture is a high-level overview. --- >-5.1.1, last paragraph, last sentence: Is the MAY applicable just to the >responding agent, or both agents? I suggest to remove the last sentence. The text already says that the gathering can start before the user is alerted. --- >-5.1.1.2, first paragraph : =B3Those requirements are at SHOULD strength= =8A=B2 >I suggest putting =B3SHOULD=B2 in quotes when talking about a requirement >stated elsewhere. (Even if that =B3elsewhere=B2 is in the same sentence :-= ) ) I suggest to remove the sentence, and begin the following sentence with: "However, use of STUN and TURN servers may be unnecessary in=8A" --- >-5.1.1.3, first paragraph: "Two candidates MUST have the same foundation >when all of the following are true=B2 >That seems like a statement of fact. (Same for the last paragraph talking >about different foundations.) I suggest to remove =B3MUST=B2. --- >- 5.1.2.1: Missing article before =B3IP Address for which the candidate=8A= =B2 >(This section also seems to have a lot of 2119 keywords that are really >statements of fact or definition. But I recognize those come from the >original 5245 text.) I suggest to say =B3the IP Address=B2. I suggest to keep the 2119 keywords. --- >-6.1.2, 2nd sentence: =B3 To form a check list, an ICE agent (initiating >and responding) forms candidate pairs" >Consider : =B3To form check lists, initiating and responding ICE agents >form candidate pairs=8A=B2 I will fix as suggested. --- >-7.2.5.2.1: =B3MUST be equal the destination IP address=B2 > >Consider =B3MUST equal=B2 or =B3MUST be equal to=B2 I will change to =B3MUST be equal to=B2. --- >-12.3: =B3 As discussed below, ICE agents are encouraged to re-adjust >jitter buffers=8A=B2 >Please cite the specific section(s). I actually suggest to remove section 12.3. It is about receiving data, and the content is covered in section 13. I also suggest to change section 12.3 to 12.2.1, as the text is only about sending media. I also suggest to change section 13 to 12.3. It was always intended to be a subsection to section 12. --- >- 17, last 3 paragraphs: With the expansion of the security >considerations, this list does not include all the countermeasures >mentioned in the later sections. I suggest to remove the list, and say: "There are several types of attacks possible in an ICE system. This section considers these attacks and their countermeasures." --- >-17.2, last bullet: Why call out viruses specifically? It seems like >there are a lot of ways a server might be compromised that do not involve >viruses per se. (Same in 17.3). My only answer is that this is text from RFC 5245. I can remove =B3virus=B2, and simply say: "An attacker can compromise a STUN server, and cause it to send responses with incorrect mapped addresses.=B2 (17.2) =8Aand: "However, TURN servers are susceptible to DNS attacks for purposes of turning it into a zombie or rogue server." --- >-17.4.1: Since the description of the voice hammer attack has been >removed, can you cite something that does describe it? (Appendix A still >refers to section 17 to describe the voice hammer attack.) I didn=B9t really find a good citation, but maybe something like: "The STUN amplification attack is similar to a voice hammer attack, where the attacker causes other agents to direct media traffic towards the attack target." I also realised that the following text needs to be removed from Appendix A: "in particular, the voice hammer attack described in Section 17 is prevented only for full implementations, not lite." --- >-17.4.1, 2nd paragraph: s/they=B9ll/=B3they will=B2 I will fix as suggested. --- >-22: Did you consider making this section an appendix? I don=B9t remember. I have no problem doing that, if you think an appendix would be better. Regards, Christer From nobody Tue Jan 9 06:44:08 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC64E12D86A; Tue, 9 Jan 2018 06:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xQoz3zP4MLM; Tue, 9 Jan 2018 06:44:03 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00A23126D0C; Tue, 9 Jan 2018 06:44:02 -0800 (PST) X-AuditID: c1b4fb2d-b35ff70000007932-3c-5a54d531eb95 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 25.43.31026.135D45A5; Tue, 9 Jan 2018 15:44:01 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Tue, 9 Jan 2018 15:44:00 +0100 From: Christer Holmberg To: Ben Campbell , "ice@ietf.org" , "draft-ietf-ice-rfc5245bis.all@ietf.org" Thread-Topic: AD Evaluation of draft-ietf-ice-rfc5245bis-15 - PULL REQUEST Thread-Index: AQHTiVhIvRSnUFT+Yk2FHzEjaViHPg== Date: Tue, 9 Jan 2018 14:43:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-ID: <531C2CF76FF70F4BB932294601741F76@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7ga7h1ZAog/bPfBbzO0+zWxz/8Yfd 4tuFWgdmjyVLfjJ5zNr5hCWAKYrLJiU1J7MstUjfLoEr48nbGawFt8or1tx6ztjAeKGki5GT Q0LARKJjy07GLkYuDiGBw4wS0/8uZYZwFjNKNN2ZwdrFyMHBJmAh0f1PG6RBRGAGo0T7i1AQ W1jAU+J6w25WiLiXxNnla9ggbD2JB7d2MoPYLAIqEiv7bjCC2LwC1hJTNvwFizMKiEl8P7WG CcRmFhCXuPVkPhPEQQISS/acZ4awRSVePv4HNl8UaOaGE7fZIeKKEh9f7WMEOY1ZQFNi/S59 iDHWEodankONVJSY0v2QHWKtoMTJmU9YJjCKzEKybRZC9ywk3bOQdM9C0r2AkXUVo2hxanFx brqRsV5qUWZycXF+nl5easkmRmCsHNzyW3cH4+rXjocYBTgYlXh4b58KiRJiTSwrrsw9xCjB wawkwus7PzhKiDclsbIqtSg/vqg0J7X4EKM0B4uSOO9JT94oIYH0xJLU7NTUgtQimCwTB6dU A2P5bnVZYeWYVrbr1c9uW7fvv7Pfull0yeoFLHI/ZzlUOz37cHFj7TcpaQPeP0Uxx4+53HM5 yBY/tePG9wlZr1h//tr390aN0bK1v1Z4rFoY0vU3yfj5qyW+hwRufi9cv9JtX9D8Y+vVk3nt /p3lE5A/2PAzKvpAwpV1v4/vPiXooBzA8XHV1TPySizFGYmGWsxFxYkA7bE2VZECAAA= Archived-At: Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-rfc5245bis-15 - PULL REQUEST X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 14:44:07 -0000 SGksDQoNCkJhc2VkIG9uIEJlbuKAmXMgcmV2aWV3LCBJIGhhdmUgY3JlYXRlZCBhIFBSOg0KDQpo dHRwczovL2dpdGh1Yi5jb20vaWNlLXdnL3JmYzUyNDViaXMvcHVsbC81NQ0KDQoNCkluIG9yZGVy IHRvIG1haW50YWluIHRoZSBQUiByZWFkYWJsZSwgaXQgZG9lcyAqbm90KiB5ZXQgaW5jbHVkZSBh bnkNCmNoZWNrLW11c3QtYW5kLXNob3VsZC1sb3Zlci1jYXNlIGZpeGVzLCBvciB2YWxpZC1wYWly LWFsaWdubWVudCBmaXhlcy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQpPbiAw OS8wMS8xOCAxNDo1OCwgIkNocmlzdGVyIEhvbG1iZXJnIiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPg0Kd3JvdGU6DQoNCj5IaSBCZW4sDQo+DQo+VGhhbmsgWW91IGZvciB0aGUgcmV2 aWV3ISBQbGVhc2Ugc2VlIGlubGluZS4NCj4NCj4+U3Vic3RhbnRpdmUgQ29tbWVudHM6DQo+Pg0K Pj4tIDIuMSwgMm5kIHRvIGxhc3Q6IERvZXMgSUNFIHJlYWxseSBwcmlvcml0aXplIGEgcGF0aCB3 aXRoIGZld2VyIE5BVHMNCj4+b3ZlciBhIHBhdGggd2l0aCBtb3JlIE5BVHMsIG9yIGlzIGl0IG1v cmUgYSBtYXR0ZXIgb2Ygc2VsZWN0aW5nIGEgcGF0aA0KPj53aXRoIG5vIE5BVHMgb3ZlciBhIHBh dGggd2l0aCDCs3NvbWXCsiBOQVRzPyAoSWYgdGhlIGZvcm1lciwgaG93IGRvZXMgaXQNCj4+Zmln dXJlIG91dCBob3cgbWFueSBOQVRzIGFyZSBiZXR3ZWVuIGFuIGFnZW50IGFuZCBpdMK5cyBzZXJ2 ZXJzIGFuZCBwZWVycz8NCj4+SXMgdGhpcyBqdXN0IGEgbWF0dGVyIG9mIHRpbWluZz8pDQo+DQo+ SUNFIGFnZW50cyBjYW7CuXQgZGV0ZXJtaW5lIGhvdyBtYW55IE5BVHMgdGhlcmUgYXJlLg0KPg0K Pkkgc3VnZ2VzdCB0byBzYXk6DQo+DQo+ICAgIkluIGdlbmVyYWwsIHRoZSBwcmlvcml0eSBhbGdv cml0aG0gaXMgZGVzaWduZWQgc28gdGhhdCBjYW5kaWRhdGVzIG9mDQo+ICAgIHNpbWlsYXIgdHlw ZSBnZXQgc2ltaWxhciBwcmlvcml0aWVzIGFuZCBzbyB0aGF0IG1vcmUgZGlyZWN0IHJvdXRlcw0K PiAgICAodGhhdCBpcywgcm91dGVzIHdpdGhvdXQgZGF0YSByZWxheXMgb3IgTkFUcykgYXJlIHBy ZWZlcnJlZCBvdmVyDQo+aW5kaXJlY3Qgcm91dGVzDQo+ICAgIChyb3V0ZXMgd2l0aCBkYXRhIHJl bGF5cyBvciBOQVRzKS4iDQo+DQo+DQo+LS0tLQ0KPg0KPj4tIDcuMi41LjIuMyBhbmQgNy4yLjUu Mi40OiBXaHkgYXJlIHRoZXNlIFNIT1VMRHMgbm90IE1VU1RzPyBEbyB5b3UNCj4+ZW52aXNpb24g Y2lyY3Vtc3RhbmNlcyB3aGVyZSBpdCBtaWdodCBtYWtlIHNlbnNlIF9ub3RfIHRvIHNldCB0aGUg c3RhdGUNCj4+dG8gRmFpbGVkPw0KPg0KPkkgY2Fuwrl0IHRoaW5rIG9mIGFueSBzdWNoIGNhc2Vz Lg0KPg0KPkkgc3VnZ2VzdCB0byBzL1NIT1VMRC9NVVNULg0KPg0KPi0tLS0NCj4NCj4+LTE3LCBm aXJzdCBwYXJhZ3JhcGg6IMKzIElmIHRoZXNlDQo+PiAgcG90ZW50aWFsIGF0dGFja3MgY2FuIG5v dCBiZSBtaXRpZ2F0ZWQsIHRoZSBpbXBsZW1lbnRhdGlvbiBtYXkgd2FudA0KPj4gIHRvIGluc3Rp dHV0ZSBjb250cm9scyBmb3Igd2hpY2ggYWRkcmVzc2VzIGFyZSByZXZlYWxlZCB0byB0aGUNCj4+ ICBuZWdvdGlhdGlvbiBhbmQvb3IgcHJvYmluZyBwcm9jZXNzLiAgU3VjaCBjb250cm9scyBuZWVk IHRvIGJlDQo+PiAgc3BlY2lmaWVkIGFzIHBhcnQgb2YgdGhlIElDRSB1c2FnZS7Csg0KPj4NCj4+ VGhpcyBzZWVtcyBhbWJpZ3VvdXMuIElzIGl0IHRoZSBpbXBsZW1lbnRhdGlvbsK5cyBkZWNpc2lv biB0byBpbnN0aXR1dGUNCj4+c3VjaCBjb250cm9scywgb3IgaXMgZWFjaCBJQ0UgdXNhZ2Ugc3Bl YyBleHBlY3RlZCB0byBtYWtlIGEgZGVjaXNpb24gdGhhdA0KPj5hcHBsaWVzIHRvIGFsbCBpbXBs ZW1lbnRhdGlvbnMgb2YgdGhhdCB1c2FnZT8NCj4NCj5JIHRoaW5rIHdlIGNvdWxkIGFsbG93IGJv dGggSUNFIHVzYWdlLXNwZWNpZmllZCBhbmQNCj5pbXBsZW1lbnRhdGlvbi1zcGVjaWZpYyBtZWNo YW5pc21zLiBNYXliZSByZS13cml0ZSBhcyBmb2xsb3dpbmc6DQo+DQo+ICAgICAgIklmIHRoZXNl IHBvdGVudGlhbCBhdHRhY2tzIGNhbiBub3QgYmUgbWl0aWdhdGVzLCBJQ0UgdXNhZ2VzIGNhbg0K PmRlZmluZSBtZWNoYW5pc21zIGZvciBjb250cm9sbGluZyB3aGljaCBhZGRyZXNzZXMgYXJlIHJl dmVhbGVkDQo+ICAgICAgIHRvIHRoZSBuZWdvdGlhdGlvbiBhbmQvb3IgcHJvYmluZyBwcm9jZXNz LiBJbmRpdmlkdWFsDQo+aW1wbGVtZW50YXRpb25zIG1heSBhbHNvIGhhdmUgaW1wbGVtZW50YXRp b24tc3BlY2lmaWMgcnVsZXMgZm9yDQo+Y29udHJvbGxpbmcgDQo+ICAgICAgIHdoaWNoIGFkZHJl c3NlcyBhcmUgcmV2ZWFsZWQuIg0KPg0KPj5TaG91bGQgwrNzZWN1cmUgc2lnbmFsaW5nIHRlY2hu aXF1ZXPCsiBkaXN0aW5ndWlzaCBiZXR3ZWVuIEhCSCBhbmQgRTJFDQo+PnRlY2huaXF1ZXMsIGlu IGxpZ2h0IG9mIHRoZSBsYXRlciBkaXNjdXNzaW9uIGFib3V0IGluc2lkZXIgYXR0YWNrcz8NCj4N Cj5MYXRlciBkb3duIGluIHRoZSByZXBseSBJIHN1Z2dlc3QgdG8gcmVtb3ZlIHRoZSBidWxsZXQg bGlzdC4NCj4NCj4tLS0NCj4NCj4+LTE3LDEsIGZhbHNlIHBlZXIgcmVmbGV4aXZlIGNhbmRpZGF0 ZTogU2hvdWxkIHRoaXMgbWVudGlvbiBTUlRQIChvcg0KPj5EVExTLVNSVFApICBhcyBhIG1pdGln YXRpbmcgY291bnRlcm1lYXN1cmU/DQo+DQo+VGhlIGxpc3QgaXRzZWxmIGRvZXMgbm90IGRlc2Ny aWJlIHRoZSBjb3VudGVybWVhc3VyZXMuIFNSVFAgaXMgbWVudGlvbmVkDQo+aW4gdGhlIGxhc3Qg cGFyYWdyYXBoIG9mIHRoZSBzZWN0aW9uLg0KPg0KPj09PT0NCj4NCj4+RWRpdG9yaWFsIENvbW1l bnRzIGFuZCBOaXRzOg0KPj4NCj4+SXMgdGhlcmUgYSByZWFzb24gdGhhdCB0aGUgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMgYW5kIElBTkENCj4+Y29uc2lkZXJhdGlvbnMgYXJlIG5vdCBpbiB0aGUg Y29udmVudGlvbmFsIGxvY2F0aW9ucyAoaS5lLiB0aGUgbGFzdCB0d28NCj4+c2VjdGlvbnMgYmVm b3JlIHRoZSByZWZlcmVuY2VzKT8gKEkgc2VlIHRoYXQgaXMgYWxzbyB0cnVlIGluIDUyNDUsIHNv DQo+PnRoaXMgaXMgbW9zdGx5IGN1cmlvc2l0eS4pDQo+DQo+Tm8gcmVhc29uLg0KPg0KPkkgc3Vn Z2VzdCB0byBtb3ZlIHRoZSBzZWN0aW9ucy4NCj4NCj4tLS0NCj4NCj4+LTEsIGxhc3QgcGFyYWdy YXBoOiBXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIGNoYW5nZSDCs2V4Y2hhbmdlZCB2aWENCj4+bWVj aGFuaXNtc8KyICh3aGljaCBzZWVtcyBhIHRhdXRvbG9neSkgdG8gwrNleGNoYW5nZWQgdmlhIHZh cmlvdXMNCj4+bWVjaGFuaXNtc8KyLCAgwrNleGNoYW5nZWQgYnkgYXBwbGljYXRpb24tc3BlY2lm aWMgbWVjaGFuaXNtc8KyLCBvcg0KPj5zb21ldGhpbmcgc2ltaWxhcj8NCj4NCj4NCj5UaGUgZG9j dW1lbnQgaW50cm9kdWNlcyB0aGUgwrNJQ0UgdXNhZ2XCsiBjb25jZXB0LCBzbyBJIHN1Z2dlc3Qg dG8gc2F5DQo+wrNleGNoYW5nZWQgd2l0aCBJQ0UgdXNhZ2Utc3BlY2lmaWMgbWVjaGFuaXNtc8Ky Lg0KPg0KPi0tLQ0KPg0KPj7igLkgRGlkbid0IDUyNDUgYWxyZWFkeSBkZXByZWNhdGUgUkZDIDQw OTEgYW5kIDQwOTI/IFRoYXQgaXMsIF90aGlzXw0KPj5kb2N1bWVudCBkb2VzIG5vdCBkbyB0aGF0 Lg0KPg0KPkkgc3VnZ2VzdCB0byByZW1vdmUgdGhlIHNlbnRlbmNlLCBhbmQgdGhlIFJGQyByZWZl cmVuY2VzLg0KPg0KPi0tLQ0KPg0KPj4tMi4xLCBmaXJzdCBwYXJhZ3JhcGg6ICJOYXR1cmFsbHks IG9uZSB2aWFibGUgY2FuZGlkYXRlIGhhcyBhIHRyYW5zcG9ydA0KPj5hZGRyZXNzIG9idGFpbmVk IGRpcmVjdGx5IGZyb20gYQ0KPj4gIGxvY2FsIGludGVyZmFjZcKyDQo+Pg0KPj5TaG91bGRuwrl0 IHRoYXQgc2F5IMKzb25lIG9yIG1vcmUgdmlhYmxlIGNhbmRpZGF0ZXMgaGF2ZcWgLsKyPyBvciDC s0F0IGxlYXN0DQo+Pm9uZcWgwrI/DQo+DQo+SSBzdWdnZXN0IHRvIHNheSDCs0F0IGxlYXN0IG9u ZcKyLg0KPg0KPi0tLQ0KPg0KPj4tMi4xLCA0dGggcGFyYWdyYXBoIGZyb20gZW5kOiBJdCB3b3Vs ZCBiZSBoZWxwZnVsIHRvIGRlc2NyaWJlIHdoYXQgwrN2YWxpZA0KPj5wYWlywrIgbWVhbnMgZWFy bGllciBpbiB0aGUgZG9jdW1lbnQuDQo+DQo+SSBhc3N1bWUgeW91IG1lYW4gc2VjdGlvbiAyLjI/ DQo+DQo+SSBzdWdnZXN0IHRvIGZvbGxvd2luZyBtb2RpZmljYXRpb246DQo+DQo+ICAgICJUaGUg YWdlbnQgd29ya3MgdGhyb3VnaCB0aGUgY2hlY2sgbGlzdCBieSBzZW5kaW5nIGEgU1RVTiByZXF1 ZXN0IGZvcg0KPiAgICAgdGhlIG5leHQgY2FuZGlkYXRlIHBhaXIgb24gdGhlIGxpc3QgcGVyaW9k aWNhbGx5LiAgVGhlc2UgYXJlIGNhbGxlZA0KPiAgICAgb3JkaW5hcnkgY2hlY2tzLiBXaGVuIGEg U1RVTiB0cmFuc2FjdGlvbiBzdWNjZWVkcywgb25lIG9yIG1vcmUNCj4gICAgIGNhbmRpZGF0ZSBw YWlycyB3aWxsIGJlY29tZSBzbyBjYWxsZWQgdmFsaWQgcGFpcnMsIGFuZCB3aWxsIGJlIGFkZGVk DQo+ICAgICB0byBhIGNhbmRpZGF0ZSBwYWlyIGxpc3QgY2FsbGVkIHRoZSB2YWxpZCBsaXN0Lg0K PiANCj4NCj4gICAgIEFzIGFuIG9wdGltaXphdGlvbiwgYXMgc29vbiBhcyBSIGdldHMgTCdzIGNo ZWNrIG1lc3NhZ2UsIFIgc2NoZWR1bGVzDQo+ICAgICBhIGNvbm5lY3Rpdml0eSBjaGVjayBtZXNz YWdlIHRvIGJlIHNlbnQgdG8gTCBvbiB0aGUgc2FtZSBjYW5kaWRhdGUNCj4gICAgIHBhaXIuIFRo aXMgaXMgY2FsbGVkIGEgdHJpZ2dlcmVkIGNoZWNrLCBhbmQgYWNjZWxlcmF0ZXMgdGhlIHByb2Nl c3MNCj4gICAgIG9mIGZpbmRpbmcgdmFsaWQgcGFpcnMuIg0KPg0KPg0KPkkgd291bGQgbm90IGxp a2UgdG8gYWRkIG1vcmUgZGV0YWlscyB0byBzZWN0aW9uIDIgKEkgdGhpbmsgaXTCuXMgdG9vDQo+ ZGV0YWlsZWQgYWxyZWFkeSksIGJ1dCBJIHN1Z2dlc3QgdG8gYWRkDQo+dGhlIGZvbGxvd2luZyB0 byBzZWN0aW9uIDQ6DQo+DQo+ICAgICJWYWxpZCBQYWlyOiBBIGNhbmRpZGF0ZSBwYWlyIHdob3Nl IGxvY2FsIGNhbmRpZGF0ZSBlcXVhbHMgdGhlIG1hcHBlZA0KPmFkZHJlc3Mgb2YgdGhlIGNvbm5l Y3Rpdml0eSBjaGVjayByZXNwb25zZSwNCj4gICAgIGFuZCB3aG9zZSByZW1vdGUgY2FuZGlkYXRl IGVxdWFscyB0aGUgZGVzdGluYXRpb24gYWRkcmVzcyB0byB3aGljaA0KPnRoZSBjb25uZWN0aXZp dHkgY2hlY2sgcmVxdWVzdCB3YXMgc2VudC4iDQo+DQo+DQo+UmVsYXRlZCB0byB0aGlzLCBJIG5v dGUgdGhhdCB0aGUgZG9jdW1lbnQgdXNlcyBib3RoIMKzdmFsaWQgcGFpcsKyIGFuZA0KPsKzdmFs aWQgY2FuZGlkYXRlIHBhaXLCsiB0ZXJtaW5vbG9neS4gUGVyaGFwcyBpdMK5cyBlbm91Z2ggdG8g c2F5IMKzdmFsaWQNCj5wYWlywrIgZXZlcnl3aGVyZS4NCj4NCj5SZWxhdGVkIHRvIHRoaXMsIHRo ZXJlIGlzIGEgYnVnIGluIHNlY3Rpb24gMi4zLiBUaGUgdGV4dCBzaGFsbCBzYXk6DQo+DQo+ICAg ICJGb3IgZWFjaCBjb21wb25lbnQgb2YgYSBkYXRhIHN0cmVhbSwgdGhlIGNvbnRyb2xsaW5nIGFn ZW50IG5vbWluYXRlcw0KPmEgdmFsaWQgcGFpciBmcm9tDQo+ICAgICB0aGUgdmFsaWQgbGlzdCB0 byBiZSB1c2VkIGZvciBkYXRhLiINCj4NCj4NCj4tLS0NCj4NCj4+LTIuMywgZmlndXJlIDQ6IFRo ZSBmaWd1cmUgc3RpbGwgc2F5cyDCs2ZsYWfCsiwgd2hpbGUgdGhlIHRleHQgaGFzIGJlZW4NCj4+ Y2hhbmdlZCBpbiBzZXZlcmFsIHBsYWNlIHRvIHNwZWFrIG9mIHRoZSBub21pbmF0ZWQgwrNhdHRy aWJ1dGXCsi4gUGxlYXNlDQo+PnVzZSBvbmUgb3IgdGhlIG90aGVyIGNvbnNpc3RlbnRseS4NCj4N Cj5JIHdpbGwgcy9mbGFnL2F0dHJpYnV0ZSBpbiB0aGUgZmlndXJlLiBFbHNld2hlcmUgdGhlIHVz YWdlIG9mIMKzZmxhZ8KyIGlzDQo+Y29ycmVjdC4NCj4NCj4tLS0NCj4NCj4+LTQ6IFRoZXJlIGFy ZSBhdCBsZWFzdCBhIGZldyB1c2VzIG9mIGxvd2VyIGNhc2UgwrNtdXN0wrIgYW5kIMKzc2hvdWxk wrIgdGhhdA0KPj5kbyBub3QgYXBwZWFyIHRvIGhhdmUgYmVlbiBpbnRlbmRlZCBhcyBrZXl3b3Jk cy4gSWYgdGhhdCBpcyB0aGUgaW50ZW50LA0KPj5wbGVhc2UgdXBkYXRlIHRoaXMgdG8gdXNlIHRo ZSBib2lsZXJwbGF0ZSBmcm9tIDgxNzQuICAoVGhlIDIxMTkNCj4+Ym9pbGVycGxhdGUgaXMgYW1i aWd1b3VzIG9uIHdoZXRoZXIgbG93ZXIgY2FzZSBpbnN0YW5jZXMgY291bnQgYXMNCj4+a2V5d29y ZHMuKQ0KPg0KPg0KPkkgc3VnZ2VzdCB3ZSBrZWVwIHRoZSAyMTE5IGJvaWxlcnBsYXRlLCBidXQg SSB3aWxsIGdvIHRocm91Z2ggdGhlIGxvd2VyDQo+Y2FzZSBpbnN0YW5jZXMgYW5kIHNlZSB3aGV0 aGVyIHRoZXkgc2hvdWxkIGJlIGNhcGl0YWxpemVkLg0KPg0KPi0tLQ0KPg0KPj5zL8KzxaAgZGVm aW5lZCBpbiB0aGUgU1RVTsWgwrIgLyDCs8WgIGRlZmluZWQgaW4gU1RVTsWgIMKzIG9yIMKzxaAg ZGVmaW5lZCBpbiB0aGUNCj4+U1RVTiBwcm90b2NvbCDFoMKyDQo+DQo+SW4gb3JkZXIgdG8gYmUg YWxpZ25lZCB3aXRoIHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudCwgSSBzdWdnZXN0IHRvIHNpbXBs eQ0KPnNheSDCs2RlZmluZWQgaW4gW1JGQzUzODldwrIuDQo+DQo+LS0tDQo+DQo+Pi01LCBsYXN0 IHBhcmFncmFwaDogVGhlIGZpZ3VyZSBkb2VzIG5vdCBhY3R1YWxseSBtZW50aW9uIMKzZGVmYXVs dA0KPj5jYW5kaWRhdGUgc2VsZWN0aW9uwrIuDQo+DQo+SSBzdWdnZXN0IHRvIHJlbW92ZSB0aGF0 IHBhcnQsIGFuZCBzYXk6DQo+DQo+IkFzIHNob3duLCB0aGUgYWdlbnRzIGludm9sdmVkIGluIHRo ZSBjYW5kaWRhdGUgZXhjaGFuZ2UgcGVyZm9ybSAoMSkNCj4gICBjYW5kaWRhdGUgZ2F0aGVyaW5n LCAoMikgY2FuZGlkYXRlIHByaW9yaXRpemF0aW9uLCAoMykgcmVkdW5kYW50DQo+ICAgY2FuZGlk YXRlIGVsaW1pbmF0aW9uIGFuZCAoNCkgc2VuZGluZyBvZiB0aGUgY2FuZGlkYXRlcyB0byB0aGUg cGVlci4iDQo+DQo+DQo+QXMgc2hvd24sIEkgYWxzbyByZW1vdmVkIHRoZSBsYXN0IHNlbnRlbmNl IHJlZ2FyZGluZyBsaXRlIGltcGxlbWVudGF0aW9ucy4NCj5JIGRvbsK5dCB0aGluayBpdCBpcyBu ZWVkZWQsIHNpbmNlIHRoZSBwaWN0dXJlIGlzIGEgaGlnaC1sZXZlbCBvdmVydmlldy4NCj4NCj4t LS0NCj4NCj4+LTUuMS4xLCBsYXN0IHBhcmFncmFwaCwgbGFzdCBzZW50ZW5jZTogSXMgdGhlIE1B WSBhcHBsaWNhYmxlIGp1c3QgdG8gdGhlDQo+PnJlc3BvbmRpbmcgYWdlbnQsIG9yIGJvdGggYWdl bnRzPw0KPg0KPkkgc3VnZ2VzdCB0byByZW1vdmUgdGhlIGxhc3Qgc2VudGVuY2UuIFRoZSB0ZXh0 IGFscmVhZHkgc2F5cyB0aGF0IHRoZQ0KPmdhdGhlcmluZyBjYW4gc3RhcnQgYmVmb3JlIHRoZSB1 c2VyIGlzIGFsZXJ0ZWQuDQo+DQo+LS0tDQo+DQo+Pi01LjEuMS4yLCBmaXJzdCBwYXJhZ3JhcGgg OiDCs1Rob3NlIHJlcXVpcmVtZW50cyBhcmUgYXQgU0hPVUxEIHN0cmVuZ3RoxaDCsg0KPj5JIHN1 Z2dlc3QgcHV0dGluZyDCs1NIT1VMRMKyIGluIHF1b3RlcyB3aGVuIHRhbGtpbmcgYWJvdXQgYSBy ZXF1aXJlbWVudA0KPj5zdGF0ZWQgZWxzZXdoZXJlLiAoRXZlbiBpZiB0aGF0IMKzZWxzZXdoZXJl wrIgaXMgaW4gdGhlIHNhbWUgc2VudGVuY2UgOi0pDQo+PikNCj4NCj5JIHN1Z2dlc3QgdG8gcmVt b3ZlIHRoZSBzZW50ZW5jZSwgYW5kIGJlZ2luIHRoZSBmb2xsb3dpbmcgc2VudGVuY2Ugd2l0aDoN Cj4NCj4iSG93ZXZlciwgdXNlIG9mIFNUVU4gYW5kIFRVUk4gc2VydmVycyBtYXkgYmUgdW5uZWNl c3NhcnkgaW7FoCINCj4NCj4tLS0NCj4NCj4NCj4+LTUuMS4xLjMsIGZpcnN0IHBhcmFncmFwaDog IlR3byBjYW5kaWRhdGVzIE1VU1QgaGF2ZSB0aGUgc2FtZSBmb3VuZGF0aW9uDQo+PndoZW4gYWxs IG9mIHRoZSBmb2xsb3dpbmcgYXJlIHRydWXCsg0KPj5UaGF0IHNlZW1zIGxpa2UgYSBzdGF0ZW1l bnQgb2YgZmFjdC4gKFNhbWUgZm9yIHRoZSBsYXN0IHBhcmFncmFwaCB0YWxraW5nDQo+PmFib3V0 IGRpZmZlcmVudCBmb3VuZGF0aW9ucy4pDQo+DQo+SSBzdWdnZXN0IHRvIHJlbW92ZSDCs01VU1TC si4NCj4NCj4tLS0NCj4NCj4+LSA1LjEuMi4xOiBNaXNzaW5nIGFydGljbGUgYmVmb3JlIMKzSVAg QWRkcmVzcyBmb3Igd2hpY2ggdGhlIGNhbmRpZGF0ZcWgwrINCj4+KFRoaXMgc2VjdGlvbiBhbHNv IHNlZW1zIHRvIGhhdmUgYSBsb3Qgb2YgMjExOSBrZXl3b3JkcyB0aGF0IGFyZSByZWFsbHkNCj4+ c3RhdGVtZW50cyBvZiBmYWN0IG9yIGRlZmluaXRpb24uIEJ1dCBJIHJlY29nbml6ZSB0aG9zZSBj b21lIGZyb20gdGhlDQo+Pm9yaWdpbmFsIDUyNDUgdGV4dC4pDQo+DQo+SSBzdWdnZXN0IHRvIHNh eSDCs3RoZSBJUCBBZGRyZXNzwrIuDQo+DQo+SSBzdWdnZXN0IHRvIGtlZXAgdGhlIDIxMTkga2V5 d29yZHMuDQo+DQo+LS0tDQo+DQo+Pi02LjEuMiwgMm5kIHNlbnRlbmNlOiDCsyBUbyBmb3JtIGEg Y2hlY2sgbGlzdCwgYW4gSUNFIGFnZW50IChpbml0aWF0aW5nDQo+PmFuZCByZXNwb25kaW5nKSBm b3JtcyBjYW5kaWRhdGUgcGFpcnMiDQo+PkNvbnNpZGVyIDogwrNUbyBmb3JtIGNoZWNrIGxpc3Rz LCBpbml0aWF0aW5nIGFuZCByZXNwb25kaW5nIElDRSBhZ2VudHMNCj4+Zm9ybSBjYW5kaWRhdGUg cGFpcnPFoMKyDQo+DQo+SSB3aWxsIGZpeCBhcyBzdWdnZXN0ZWQuDQo+DQo+LS0tDQo+DQo+Pi03 LjIuNS4yLjE6IMKzTVVTVCBiZSBlcXVhbCB0aGUgZGVzdGluYXRpb24gSVAgYWRkcmVzc8KyDQo+ Pg0KPj5Db25zaWRlciDCs01VU1QgZXF1YWzCsiBvciDCs01VU1QgYmUgZXF1YWwgdG/Csg0KPg0K Pkkgd2lsbCBjaGFuZ2UgdG8gwrNNVVNUIGJlIGVxdWFsIHRvwrIuDQo+DQo+LS0tDQo+DQo+Pi0x Mi4zOiDCsyBBcyBkaXNjdXNzZWQgYmVsb3csIElDRSBhZ2VudHMgYXJlIGVuY291cmFnZWQgdG8g cmUtYWRqdXN0DQo+PmppdHRlciBidWZmZXJzxaDCsg0KPj5QbGVhc2UgY2l0ZSB0aGUgc3BlY2lm aWMgc2VjdGlvbihzKS4NCj4NCj5JIGFjdHVhbGx5IHN1Z2dlc3QgdG8gcmVtb3ZlIHNlY3Rpb24g MTIuMy4gSXQgaXMgYWJvdXQgcmVjZWl2aW5nIGRhdGEsIGFuZA0KPnRoZSBjb250ZW50IGlzIGNv dmVyZWQgaW4gc2VjdGlvbiAxMy4NCj4NCj5JIGFsc28gc3VnZ2VzdCB0byBjaGFuZ2Ugc2VjdGlv biAxMi4zIHRvIDEyLjIuMSwgYXMgdGhlIHRleHQgaXMgb25seSBhYm91dA0KPnNlbmRpbmcgbWVk aWEuDQo+DQo+SSBhbHNvIHN1Z2dlc3QgdG8gY2hhbmdlIHNlY3Rpb24gMTMgdG8gMTIuMy4gSXQg d2FzIGFsd2F5cyBpbnRlbmRlZCB0byBiZQ0KPmEgc3Vic2VjdGlvbiB0byBzZWN0aW9uIDEyLg0K Pg0KPi0tLQ0KPg0KPj4tIDE3LCBsYXN0IDMgcGFyYWdyYXBoczogV2l0aCB0aGUgZXhwYW5zaW9u IG9mIHRoZSBzZWN1cml0eQ0KPj5jb25zaWRlcmF0aW9ucywgdGhpcyBsaXN0IGRvZXMgbm90IGlu Y2x1ZGUgYWxsIHRoZSBjb3VudGVybWVhc3VyZXMNCj4+bWVudGlvbmVkIGluIHRoZSBsYXRlciBz ZWN0aW9ucy4NCj4NCj5JIHN1Z2dlc3QgdG8gcmVtb3ZlIHRoZSBsaXN0LCBhbmQgc2F5Og0KPg0K PiAgICAiVGhlcmUgYXJlIHNldmVyYWwgdHlwZXMgb2YgYXR0YWNrcyBwb3NzaWJsZSBpbiBhbiBJ Q0Ugc3lzdGVtLiAgVGhpcw0KPiAgICAgc2VjdGlvbiBjb25zaWRlcnMgdGhlc2UgYXR0YWNrcyBh bmQgdGhlaXIgY291bnRlcm1lYXN1cmVzLiINCj4NCj4NCj4tLS0NCj4NCj4+LTE3LjIsIGxhc3Qg YnVsbGV0OiBXaHkgY2FsbCBvdXQgdmlydXNlcyBzcGVjaWZpY2FsbHk/IEl0IHNlZW1zIGxpa2UN Cj4+dGhlcmUgYXJlIGEgbG90IG9mIHdheXMgYSBzZXJ2ZXIgbWlnaHQgYmUgY29tcHJvbWlzZWQg dGhhdCBkbyBub3QgaW52b2x2ZQ0KPj52aXJ1c2VzIHBlciBzZS4gKFNhbWUgaW4gMTcuMykuDQo+ DQo+IE15IG9ubHkgYW5zd2VyIGlzIHRoYXQgdGhpcyBpcyB0ZXh0IGZyb20gUkZDIDUyNDUuDQo+ DQo+SSBjYW4gcmVtb3ZlIMKzdmlydXPCsiwgYW5kIHNpbXBseSBzYXk6DQo+DQo+IkFuIGF0dGFj a2VyIGNhbiBjb21wcm9taXNlIGEgU1RVTiBzZXJ2ZXIsIGFuZCBjYXVzZSBpdCB0byBzZW5kIHJl c3BvbnNlcw0KPndpdGggaW5jb3JyZWN0IG1hcHBlZCBhZGRyZXNzZXMuwrIgKDE3LjIpDQo+DQo+ DQo+xaBhbmQ6DQo+DQo+Ikhvd2V2ZXIsIFRVUk4gc2VydmVycyBhcmUgc3VzY2VwdGlibGUgdG8g RE5TIGF0dGFja3MgZm9yIHB1cnBvc2VzIG9mDQo+dHVybmluZyBpdCBpbnRvIGEgem9tYmllIG9y IHJvZ3VlIHNlcnZlci4iDQo+DQo+DQo+LS0tDQo+DQo+Pi0xNy40LjE6IFNpbmNlIHRoZSBkZXNj cmlwdGlvbiBvZiB0aGUgdm9pY2UgaGFtbWVyIGF0dGFjayBoYXMgYmVlbg0KPj5yZW1vdmVkLCBj YW4geW91IGNpdGUgc29tZXRoaW5nIHRoYXQgZG9lcyBkZXNjcmliZSBpdD8gKEFwcGVuZGl4IEEg c3RpbGwNCj4+cmVmZXJzIHRvIHNlY3Rpb24gMTcgdG8gZGVzY3JpYmUgdGhlIHZvaWNlIGhhbW1l ciBhdHRhY2suKQ0KPg0KPkkgZGlkbsK5dCByZWFsbHkgZmluZCBhIGdvb2QgY2l0YXRpb24sIGJ1 dCBtYXliZSBzb21ldGhpbmcgbGlrZToNCj4NCj4iVGhlIFNUVU4gYW1wbGlmaWNhdGlvbiBhdHRh Y2sgaXMgc2ltaWxhciB0byBhIHZvaWNlIGhhbW1lciBhdHRhY2ssIHdoZXJlDQo+dGhlIGF0dGFj a2VyIGNhdXNlcyBvdGhlciBhZ2VudHMgdG8gZGlyZWN0IG1lZGlhIHRyYWZmaWMgdG93YXJkcyB0 aGUNCj5hdHRhY2sgdGFyZ2V0LiINCj4NCj4NCj5JIGFsc28gcmVhbGlzZWQgdGhhdCB0aGUgZm9s bG93aW5nIHRleHQgbmVlZHMgdG8gYmUgcmVtb3ZlZCBmcm9tIEFwcGVuZGl4DQo+QToNCj4NCj4i aW4gcGFydGljdWxhciwgdGhlIHZvaWNlIGhhbW1lciBhdHRhY2sgZGVzY3JpYmVkIGluIFNlY3Rp b24gMTcgaXMNCj4gICBwcmV2ZW50ZWQgb25seSBmb3IgZnVsbCBpbXBsZW1lbnRhdGlvbnMsIG5v dCBsaXRlLiINCj4NCj4NCj4tLS0NCj4NCj4+LTE3LjQuMSwgMm5kIHBhcmFncmFwaDogcy90aGV5 wrlsbC/Cs3RoZXkgd2lsbMKyDQo+DQo+SSB3aWxsIGZpeCBhcyBzdWdnZXN0ZWQuDQo+DQo+LS0t DQo+DQo+Pi0yMjogRGlkIHlvdSBjb25zaWRlciBtYWtpbmcgdGhpcyBzZWN0aW9uIGFuIGFwcGVu ZGl4Pw0KPg0KPkkgZG9uwrl0IHJlbWVtYmVyLiBJIGhhdmUgbm8gcHJvYmxlbSBkb2luZyB0aGF0 LCBpZiB5b3UgdGhpbmsgYW4gYXBwZW5kaXgNCj53b3VsZCBiZSBiZXR0ZXIuDQo+DQo+UmVnYXJk cywNCj4NCj5DaHJpc3Rlcg0KPg0KDQo= From nobody Tue Jan 9 09:25:01 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A47127522; Tue, 9 Jan 2018 09:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDLVUhRALlsq; Tue, 9 Jan 2018 09:24:57 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8866F12422F; Tue, 9 Jan 2018 09:24:57 -0800 (PST) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w09HOlfj077126 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 9 Jan 2018 11:24:48 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: <54D05F30-E2A1-42E4-BAEF-D39D134D0C49@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F27841E6-A94B-45AB-9DAF-14999088C8C0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 9 Jan 2018 11:24:46 -0600 In-Reply-To: Cc: "ice@ietf.org" , "draft-ietf-ice-rfc5245bis.all@ietf.org" To: Christer Holmberg References: <28E9DD8B-5FEC-468D-B745-30D21E504B9D@nostrum.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-rfc5245bis-15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 17:25:00 -0000 --Apple-Mail=_F27841E6-A94B-45AB-9DAF-14999088C8C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 9, 2018, at 6:58 AM, Christer Holmberg = wrote: >=20 > Hi Ben, >=20 > Thank You for the review! Please see inline. >=20 >> Substantive Comments: >>=20 >> - 2.1, 2nd to last: Does ICE really prioritize a path with fewer NATs >> over a path with more NATs, or is it more a matter of selecting a = path >> with no NATs over a path with =C2=B3some=C2=B2 NATs? (If the former, = how does it >> figure out how many NATs are between an agent and it=C2=B9s servers = and peers? >> Is this just a matter of timing?) >=20 > ICE agents can=C2=B9t determine how many NATs there are. >=20 > I suggest to say: >=20 > "In general, the priority algorithm is designed so that candidates = of > similar type get similar priorities and so that more direct routes > (that is, routes without data relays or NATs) are preferred over > indirect routes > (routes with data relays or NATs).=E2=80=9D >=20 WFM >=20 > ---- >=20 >> - 7.2.5.2.3 and 7.2.5.2.4: Why are these SHOULDs not MUSTs? Do you >> envision circumstances where it might make sense _not_ to set the = state >> to Failed? >=20 > I can=C2=B9t think of any such cases. >=20 > I suggest to s/SHOULD/MUST. Okay. (Shepherd: Please note that this would be a normative change that = should be pointed out to the WG.) >=20 > ---- >=20 >> -17, first paragraph: =C2=B3 If these >> potential attacks can not be mitigated, the implementation may want >> to institute controls for which addresses are revealed to the >> negotiation and/or probing process. Such controls need to be >> specified as part of the ICE usage.=C2=B2 >>=20 >> This seems ambiguous. Is it the implementation=C2=B9s decision to = institute >> such controls, or is each ICE usage spec expected to make a decision = that >> applies to all implementations of that usage? >=20 > I think we could allow both ICE usage-specified and > implementation-specific mechanisms. Maybe re-write as following: >=20 > "If these potential attacks can not be mitigates, ICE usages can > define mechanisms for controlling which addresses are revealed > to the negotiation and/or probing process. Individual > implementations may also have implementation-specific rules for > controlling > which addresses are revealed.=E2=80=9D WFM. >=20 >> Should =C2=B3secure signaling techniques=C2=B2 distinguish between = HBH and E2E >> techniques, in light of the later discussion about insider attacks? >=20 > Later down in the reply I suggest to remove the bullet list. Okay, does it make sense to discuss HBH vs E2E protections in the = section about insider attacks? >=20 > --- >=20 >> -17,1, false peer reflexive candidate: Should this mention SRTP (or >> DTLS-SRTP) as a mitigating countermeasure? >=20 > The list itself does not describe the countermeasures. SRTP is = mentioned > in the last paragraph of the section. Ah, okay. >=20 > =3D=3D=3D=3D >=20 >> Editorial Comments and Nits: >>=20 >> Is there a reason that the Security Considerations and IANA >> considerations are not in the conventional locations (i.e. the last = two >> sections before the references)? (I see that is also true in 5245, so >> this is mostly curiosity.) >=20 > No reason. >=20 > I suggest to move the sections. >=20 Okay. (I=E2=80=99m also okay leaving it as is unless someone objects in = IETF LC). > --- >=20 >> -1, last paragraph: Would it make sense to change =C2=B3exchanged via >> mechanisms=C2=B2 (which seems a tautology) to =C2=B3exchanged via = various >> mechanisms=C2=B2, =C2=B3exchanged by application-specific = mechanisms=C2=B2, or >> something similar? >=20 >=20 > The document introduces the =C2=B3ICE usage=C2=B2 concept, so I = suggest to say > =C2=B3exchanged with ICE usage-specific mechanisms=C2=B2. Okay. >=20 > --- >=20 >> =E2=80=B9 Didn't 5245 already deprecate RFC 4091 and 4092? That is, = _this_ >> document does not do that. >=20 > I suggest to remove the sentence, and the RFC references. I=E2=80=99m okay with that, but it might be helpful to merely adjust the = wording to say that 5245 deprecated them. >=20 > --- >=20 >> -2.1, first paragraph: "Naturally, one viable candidate has a = transport >> address obtained directly from a >> local interface=C2=B2 >>=20 >> Shouldn=C2=B9t that say =C2=B3one or more viable candidates = have=C5=A0.=C2=B2? or =C2=B3At least >> one=C5=A0=C2=B2? >=20 > I suggest to say =C2=B3At least one=C2=B2. Okay. >=20 > --- >=20 >> -2.1, 4th paragraph from end: It would be helpful to describe what = =C2=B3valid >> pair=C2=B2 means earlier in the document. >=20 > I assume you mean section 2.2? Sorry, yes. >=20 > I suggest to following modification: >=20 > "The agent works through the check list by sending a STUN request = for > the next candidate pair on the list periodically. These are = called > ordinary checks. When a STUN transaction succeeds, one or more > candidate pairs will become so called valid pairs, and will be = added > to a candidate pair list called the valid list. >=20 >=20 > As an optimization, as soon as R gets L's check message, R = schedules > a connectivity check message to be sent to L on the same candidate > pair. This is called a triggered check, and accelerates the = process > of finding valid pairs.=E2=80=9D WFM >=20 >=20 > I would not like to add more details to section 2 (I think it=C2=B9s = too > detailed already), but I suggest to add > the following to section 4: >=20 > "Valid Pair: A candidate pair whose local candidate equals the = mapped > address of the connectivity check response, > and whose remote candidate equals the destination address to which > the connectivity check request was sent.=E2=80=9D Also WFM. >=20 >=20 > Related to this, I note that the document uses both =C2=B3valid pair=C2=B2= and > =C2=B3valid candidate pair=C2=B2 terminology. Perhaps it=C2=B9s enough = to say =C2=B3valid > pair=C2=B2 everywhere. >=20 > Related to this, there is a bug in section 2.3. The text shall say: >=20 > "For each component of a data stream, the controlling agent = nominates > a valid pair from > the valid list to be used for data.=E2=80=9D I=E2=80=99m okay either way. (While I usually prefer consistency, I = imagine that people can figure this one out.) >=20 >=20 > --- >=20 >> -2.3, figure 4: The figure still says =C2=B3flag=C2=B2, while the = text has been >> changed in several place to speak of the nominated =C2=B3attribute=C2=B2= . Please >> use one or the other consistently. >=20 > I will s/flag/attribute in the figure. Elsewhere the usage of =C2=B3flag= =C2=B2 is > correct. Okay >=20 > --- >=20 >> -4: There are at least a few uses of lower case =C2=B3must=C2=B2 and = =C2=B3should=C2=B2 that >> do not appear to have been intended as keywords. If that is the = intent, >> please update this to use the boilerplate from 8174. (The 2119 >> boilerplate is ambiguous on whether lower case instances count as >> keywords.) >=20 >=20 > I suggest we keep the 2119 boilerplate, but I will go through the = lower > case instances and see whether they should be capitalized. Okay, although if you keep 2119, it might be better to change any that = should remain non-capitalized to non-colliding terms. >=20 > --- >=20 >> s/=C2=B3=C5=A0 defined in the STUN=C5=A0=C2=B2 / =C2=B3=C5=A0 defined = in STUN=C5=A0 =C2=B3 or =C2=B3=C5=A0 defined in the >> STUN protocol =C5=A0=C2=B2 >=20 > In order to be aligned with the rest of the document, I suggest to = simply > say =C2=B3defined in [RFC5389]=C2=B2. Okay >=20 > --- >=20 >> -5, last paragraph: The figure does not actually mention =C2=B3default >> candidate selection=C2=B2. >=20 > I suggest to remove that part, and say: >=20 > "As shown, the agents involved in the candidate exchange perform (1) > candidate gathering, (2) candidate prioritization, (3) redundant > candidate elimination and (4) sending of the candidates to the = peer." >=20 >=20 > As shown, I also removed the last sentence regarding lite = implementations. > I don=C2=B9t think it is needed, since the picture is a high-level = overview. Okay. >=20 > --- >=20 >> -5.1.1, last paragraph, last sentence: Is the MAY applicable just to = the >> responding agent, or both agents? >=20 > I suggest to remove the last sentence. The text already says that the > gathering can start before the user is alerted. Okay. >=20 > --- >=20 >> -5.1.1.2, first paragraph : =C2=B3Those requirements are at SHOULD = strength=C5=A0=C2=B2 >> I suggest putting =C2=B3SHOULD=C2=B2 in quotes when talking about a = requirement >> stated elsewhere. (Even if that =C2=B3elsewhere=C2=B2 is in the same = sentence :-) ) >=20 > I suggest to remove the sentence, and begin the following sentence = with: >=20 > "However, use of STUN and TURN servers may be unnecessary in=C5=A0=E2=80= =9D Okay. >=20 > --- >=20 >=20 >> -5.1.1.3, first paragraph: "Two candidates MUST have the same = foundation >> when all of the following are true=C2=B2 >> That seems like a statement of fact. (Same for the last paragraph = talking >> about different foundations.) >=20 > I suggest to remove =C2=B3MUST=C2=B2. Okay. >=20 > --- >=20 >> - 5.1.2.1: Missing article before =C2=B3IP Address for which the = candidate=C5=A0=C2=B2 >> (This section also seems to have a lot of 2119 keywords that are = really >> statements of fact or definition. But I recognize those come from the >> original 5245 text.) >=20 > I suggest to say =C2=B3the IP Address=C2=B2. >=20 > I suggest to keep the 2119 keywords. Okay. >=20 > --- >=20 >> -6.1.2, 2nd sentence: =C2=B3 To form a check list, an ICE agent = (initiating >> and responding) forms candidate pairs" >> Consider : =C2=B3To form check lists, initiating and responding ICE = agents >> form candidate pairs=C5=A0=C2=B2 >=20 > I will fix as suggested. Okay. >=20 > --- >=20 >> -7.2.5.2.1: =C2=B3MUST be equal the destination IP address=C2=B2 >>=20 >> Consider =C2=B3MUST equal=C2=B2 or =C2=B3MUST be equal to=C2=B2 >=20 > I will change to =C2=B3MUST be equal to=C2=B2. Okay. >=20 > --- >=20 >> -12.3: =C2=B3 As discussed below, ICE agents are encouraged to = re-adjust >> jitter buffers=C5=A0=C2=B2 >> Please cite the specific section(s). >=20 > I actually suggest to remove section 12.3. It is about receiving data, = and > the content is covered in section 13. >=20 > I also suggest to change section 12.3 to 12.2.1, as the text is only = about > sending media. >=20 > I also suggest to change section 13 to 12.3. It was always intended to = be > a subsection to section 12. No objection, but that goes beyond the scope of my comment :-) (Normally I discourage lots of reorganization in bis drafts because it = makes them harder to review against the original. But this is already = enough of a re-write that this change would make little incremental = difference.) >=20 > --- >=20 >> - 17, last 3 paragraphs: With the expansion of the security >> considerations, this list does not include all the countermeasures >> mentioned in the later sections. >=20 > I suggest to remove the list, and say: >=20 > "There are several types of attacks possible in an ICE system. = This > section considers these attacks and their countermeasures.=E2=80=9D Okay. >=20 >=20 > --- >=20 >> -17.2, last bullet: Why call out viruses specifically? It seems like >> there are a lot of ways a server might be compromised that do not = involve >> viruses per se. (Same in 17.3). >=20 > My only answer is that this is text from RFC 5245. > I can remove =C2=B3virus=C2=B2, and simply say: >=20 > "An attacker can compromise a STUN server, and cause it to send = responses > with incorrect mapped addresses.=C2=B2 (17.2) >=20 >=20 > =C5=A0and: >=20 > "However, TURN servers are susceptible to DNS attacks for purposes of > turning it into a zombie or rogue server.=E2=80=9D Okay. On reflection, I=E2=80=99m also okay leaving things as is in = deference to 5245. >=20 >=20 > --- >=20 >> -17.4.1: Since the description of the voice hammer attack has been >> removed, can you cite something that does describe it? (Appendix A = still >> refers to section 17 to describe the voice hammer attack.) >=20 > I didn=C2=B9t really find a good citation, but maybe something like: >=20 > "The STUN amplification attack is similar to a voice hammer attack, = where > the attacker causes other agents to direct media traffic towards the > attack target.=E2=80=9D >=20 WFM. Perhaps put =E2=80=9Cvoice hammer=E2=80=9D in quotes? >=20 > I also realised that the following text needs to be removed from = Appendix > A: >=20 > "in particular, the voice hammer attack described in Section 17 is > prevented only for full implementations, not lite.=E2=80=9D Okay. >=20 >=20 > --- >=20 >> -17.4.1, 2nd paragraph: s/they=C2=B9ll/=C2=B3they will=C2=B2 >=20 > I will fix as suggested. >=20 Okay. > --- >=20 >> -22: Did you consider making this section an appendix? >=20 > I don=C2=B9t remember. I have no problem doing that, if you think an = appendix > would be better. On reflection, don=E2=80=99t worry about it. >=20 > Regards, >=20 > Christer >=20 --Apple-Mail=_F27841E6-A94B-45AB-9DAF-14999088C8C0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpU+t4ACgkQgFZKbJXz 1A0VqA//beGi9QCEpI/OvVUU4W5mNv7VJwWZ2lyjqHlMF/Jqa0UwUaVvXugIWTV1 DOu2XRNX5IZAVrN5hW/PeaPiPnh0svekm+UDcyuvwasJPgudbSDW2qbfa//oiUQY GeK6nB33aH44UH5qrVNcSX+WVumHUGUcxW0+DY4Aqoy/PJcVXzoPx1tbAj3fniEr 9OoqHShV0gjjYBtOhX3+gJxmInUne62SDh8MM/0RS4HFdlH/XrlgsbiURCWHdp+i wc0JvfKs4aPYivO9zcctd3dPZWEggB5/2cw1IMmpbMz6G8yId7/3wfjlZvOnW3Kf UEQnDnO8VERgHKJ0rDUzKr1UBmQYs4YBI4i5ugzyLKISu0pfGrWf8HQkpfZy1pGr r15+4prsmo7eCEVjugMhGvVZcgv6noFIJUR/zUg0rjSxiT79A9m2D8rZNmSjFW6J tOw0dvoTmyZpJX5g2DC5SjRf0024rH8m3QioKoZg3TNdw5t36Sxr2rzmMRlzaUrJ bOfAqufldJHjxC+0yENzA7FfL+6bY++4bvKM1Uybl9Ic/kDRK6hNX1aOTWeCHOdm EWJpF/x9Ap6hVV7wTvqpoaRWyfmxrp9C1UQiTLfGF/QdWMd0Qd72YOdht6n/P6Fp V16CGOA7/UXiMbkG/DRjj+zUq1qHhMj6o0iVqRid14zHLLCrfTU= =IRfj -----END PGP SIGNATURE----- --Apple-Mail=_F27841E6-A94B-45AB-9DAF-14999088C8C0-- From nobody Wed Jan 10 03:47:22 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40A41200C1; Wed, 10 Jan 2018 03:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUCQ_c9MwBTe; Wed, 10 Jan 2018 03:47:19 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72DF61200B9; Wed, 10 Jan 2018 03:47:18 -0800 (PST) X-AuditID: c1b4fb3a-716549c0000037f2-0e-5a55fd4427f4 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 72.95.14322.44DF55A5; Wed, 10 Jan 2018 12:47:16 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Wed, 10 Jan 2018 12:45:57 +0100 From: Christer Holmberg To: Ben Campbell CC: "ice@ietf.org" , "draft-ietf-ice-rfc5245bis.all@ietf.org" Thread-Topic: AD Evaluation of draft-ietf-ice-rfc5245bis-15 Thread-Index: AQHTiPxCRxYiw9L/zEu/jMuzPPo1iKNrlLmAgAAmCACAAVgqgA== Date: Wed, 10 Jan 2018 11:45:57 +0000 Message-ID: References: <28E9DD8B-5FEC-468D-B745-30D21E504B9D@nostrum.com> <54D05F30-E2A1-42E4-BAEF-D39D134D0C49@nostrum.com> In-Reply-To: <54D05F30-E2A1-42E4-BAEF-D39D134D0C49@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM2K7oq7L39Aog6t/pSzmd55mtzj+4w+7 xbcLtQ7MHkuW/GTymLXzCUsAUxSXTUpqTmZZapG+XQJXRvffftaCPp+Key/uMzUwTvHqYuTk kBAwkbi+ZhJrFyMXh5DAYUaJ0yuPskE4SxglpjV1s3cxcnCwCVhIdP/TBmkQEVCSeN68lQUk zCxQJjFjNjNIWFjASqJ1znU2iBJrie9/bkLZThJz5y1hAbFZBFQlep/0MoHYvEA1l+f1sEOs Wsoosez5VbAGTgF7iXX3W8CGMgqISXw/tQasgVlAXOLWk/lMEEcLSCzZc54ZwhaVePn4HyuI LSqgJ7HhxG2wkyUEFCWW98tBnKkpsX6XPoRpLdH0TwlioKLElO6H7BDXCEqcnPmEZQKj+Cwk u2YhNM9CaJ6FpHkWkuYFjKyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQKj7eCW31Y7GA8+ dzzEKMDBqMTD++hraJQQa2JZcWXuIUYJDmYlEd53j4FCvCmJlVWpRfnxRaU5qcWHGKU5WJTE eZ3SLKKEBNITS1KzU1MLUotgskwcnFINjCsup+Tn8NSv57/dqlbVqc+bIhsSw7qNafM/xclV V35kex5ZbO2337ul7nO2p66cbahmWP60rOJ1G6d+S9sUf+Seu86xtv3RSYfOcjyrSXu45eGL yAXVPlM1N7ZcnSqR8K1k18UnqXteihi7ORbe+7S0jDcirPgs85xVgk7zOPjduR58PfnBVIml OCPRUIu5qDgRAGSJYJqyAgAA Archived-At: Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-rfc5245bis-15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 11:47:21 -0000 SGksDQoNCj4+IA0KPj4+IFNob3VsZCDCs3NlY3VyZSBzaWduYWxpbmcgdGVjaG5pcXVlc8KyIGRp c3Rpbmd1aXNoIGJldHdlZW4gSEJIIGFuZCBFMkUNCj4+PiB0ZWNobmlxdWVzLCBpbiBsaWdodCBv ZiB0aGUgbGF0ZXIgZGlzY3Vzc2lvbiBhYm91dCBpbnNpZGVyIGF0dGFja3M/DQo+PiANCj4+IExh dGVyIGRvd24gaW4gdGhlIHJlcGx5IEkgc3VnZ2VzdCB0byByZW1vdmUgdGhlIGJ1bGxldCBsaXN0 Lg0KPg0KPk9rYXksIGRvZXMgaXQgbWFrZSBzZW5zZSB0byBkaXNjdXNzIEhCSCB2cyBFMkUgcHJv dGVjdGlvbnMgaW4gdGhlIHNlY3Rpb24NCj5hYm91dCBpbnNpZGVyIGF0dGFja3M/DQoNCkkgZG9u 4oCZdCBrbm93LiBEbyB3ZSBoYXZlIHRoZSByaWdodCBwZW9wbGU/IFdvdWxkIHdlIGdldCBhbnkg dXNlZnVsIGlucHV0Pw0KDQpNeSBzdWdnZXN0aW9uIHdvdWxkIGJlIHRvIHdhaXQgZm9yIHRoZSBT RUNESVItIGFuZCBTRUMgQUQgcmV2aWV3cyBldGMsIGFuZA0Kc2VlIHdoYXQvaWYgdGhleSBzYXku DQoNCj09PT0NCg0KRWRpdG9yaWFsIENvbW1lbnRzIGFuZCBOaXRzOg0KDQo+Pj4gDQo+Pj4gSXMg dGhlcmUgYSByZWFzb24gdGhhdCB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgYW5kIElBTkEN Cj4+PiBjb25zaWRlcmF0aW9ucyBhcmUgbm90IGluIHRoZSBjb252ZW50aW9uYWwgbG9jYXRpb25z IChpLmUuIHRoZSBsYXN0IHR3bw0KPj4+IHNlY3Rpb25zIGJlZm9yZSB0aGUgcmVmZXJlbmNlcyk/ IChJIHNlZSB0aGF0IGlzIGFsc28gdHJ1ZSBpbiA1MjQ1LCBzbw0KPj4+IHRoaXMgaXMgbW9zdGx5 IGN1cmlvc2l0eS4pDQo+PiANCj4+IE5vIHJlYXNvbi4NCj4+IA0KPj4gSSBzdWdnZXN0IHRvIG1v dmUgdGhlIHNlY3Rpb25zLg0KPj4gDQo+DQo+T2theS4gKEnigJltIGFsc28gb2theSBsZWF2aW5n IGl0IGFzIGlzIHVubGVzcyBzb21lb25lIG9iamVjdHMgaW4gSUVURiBMQykuDQoNCkkgYWxyZWFk eSBtb3ZlZCB0aGVtIGluIHRoZSBwdWxsIHJlcXVlc3QgOikNCg0KLS0tDQoNCj4+IA0KPj4gLS0t DQo+PiANCj4+PiDigLkgRGlkbid0IDUyNDUgYWxyZWFkeSBkZXByZWNhdGUgUkZDIDQwOTEgYW5k IDQwOTI/IFRoYXQgaXMsIF90aGlzXw0KPj4+IGRvY3VtZW50IGRvZXMgbm90IGRvIHRoYXQuDQo+ PiANCj4+IEkgc3VnZ2VzdCB0byByZW1vdmUgdGhlIHNlbnRlbmNlLCBhbmQgdGhlIFJGQyByZWZl cmVuY2VzLg0KPg0KPknigJltIG9rYXkgd2l0aCB0aGF0LCBidXQgaXQgbWlnaHQgYmUgaGVscGZ1 bCB0byBtZXJlbHkgYWRqdXN0IHRoZSB3b3JkaW5nDQo+dG8gc2F5IHRoYXQgNTI0NSBkZXByZWNh dGVkIHRoZW0uDQoNCk9rLiBTbywgSSBzdWdnZXN0Og0KDQogICAiQmVjYXVzZSBJQ0UgZXhjaGFu Z2VzIGEgbXVsdGlwbGljaXR5IG9mIElQIGFkZHJlc3NlcyBhbmQgcG9ydHMgZm9yDQplYWNoIG1l ZGlhDQogICAgc3RyZWFtLCBpdCBhbHNvIGFsbG93cyBmb3IgYWRkcmVzcyBzZWxlY3Rpb24gZm9y IG11bHRpaG9tZWQgYW5kIGR1YWwtDQogICAgc3RhY2sgaG9zdHMuIEZvciB0aGlzIHJlYXNvbiBS RkMgNTI0NSBbUkZDNTI0NV0gZGVwcmVjYXRlZCBSRkMgNDA5MQ0KW1JGQzQwOTFdIGFuZA0KICAg IFtSRkM0MDkyXS4iDQoNCg0KLS0tDQoNCg0KPj4+LTIuMSwgNHRoIHBhcmFncmFwaCBmcm9tIGVu ZDogSXQgd291bGQgYmUgaGVscGZ1bCB0byBkZXNjcmliZSB3aGF0DQo+Pj7Cs3ZhbGlkDQo+Pj4g cGFpcsKyIG1lYW5zIGVhcmxpZXIgaW4gdGhlIGRvY3VtZW50Lg0KPj4gDQo+PiBJIGFzc3VtZSB5 b3UgbWVhbiBzZWN0aW9uIDIuMj8NCj4NCj5Tb3JyeSwgeWVzLg0KPg0KPj4gDQo+PiBJIHN1Z2dl c3QgdG8gZm9sbG93aW5nIG1vZGlmaWNhdGlvbjoNCj4+IA0KPj4gICAgIlRoZSBhZ2VudCB3b3Jr cyB0aHJvdWdoIHRoZSBjaGVjayBsaXN0IGJ5IHNlbmRpbmcgYSBTVFVOIHJlcXVlc3QgZm9yDQo+ PiAgICAgdGhlIG5leHQgY2FuZGlkYXRlIHBhaXIgb24gdGhlIGxpc3QgcGVyaW9kaWNhbGx5LiAg VGhlc2UgYXJlIGNhbGxlZA0KPj4gICAgIG9yZGluYXJ5IGNoZWNrcy4gV2hlbiBhIFNUVU4gdHJh bnNhY3Rpb24gc3VjY2VlZHMsIG9uZSBvciBtb3JlDQo+PiAgICAgY2FuZGlkYXRlIHBhaXJzIHdp bGwgYmVjb21lIHNvIGNhbGxlZCB2YWxpZCBwYWlycywgYW5kIHdpbGwgYmUgYWRkZWQNCj4+ICAg ICB0byBhIGNhbmRpZGF0ZSBwYWlyIGxpc3QgY2FsbGVkIHRoZSB2YWxpZCBsaXN0Lg0KPj4gDQo+ PiANCj4+ICAgICBBcyBhbiBvcHRpbWl6YXRpb24sIGFzIHNvb24gYXMgUiBnZXRzIEwncyBjaGVj ayBtZXNzYWdlLCBSIHNjaGVkdWxlcw0KPj4gICAgIGEgY29ubmVjdGl2aXR5IGNoZWNrIG1lc3Nh Z2UgdG8gYmUgc2VudCB0byBMIG9uIHRoZSBzYW1lIGNhbmRpZGF0ZQ0KPj4gICAgIHBhaXIuIFRo aXMgaXMgY2FsbGVkIGEgdHJpZ2dlcmVkIGNoZWNrLCBhbmQgYWNjZWxlcmF0ZXMgdGhlIHByb2Nl c3MNCj4+ICAgICBvZiBmaW5kaW5nIHZhbGlkIHBhaXJzLuKAnQ0KPg0KPldGTQ0KPg0KPj4gDQo+ PiANCj4+IEkgd291bGQgbm90IGxpa2UgdG8gYWRkIG1vcmUgZGV0YWlscyB0byBzZWN0aW9uIDIg KEkgdGhpbmsgaXTCuXMgdG9vDQo+PiBkZXRhaWxlZCBhbHJlYWR5KSwgYnV0IEkgc3VnZ2VzdCB0 byBhZGQNCj4+IHRoZSBmb2xsb3dpbmcgdG8gc2VjdGlvbiA0Og0KPj4gDQo+PiAgICAiVmFsaWQg UGFpcjogQSBjYW5kaWRhdGUgcGFpciB3aG9zZSBsb2NhbCBjYW5kaWRhdGUgZXF1YWxzIHRoZSBt YXBwZWQNCj4+IGFkZHJlc3Mgb2YgdGhlIGNvbm5lY3Rpdml0eSBjaGVjayByZXNwb25zZSwNCj4+ ICAgICBhbmQgd2hvc2UgcmVtb3RlIGNhbmRpZGF0ZSBlcXVhbHMgdGhlIGRlc3RpbmF0aW9uIGFk ZHJlc3MgdG8gd2hpY2gNCj4+IHRoZSBjb25uZWN0aXZpdHkgY2hlY2sgcmVxdWVzdCB3YXMgc2Vu dC7igJ0NCj4NCj5BbHNvIFdGTS4NCj4NCj4+IA0KPj4gDQo+PiBSZWxhdGVkIHRvIHRoaXMsIEkg bm90ZSB0aGF0IHRoZSBkb2N1bWVudCB1c2VzIGJvdGggwrN2YWxpZCBwYWlywrIgYW5kDQo+PiDC s3ZhbGlkIGNhbmRpZGF0ZSBwYWlywrIgdGVybWlub2xvZ3kuIFBlcmhhcHMgaXTCuXMgZW5vdWdo IHRvIHNheSDCs3ZhbGlkDQo+PiBwYWlywrIgZXZlcnl3aGVyZS4NCj4+IA0KPj4gUmVsYXRlZCB0 byB0aGlzLCB0aGVyZSBpcyBhIGJ1ZyBpbiBzZWN0aW9uIDIuMy4gVGhlIHRleHQgc2hhbGwgc2F5 Og0KPj4gDQo+PiAgICAiRm9yIGVhY2ggY29tcG9uZW50IG9mIGEgZGF0YSBzdHJlYW0sIHRoZSBj b250cm9sbGluZyBhZ2VudCBub21pbmF0ZXMNCj4+IGEgdmFsaWQgcGFpciBmcm9tDQo+PiAgICAg dGhlIHZhbGlkIGxpc3QgdG8gYmUgdXNlZCBmb3IgZGF0YS7igJ0NCj4NCj5J4oCZbSBva2F5IGVp dGhlciB3YXkuIChXaGlsZSBJIHVzdWFsbHkgcHJlZmVyIGNvbnNpc3RlbmN5LCBJIGltYWdpbmUg dGhhdA0KPnBlb3BsZSBjYW4gZmlndXJlIHRoaXMgb25lIG91dC4pDQoNClRoaXMgaXMgb25lIG9m IHRoZSB0aGluZ3MgSSBhbHdheXMgY2hlY2sgd2hlbiBJIGRvIEdlbkFydCByZXZpZXdzIDopDQoN CkkgaGFkIGEgbG9vaywgYW5kIHRoZXJlIHdlcmVu4oCZdCB0b28gbWFueSBpbnN0YW5jZXMgb2Yg 4oCcdmFsaWQgY2FuZGlkYXRlDQpwYWly4oCdLCBzbyBJIGNoYW5nZWQgdGhlbSB0byDigJx2YWxp ZCBwYWly4oCdIGluIG9yZGVyIHRvIGFsaWduLg0KDQpJIGltcGxlbWVudGVkIHRoZSBjaGFuZ2Vz IGluIHRoZSBQUi4NCg0KDQotLS0NCg0KPj4gDQo+Pj4gLTQ6IFRoZXJlIGFyZSBhdCBsZWFzdCBh IGZldyB1c2VzIG9mIGxvd2VyIGNhc2UgwrNtdXN0wrIgYW5kIMKzc2hvdWxkwrINCj4+PnRoYXQN Cj4+PiBkbyBub3QgYXBwZWFyIHRvIGhhdmUgYmVlbiBpbnRlbmRlZCBhcyBrZXl3b3Jkcy4gSWYg dGhhdCBpcyB0aGUgaW50ZW50LA0KPj4+IHBsZWFzZSB1cGRhdGUgdGhpcyB0byB1c2UgdGhlIGJv aWxlcnBsYXRlIGZyb20gODE3NC4gIChUaGUgMjExOQ0KPj4+IGJvaWxlcnBsYXRlIGlzIGFtYmln dW91cyBvbiB3aGV0aGVyIGxvd2VyIGNhc2UgaW5zdGFuY2VzIGNvdW50IGFzDQo+Pj4ga2V5d29y ZHMuKQ0KPj4gDQo+PiANCj4+IEkgc3VnZ2VzdCB3ZSBrZWVwIHRoZSAyMTE5IGJvaWxlcnBsYXRl LCBidXQgSSB3aWxsIGdvIHRocm91Z2ggdGhlIGxvd2VyDQo+PiBjYXNlIGluc3RhbmNlcyBhbmQg c2VlIHdoZXRoZXIgdGhleSBzaG91bGQgYmUgY2FwaXRhbGl6ZWQuDQo+DQo+T2theSwgYWx0aG91 Z2ggaWYgeW91IGtlZXAgMjExOSwgaXQgbWlnaHQgYmUgYmV0dGVyIHRvIGNoYW5nZSBhbnkgdGhh dA0KPnNob3VsZCByZW1haW4gbm9uLWNhcGl0YWxpemVkIHRvIG5vbi1jb2xsaWRpbmcgdGVybXMu DQoNCkkgaGFkIGEgbG9vay4gSW4gbW9zdCBjYXNlcyBJIGNvdWxkIGNoYW5nZSB0byBhIG5vbi1j b2xsaWRpbmcgdGVybXMsIGFuZA0KaW4gMS0yIGNhc2VzIEkgY2hhbmdlZCB0byB1cHBlciBjYXNl Lg0KDQpJIGltcGxlbWVudGVkIHRoZSBjaGFuZ2VzIGluIHRoZSBQUi4NCg0K4oCUDQoNCj4+Pi0x Mi4zOiDCsyBBcyBkaXNjdXNzZWQgYmVsb3csIElDRSBhZ2VudHMgYXJlIGVuY291cmFnZWQgdG8g cmUtYWRqdXN0DQo+Pj4gaml0dGVyIGJ1ZmZlcnPFoMKyDQo+Pj4gUGxlYXNlIGNpdGUgdGhlIHNw ZWNpZmljIHNlY3Rpb24ocykuDQo+PiANCj4+IEkgYWN0dWFsbHkgc3VnZ2VzdCB0byByZW1vdmUg c2VjdGlvbiAxMi4zLiBJdCBpcyBhYm91dCByZWNlaXZpbmcgZGF0YSwNCj4+YW5kDQo+PiB0aGUg Y29udGVudCBpcyBjb3ZlcmVkIGluIHNlY3Rpb24gMTMuDQo+PiANCj4+IEkgYWxzbyBzdWdnZXN0 IHRvIGNoYW5nZSBzZWN0aW9uIDEyLjMgdG8gMTIuMi4xLCBhcyB0aGUgdGV4dCBpcyBvbmx5DQo+ PmFib3V0DQo+PiBzZW5kaW5nIG1lZGlhLg0KPj4gDQo+PiBJIGFsc28gc3VnZ2VzdCB0byBjaGFu Z2Ugc2VjdGlvbiAxMyB0byAxMi4zLiBJdCB3YXMgYWx3YXlzIGludGVuZGVkIHRvDQo+PmJlDQo+ PiBhIHN1YnNlY3Rpb24gdG8gc2VjdGlvbiAxMi4NCj4NCj5ObyBvYmplY3Rpb24sIGJ1dCB0aGF0 IGdvZXMgYmV5b25kIHRoZSBzY29wZSBvZiBteSBjb21tZW50IDotKQ0KPg0KPihOb3JtYWxseSBJ IGRpc2NvdXJhZ2UgbG90cyBvZiByZW9yZ2FuaXphdGlvbiBpbiBiaXMgZHJhZnRzIGJlY2F1c2Ug aXQNCj5tYWtlcyB0aGVtIGhhcmRlciB0byByZXZpZXcgYWdhaW5zdCB0aGUgb3JpZ2luYWwuIEJ1 dCB0aGlzIGlzIGFscmVhZHkNCj5lbm91Z2ggb2YgYSByZS13cml0ZSB0aGF0IHRoaXMgY2hhbmdl IHdvdWxkIG1ha2UgbGl0dGxlIGluY3JlbWVudGFsDQo+ZGlmZmVyZW5jZS4pDQoNCkFsc28gbm90 ZSB0aGF0IOKAnFJlY2VpdmluZyBtZWRpYeKAnSAoc2VjdGlvbiAxMyBpbiBiaXMpIHdhcyBhIHN1 YnNlY3Rpb24gaW4NClJGQyA1MjQ1LCBzbyB0aGUgMTMtPjEyLjMgY2hhbmdlIHdpbGwgYWN0dWFs bHkgYWxpZ24gdGhlIGJpcyB3aXRoIHRoZSBSRkMNCjopDQoNCuKAlA0KDQo+PiANCj4+PiAtMTcu MiwgbGFzdCBidWxsZXQ6IFdoeSBjYWxsIG91dCB2aXJ1c2VzIHNwZWNpZmljYWxseT8gSXQgc2Vl bXMgbGlrZQ0KPj4+IHRoZXJlIGFyZSBhIGxvdCBvZiB3YXlzIGEgc2VydmVyIG1pZ2h0IGJlIGNv bXByb21pc2VkIHRoYXQgZG8gbm90DQo+Pj5pbnZvbHZlDQo+Pj4gdmlydXNlcyBwZXIgc2UuIChT YW1lIGluIDE3LjMpLg0KPj4gDQo+PiBNeSBvbmx5IGFuc3dlciBpcyB0aGF0IHRoaXMgaXMgdGV4 dCBmcm9tIFJGQyA1MjQ1Lg0KPj4gSSBjYW4gcmVtb3ZlIMKzdmlydXPCsiwgYW5kIHNpbXBseSBz YXk6DQo+PiANCj4+ICJBbiBhdHRhY2tlciBjYW4gY29tcHJvbWlzZSBhIFNUVU4gc2VydmVyLCBh bmQgY2F1c2UgaXQgdG8gc2VuZA0KPj5yZXNwb25zZXMNCj4+IHdpdGggaW5jb3JyZWN0IG1hcHBl ZCBhZGRyZXNzZXMuwrIgKDE3LjIpDQo+PiANCj4+IA0KPj4gxaBhbmQ6DQo+PiANCj4+ICJIb3dl dmVyLCBUVVJOIHNlcnZlcnMgYXJlIHN1c2NlcHRpYmxlIHRvIEROUyBhdHRhY2tzIGZvciBwdXJw b3NlcyBvZg0KPj4gdHVybmluZyBpdCBpbnRvIGEgem9tYmllIG9yIHJvZ3VlIHNlcnZlci7igJ0N Cj4NCj5Pa2F5LiBPbiByZWZsZWN0aW9uLCAgSeKAmW0gYWxzbyBva2F5IGxlYXZpbmcgdGhpbmdz IGFzIGlzIGluIGRlZmVyZW5jZSB0bw0KPjUyNDUuDQoNCkkgYWxyZWFkeSByZW1vdmVkIGl0IGlu IHRoZSBQUiwgc28gaWYgeW91IGFyZSBvayB3aXRoIHRoYXQgSSB3b27igJl0IHB1dCBpdA0KYmFj ayA6KQ0KDQotLS0NCg0KPj4gDQo+Pj4gLTE3LjQuMTogU2luY2UgdGhlIGRlc2NyaXB0aW9uIG9m IHRoZSB2b2ljZSBoYW1tZXIgYXR0YWNrIGhhcyBiZWVuDQo+Pj4gcmVtb3ZlZCwgY2FuIHlvdSBj aXRlIHNvbWV0aGluZyB0aGF0IGRvZXMgZGVzY3JpYmUgaXQ/IChBcHBlbmRpeCBBDQo+Pj5zdGls bA0KPj4+IHJlZmVycyB0byBzZWN0aW9uIDE3IHRvIGRlc2NyaWJlIHRoZSB2b2ljZSBoYW1tZXIg YXR0YWNrLikNCj4+IA0KPj4gSSBkaWRuwrl0IHJlYWxseSBmaW5kIGEgZ29vZCBjaXRhdGlvbiwg YnV0IG1heWJlIHNvbWV0aGluZyBsaWtlOg0KPj4gDQo+PiAiVGhlIFNUVU4gYW1wbGlmaWNhdGlv biBhdHRhY2sgaXMgc2ltaWxhciB0byBhIHZvaWNlIGhhbW1lciBhdHRhY2ssDQo+PndoZXJlDQo+ PiB0aGUgYXR0YWNrZXIgY2F1c2VzIG90aGVyIGFnZW50cyB0byBkaXJlY3QgbWVkaWEgdHJhZmZp YyB0b3dhcmRzIHRoZQ0KPj4gYXR0YWNrIHRhcmdldC7igJ0NCj4+IA0KPg0KPldGTS4gUGVyaGFw cyBwdXQg4oCcdm9pY2UgaGFtbWVy4oCdIGluIHF1b3Rlcz8NCg0KSSB3aWxsIGZpeCB0aGF0Lg0K DQotLS0NCg0KPj4gDQo+Pj4gLTIyOiBEaWQgeW91IGNvbnNpZGVyIG1ha2luZyB0aGlzIHNlY3Rp b24gYW4gYXBwZW5kaXg/DQo+PiANCj4+IEkgZG9uwrl0IHJlbWVtYmVyLiBJIGhhdmUgbm8gcHJv YmxlbSBkb2luZyB0aGF0LCBpZiB5b3UgdGhpbmsgYW4gYXBwZW5kaXgNCj4+IHdvdWxkIGJlIGJl dHRlci4NCj4NCj5PbiByZWZsZWN0aW9uLCBkb27igJl0IHdvcnJ5IGFib3V0IGl0Lg0KDQpPaywg SeKAmWxsIGtlZXAgaXQuDQoNClVwZGF0ZWQgUFI6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9pY2Ut d2cvcmZjNTI0NWJpcy9wdWxsLzU1DQoNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Wed Jan 10 08:10:50 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE5112D951; Wed, 10 Jan 2018 08:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qF9hQ_ucraDT; Wed, 10 Jan 2018 08:10:44 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39C2112D948; Wed, 10 Jan 2018 08:10:41 -0800 (PST) X-AuditID: c1b4fb3a-34dff700000037f2-c2-5a563aff79c0 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C8.EA.14322.FFA365A5; Wed, 10 Jan 2018 17:10:39 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Wed, 10 Jan 2018 17:10:38 +0100 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Christer Holmberg CC: Ben Campbell , "ice@ietf.org" , "draft-ietf-ice-rfc5245bis.all@ietf.org" Thread-Topic: AD Evaluation of draft-ietf-ice-rfc5245bis-15 Thread-Index: AQHTiPxCStiYLvaae0uXgE3/7vtvXKNrcDuAgAHIJAA= Date: Wed, 10 Jan 2018 16:10:38 +0000 Message-ID: <4A671047-4C38-475C-A20F-D68C7E4A083A@ericsson.com> References: <28E9DD8B-5FEC-468D-B745-30D21E504B9D@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: <2F8B2C1DC165B146830E7651A5D50E09@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM2K7tO5/q7AogyWLlSzmd55mtzj+4w+7 xbcLtQ7MHkuW/GTymLXzCUsAUxSXTUpqTmZZapG+XQJXxsSv39kKbvFVzOu4xNTAuIKvi5GT Q0LARKKtt4W9i5GLQ0jgMKNEw5H3bBDOEkaJG1dOMIJUsQnYSjxp3ccKYosImElc/9zLBFLE LDCDUWLO02Y2kISwgJVE65zrbBBF1hLf/9yEsq0kZjx8wg5iswioSuzZ/owJxOYVsJd48n8/ M4gtJFAg8X7uWqBlHBycAjYSu5YWgIQZBcQkvp9aA1bOLCAucevJfCaIqwUkluw5zwxhi0q8 fPyPFcJWklix/RLYGGYBTYn1u/QhWq0l5u9qY4ewFSWmdD9kh7hAUOLkzCcsExjFZiHZMAuh exaS7llIumch6V7AyLqKUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzC6Dm75bbWD8eBzx0OM AhyMSjy891TCooRYE8uKK3MPMUpwMCuJ8DqZA4V4UxIrq1KL8uOLSnNSiw8xSnOwKInzOqVZ RAkJpCeWpGanphakFsFkmTg4pRoYNRaGC9sqNaR89xN2+HR9/xTBt4vYhPjs9Hayr97Pk7X4 wezrybtXCn+aWejpect9zceDk5Rkft6R+93zq+bEpkq90qZ+nrLWA36WTzdbThE/fjXrz/Hs ao+oZY55N7d/ff4zMdtq5rvOrQn3H5bPfsf2j/Oz3ZSTrYUOb42XfS9T2bGW4x7ncSWW4oxE Qy3mouJEAGBnTf6qAgAA Archived-At: Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-rfc5245bis-15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 16:10:48 -0000 DQo+IE9uIDkgSmFuIDIwMTgsIGF0IDE0LjU4LCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gDQo+IEhpIEJlbiwNCj4gDQo+IFRoYW5r IFlvdSBmb3IgdGhlIHJldmlldyEgUGxlYXNlIHNlZSBpbmxpbmUuDQo+IA0KPj4gU3Vic3RhbnRp dmUgQ29tbWVudHM6DQo+PiANCj4+IC0gMi4xLCAybmQgdG8gbGFzdDogRG9lcyBJQ0UgcmVhbGx5 IHByaW9yaXRpemUgYSBwYXRoIHdpdGggZmV3ZXIgTkFUcw0KPj4gb3ZlciBhIHBhdGggd2l0aCBt b3JlIE5BVHMsIG9yIGlzIGl0IG1vcmUgYSBtYXR0ZXIgb2Ygc2VsZWN0aW5nIGEgcGF0aA0KPj4g d2l0aCBubyBOQVRzIG92ZXIgYSBwYXRoIHdpdGggwrNzb21lwrIgTkFUcz8gKElmIHRoZSBmb3Jt ZXIsIGhvdyBkb2VzIGl0DQo+PiBmaWd1cmUgb3V0IGhvdyBtYW55IE5BVHMgYXJlIGJldHdlZW4g YW4gYWdlbnQgYW5kIGl0wrlzIHNlcnZlcnMgYW5kIHBlZXJzPw0KPj4gSXMgdGhpcyBqdXN0IGEg bWF0dGVyIG9mIHRpbWluZz8pDQo+IA0KPiBJQ0UgYWdlbnRzIGNhbsK5dCBkZXRlcm1pbmUgaG93 IG1hbnkgTkFUcyB0aGVyZSBhcmUuDQo+IA0KPiBJIHN1Z2dlc3QgdG8gc2F5Og0KPiANCj4gICAi SW4gZ2VuZXJhbCwgdGhlIHByaW9yaXR5IGFsZ29yaXRobSBpcyBkZXNpZ25lZCBzbyB0aGF0IGNh bmRpZGF0ZXMgb2YNCj4gICAgc2ltaWxhciB0eXBlIGdldCBzaW1pbGFyIHByaW9yaXRpZXMgYW5k IHNvIHRoYXQgbW9yZSBkaXJlY3Qgcm91dGVzDQo+ICAgICh0aGF0IGlzLCByb3V0ZXMgd2l0aG91 dCBkYXRhIHJlbGF5cyBvciBOQVRzKSBhcmUgcHJlZmVycmVkIG92ZXINCj4gaW5kaXJlY3Qgcm91 dGVzDQo+ICAgIChyb3V0ZXMgd2l0aCBkYXRhIHJlbGF5cyBvciBOQVRzKS4iDQoNCklDRSBtYWtl cyBhIGRpZmZlcmVuY2UgYmV0d2VlbiBubyBOQVRzLCBvbmUgYWdlbnQgYmVoaW5kIGEgTkFULCBh bmQgYm90aCBhZ2VudHMgKG9yIG1vcmUgc3BlY2lmaWNhbGx5IHRoZWlyIGludGVyZmFjZXMgYmVp bmcgY2hlY2tlZCkgYmVoaW5kIE5BVHMuIEFuZCBhIHBhdGggd2l0aCBvbmx5IG9uZSBhZ2VudCBi ZWhpbmQgYSBOQVQgd291bGQgYmUgImZld2VyIE5BVHMiIHRoYW4gYm90aCBiZWhpbmQgTkFUcy4g QWRtaXR0ZWRseSB0aGVyZSBjb3VsZCBiZSBhIGNhc2NhZGUgb2YgMyBOQVRzIGluIGZyb250IG9m IG9uZSBvZiB0aGUgYWdlbnRzIGFuZCB0aGV5IHdvdWxkIGJlICJjb3VudGVkIiBhcyBhIHNpbmds ZSBOQVQuDQoNClRoYXQgc2FpZCwgSSB0aGluayB0aGUgdGV4dCB5b3Ugc3VnZ2VzdGVkIGlzIGFs c28gY29ycmVjdC4gQW5kIHByb2JhYmx5IGxlc3MgY29uZnVzaW5nIHRvby4NCg0KDQpDaGVlcnMs DQpBcmk= From nobody Wed Jan 10 08:22:34 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B499412D948; Wed, 10 Jan 2018 08:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMM6Ay_BFk6D; Wed, 10 Jan 2018 08:22:29 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 551E112895E; Wed, 10 Jan 2018 08:22:29 -0800 (PST) Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0AGMOnF030165 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 Jan 2018 10:22:25 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105] From: Ben Campbell Message-Id: <583094F9-BFD0-4025-AA16-9E22A503E609@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_CC7C73DD-57AC-4C01-9133-C44B81483617"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 10 Jan 2018 10:22:23 -0600 In-Reply-To: Cc: "ice@ietf.org" , "draft-ietf-ice-rfc5245bis.all@ietf.org" To: Christer Holmberg References: <28E9DD8B-5FEC-468D-B745-30D21E504B9D@nostrum.com> <54D05F30-E2A1-42E4-BAEF-D39D134D0C49@nostrum.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-rfc5245bis-15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 16:22:32 -0000 --Apple-Mail=_CC7C73DD-57AC-4C01-9133-C44B81483617 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 10, 2018, at 5:45 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>=20 >>>> Should =C2=B3secure signaling techniques=C2=B2 distinguish between = HBH and E2E >>>> techniques, in light of the later discussion about insider attacks? >>>=20 >>> Later down in the reply I suggest to remove the bullet list. >>=20 >> Okay, does it make sense to discuss HBH vs E2E protections in the = section >> about insider attacks? >=20 > I don=E2=80=99t know. Do we have the right people? Would we get any = useful input? I wasn=E2=80=99t asking for a detailed discussion=E2=80=94maybe just a 1 = sentence acknowledgement that things like SIPS do not by themselves = prevent an insider or a compromised proxy/b2bua from eavesdropping on = and/or tampering with the candidate exchange. >=20 > My suggestion would be to wait for the SECDIR- and SEC AD reviews etc, = and > see what/if they say. I=E2=80=99m okay with that. [The rest of your responses look fine.] Thanks! Ben. >=20 > =3D=3D=3D=3D >=20 > Editorial Comments and Nits: >=20 >>>>=20 >>>> Is there a reason that the Security Considerations and IANA >>>> considerations are not in the conventional locations (i.e. the last = two >>>> sections before the references)? (I see that is also true in 5245, = so >>>> this is mostly curiosity.) >>>=20 >>> No reason. >>>=20 >>> I suggest to move the sections. >>>=20 >>=20 >> Okay. (I=E2=80=99m also okay leaving it as is unless someone objects = in IETF LC). >=20 > I already moved them in the pull request :) >=20 > --- >=20 >>>=20 >>> --- >>>=20 >>>> =E2=80=B9 Didn't 5245 already deprecate RFC 4091 and 4092? That is, = _this_ >>>> document does not do that. >>>=20 >>> I suggest to remove the sentence, and the RFC references. >>=20 >> I=E2=80=99m okay with that, but it might be helpful to merely adjust = the wording >> to say that 5245 deprecated them. >=20 > Ok. So, I suggest: >=20 > "Because ICE exchanges a multiplicity of IP addresses and ports for > each media > stream, it also allows for address selection for multihomed and = dual- > stack hosts. For this reason RFC 5245 [RFC5245] deprecated RFC 4091 > [RFC4091] and > [RFC4092]." >=20 >=20 > --- >=20 >=20 >>>> -2.1, 4th paragraph from end: It would be helpful to describe what >>>> =C2=B3valid >>>> pair=C2=B2 means earlier in the document. >>>=20 >>> I assume you mean section 2.2? >>=20 >> Sorry, yes. >>=20 >>>=20 >>> I suggest to following modification: >>>=20 >>> "The agent works through the check list by sending a STUN request = for >>> the next candidate pair on the list periodically. These are = called >>> ordinary checks. When a STUN transaction succeeds, one or more >>> candidate pairs will become so called valid pairs, and will be = added >>> to a candidate pair list called the valid list. >>>=20 >>>=20 >>> As an optimization, as soon as R gets L's check message, R = schedules >>> a connectivity check message to be sent to L on the same = candidate >>> pair. This is called a triggered check, and accelerates the = process >>> of finding valid pairs.=E2=80=9D >>=20 >> WFM >>=20 >>>=20 >>>=20 >>> I would not like to add more details to section 2 (I think it=C2=B9s = too >>> detailed already), but I suggest to add >>> the following to section 4: >>>=20 >>> "Valid Pair: A candidate pair whose local candidate equals the = mapped >>> address of the connectivity check response, >>> and whose remote candidate equals the destination address to = which >>> the connectivity check request was sent.=E2=80=9D >>=20 >> Also WFM. >>=20 >>>=20 >>>=20 >>> Related to this, I note that the document uses both =C2=B3valid = pair=C2=B2 and >>> =C2=B3valid candidate pair=C2=B2 terminology. Perhaps it=C2=B9s = enough to say =C2=B3valid >>> pair=C2=B2 everywhere. >>>=20 >>> Related to this, there is a bug in section 2.3. The text shall say: >>>=20 >>> "For each component of a data stream, the controlling agent = nominates >>> a valid pair from >>> the valid list to be used for data.=E2=80=9D >>=20 >> I=E2=80=99m okay either way. (While I usually prefer consistency, I = imagine that >> people can figure this one out.) >=20 > This is one of the things I always check when I do GenArt reviews :) >=20 > I had a look, and there weren=E2=80=99t too many instances of =E2=80=9Cv= alid candidate > pair=E2=80=9D, so I changed them to =E2=80=9Cvalid pair=E2=80=9D in = order to align. >=20 > I implemented the changes in the PR. >=20 >=20 > --- >=20 >>>=20 >>>> -4: There are at least a few uses of lower case =C2=B3must=C2=B2 = and =C2=B3should=C2=B2 >>>> that >>>> do not appear to have been intended as keywords. If that is the = intent, >>>> please update this to use the boilerplate from 8174. (The 2119 >>>> boilerplate is ambiguous on whether lower case instances count as >>>> keywords.) >>>=20 >>>=20 >>> I suggest we keep the 2119 boilerplate, but I will go through the = lower >>> case instances and see whether they should be capitalized. >>=20 >> Okay, although if you keep 2119, it might be better to change any = that >> should remain non-capitalized to non-colliding terms. >=20 > I had a look. In most cases I could change to a non-colliding terms, = and > in 1-2 cases I changed to upper case. >=20 > I implemented the changes in the PR. >=20 > =E2=80=94 >=20 >>>> -12.3: =C2=B3 As discussed below, ICE agents are encouraged to = re-adjust >>>> jitter buffers=C5=A0=C2=B2 >>>> Please cite the specific section(s). >>>=20 >>> I actually suggest to remove section 12.3. It is about receiving = data, >>> and >>> the content is covered in section 13. >>>=20 >>> I also suggest to change section 12.3 to 12.2.1, as the text is only >>> about >>> sending media. >>>=20 >>> I also suggest to change section 13 to 12.3. It was always intended = to >>> be >>> a subsection to section 12. >>=20 >> No objection, but that goes beyond the scope of my comment :-) >>=20 >> (Normally I discourage lots of reorganization in bis drafts because = it >> makes them harder to review against the original. But this is already >> enough of a re-write that this change would make little incremental >> difference.) >=20 > Also note that =E2=80=9CReceiving media=E2=80=9D (section 13 in bis) = was a subsection in > RFC 5245, so the 13->12.3 change will actually align the bis with the = RFC > :) >=20 > =E2=80=94 >=20 >>>=20 >>>> -17.2, last bullet: Why call out viruses specifically? It seems = like >>>> there are a lot of ways a server might be compromised that do not >>>> involve >>>> viruses per se. (Same in 17.3). >>>=20 >>> My only answer is that this is text from RFC 5245. >>> I can remove =C2=B3virus=C2=B2, and simply say: >>>=20 >>> "An attacker can compromise a STUN server, and cause it to send >>> responses >>> with incorrect mapped addresses.=C2=B2 (17.2) >>>=20 >>>=20 >>> =C5=A0and: >>>=20 >>> "However, TURN servers are susceptible to DNS attacks for purposes = of >>> turning it into a zombie or rogue server.=E2=80=9D >>=20 >> Okay. On reflection, I=E2=80=99m also okay leaving things as is in = deference to >> 5245. >=20 > I already removed it in the PR, so if you are ok with that I won=E2=80=99= t put it > back :) >=20 > --- >=20 >>>=20 >>>> -17.4.1: Since the description of the voice hammer attack has been >>>> removed, can you cite something that does describe it? (Appendix A >>>> still >>>> refers to section 17 to describe the voice hammer attack.) >>>=20 >>> I didn=C2=B9t really find a good citation, but maybe something like: >>>=20 >>> "The STUN amplification attack is similar to a voice hammer attack, >>> where >>> the attacker causes other agents to direct media traffic towards the >>> attack target.=E2=80=9D >>>=20 >>=20 >> WFM. Perhaps put =E2=80=9Cvoice hammer=E2=80=9D in quotes? >=20 > I will fix that. >=20 > --- >=20 >>>=20 >>>> -22: Did you consider making this section an appendix? >>>=20 >>> I don=C2=B9t remember. I have no problem doing that, if you think an = appendix >>> would be better. >>=20 >> On reflection, don=E2=80=99t worry about it. >=20 > Ok, I=E2=80=99ll keep it. >=20 > Updated PR: >=20 > https://github.com/ice-wg/rfc5245bis/pull/55 >=20 >=20 > Regards, >=20 > Christer >=20 --Apple-Mail=_CC7C73DD-57AC-4C01-9133-C44B81483617 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpWPb8ACgkQgFZKbJXz 1A3a+xAAzDoanKbmQ16AaTmzujYnJDl4vX7pIaKOXMwQLUmh/hSfSBxD55rI1oKj THOLgS8b2KCokCNj+c/9NoF5Yr2ej/BAgsWgEEiRN9ZgWoY0jVH2IQJ7pQBBPRS8 bFuXHa38tqtbYoP16W8tmQWy353dRjEliyQn3aX+PjQykZ4zRGH/bvpJcjbeXhie UWXMNeVTV/4U/R4jnnoKQDSIjH+n0BvnWyTfceFQaq34NVmVVi0bG5fxw8m6W0xg xo1yIoP9d6yfbLENIu/3b+RMdu9VDrqy19BKADi4sX/fwaGnnJPOa2O8OQCllyQm kI6rqrf2yQ52iZ79I3iiqSpHPRts4p1HR7M3e67Q7uqnb5H3dXGP/rKqLPiw0SSj fsX2u/5q7O1F2yKJzYHLAFW0TrLJdH/2Vu3eRF1jkf4ZlV91spcowdLjdEd6/sQc 9jazyi4B1f5CdMtdENe4jA/QJnOlKRaNTe3C/Q7PeascXDDUWTMFrNHem8RmDH2W gYsCRSyTcsf+n7Ogejr+iG+dRlhxw4Hu1VkaF13lyBqgzeWEwpQLVX6fAyX4AHY/ S3hiyQJfmbMMWZKUBf1ArS1sSpnzu3IKY50LVLukDCenPgOKwovrhxk8TAlY79Ox qUFGzxGlZViGx45eJoYMcgL/PwXYGEd3xRGE6zJUgw9rvHvBomU= =3RAX -----END PGP SIGNATURE----- --Apple-Mail=_CC7C73DD-57AC-4C01-9133-C44B81483617-- From nobody Wed Jan 10 08:36:32 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F7112DA02; Wed, 10 Jan 2018 08:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXo5PIK5JucM; Wed, 10 Jan 2018 08:36:27 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28A312DA03; Wed, 10 Jan 2018 08:36:12 -0800 (PST) Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0AGa85t031681 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 Jan 2018 10:36:09 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105] From: Ben Campbell Message-Id: <58865C4E-310F-457C-B2DD-5FDB12C9C435@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_3F0FB03E-B4C3-4D7A-ADE5-C6822E08CE30"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 10 Jan 2018 10:36:07 -0600 In-Reply-To: <583094F9-BFD0-4025-AA16-9E22A503E609@nostrum.com> Cc: "ice@ietf.org" , "draft-ietf-ice-rfc5245bis.all@ietf.org" To: Christer Holmberg References: <28E9DD8B-5FEC-468D-B745-30D21E504B9D@nostrum.com> <54D05F30-E2A1-42E4-BAEF-D39D134D0C49@nostrum.com> <583094F9-BFD0-4025-AA16-9E22A503E609@nostrum.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-rfc5245bis-15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 16:36:31 -0000 --Apple-Mail=_3F0FB03E-B4C3-4D7A-ADE5-C6822E08CE30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I meant to mention that the github DIFF looks good to me as far as I can = tell. I agree with Ari=E2=80=99s comments. However, moving sections = around makes the diff hard to follow for those sections, so I reserve = the right to find something I missed when it is submitted as a draft :-) Since there is at least one normative change (SHOULD to MUST), please = call that out in a separate message to the wg. That doesn=E2=80=99t = need to block IETF LC; if anyone objects they can do it as part of the = LC. Thanks! Ben. > On Jan 10, 2018, at 10:22 AM, Ben Campbell wrote: >=20 >=20 >=20 >> On Jan 10, 2018, at 5:45 AM, Christer Holmberg = wrote: >>=20 >> Hi, >>=20 >>>>=20 >>>>> Should =C2=B3secure signaling techniques=C2=B2 distinguish between = HBH and E2E >>>>> techniques, in light of the later discussion about insider = attacks? >>>>=20 >>>> Later down in the reply I suggest to remove the bullet list. >>>=20 >>> Okay, does it make sense to discuss HBH vs E2E protections in the = section >>> about insider attacks? >>=20 >> I don=E2=80=99t know. Do we have the right people? Would we get any = useful input? >=20 > I wasn=E2=80=99t asking for a detailed discussion=E2=80=94maybe just a = 1 sentence acknowledgement that things like SIPS do not by themselves = prevent an insider or a compromised proxy/b2bua from eavesdropping on = and/or tampering with the candidate exchange. >=20 >>=20 >> My suggestion would be to wait for the SECDIR- and SEC AD reviews = etc, and >> see what/if they say. >=20 > I=E2=80=99m okay with that. >=20 > [The rest of your responses look fine.] >=20 > Thanks! >=20 > Ben. >=20 >>=20 >> =3D=3D=3D=3D >>=20 >> Editorial Comments and Nits: >>=20 >>>>>=20 >>>>> Is there a reason that the Security Considerations and IANA >>>>> considerations are not in the conventional locations (i.e. the = last two >>>>> sections before the references)? (I see that is also true in 5245, = so >>>>> this is mostly curiosity.) >>>>=20 >>>> No reason. >>>>=20 >>>> I suggest to move the sections. >>>>=20 >>>=20 >>> Okay. (I=E2=80=99m also okay leaving it as is unless someone objects = in IETF LC). >>=20 >> I already moved them in the pull request :) >>=20 >> --- >>=20 >>>>=20 >>>> --- >>>>=20 >>>>> =E2=80=B9 Didn't 5245 already deprecate RFC 4091 and 4092? That = is, _this_ >>>>> document does not do that. >>>>=20 >>>> I suggest to remove the sentence, and the RFC references. >>>=20 >>> I=E2=80=99m okay with that, but it might be helpful to merely adjust = the wording >>> to say that 5245 deprecated them. >>=20 >> Ok. So, I suggest: >>=20 >> "Because ICE exchanges a multiplicity of IP addresses and ports for >> each media >> stream, it also allows for address selection for multihomed and = dual- >> stack hosts. For this reason RFC 5245 [RFC5245] deprecated RFC 4091 >> [RFC4091] and >> [RFC4092]." >>=20 >>=20 >> --- >>=20 >>=20 >>>>> -2.1, 4th paragraph from end: It would be helpful to describe what >>>>> =C2=B3valid >>>>> pair=C2=B2 means earlier in the document. >>>>=20 >>>> I assume you mean section 2.2? >>>=20 >>> Sorry, yes. >>>=20 >>>>=20 >>>> I suggest to following modification: >>>>=20 >>>> "The agent works through the check list by sending a STUN request = for >>>> the next candidate pair on the list periodically. These are = called >>>> ordinary checks. When a STUN transaction succeeds, one or more >>>> candidate pairs will become so called valid pairs, and will be = added >>>> to a candidate pair list called the valid list. >>>>=20 >>>>=20 >>>> As an optimization, as soon as R gets L's check message, R = schedules >>>> a connectivity check message to be sent to L on the same = candidate >>>> pair. This is called a triggered check, and accelerates the = process >>>> of finding valid pairs.=E2=80=9D >>>=20 >>> WFM >>>=20 >>>>=20 >>>>=20 >>>> I would not like to add more details to section 2 (I think it=C2=B9s = too >>>> detailed already), but I suggest to add >>>> the following to section 4: >>>>=20 >>>> "Valid Pair: A candidate pair whose local candidate equals the = mapped >>>> address of the connectivity check response, >>>> and whose remote candidate equals the destination address to = which >>>> the connectivity check request was sent.=E2=80=9D >>>=20 >>> Also WFM. >>>=20 >>>>=20 >>>>=20 >>>> Related to this, I note that the document uses both =C2=B3valid = pair=C2=B2 and >>>> =C2=B3valid candidate pair=C2=B2 terminology. Perhaps it=C2=B9s = enough to say =C2=B3valid >>>> pair=C2=B2 everywhere. >>>>=20 >>>> Related to this, there is a bug in section 2.3. The text shall say: >>>>=20 >>>> "For each component of a data stream, the controlling agent = nominates >>>> a valid pair from >>>> the valid list to be used for data.=E2=80=9D >>>=20 >>> I=E2=80=99m okay either way. (While I usually prefer consistency, I = imagine that >>> people can figure this one out.) >>=20 >> This is one of the things I always check when I do GenArt reviews :) >>=20 >> I had a look, and there weren=E2=80=99t too many instances of = =E2=80=9Cvalid candidate >> pair=E2=80=9D, so I changed them to =E2=80=9Cvalid pair=E2=80=9D in = order to align. >>=20 >> I implemented the changes in the PR. >>=20 >>=20 >> --- >>=20 >>>>=20 >>>>> -4: There are at least a few uses of lower case =C2=B3must=C2=B2 = and =C2=B3should=C2=B2 >>>>> that >>>>> do not appear to have been intended as keywords. If that is the = intent, >>>>> please update this to use the boilerplate from 8174. (The 2119 >>>>> boilerplate is ambiguous on whether lower case instances count as >>>>> keywords.) >>>>=20 >>>>=20 >>>> I suggest we keep the 2119 boilerplate, but I will go through the = lower >>>> case instances and see whether they should be capitalized. >>>=20 >>> Okay, although if you keep 2119, it might be better to change any = that >>> should remain non-capitalized to non-colliding terms. >>=20 >> I had a look. In most cases I could change to a non-colliding terms, = and >> in 1-2 cases I changed to upper case. >>=20 >> I implemented the changes in the PR. >>=20 >> =E2=80=94 >>=20 >>>>> -12.3: =C2=B3 As discussed below, ICE agents are encouraged to = re-adjust >>>>> jitter buffers=C5=A0=C2=B2 >>>>> Please cite the specific section(s). >>>>=20 >>>> I actually suggest to remove section 12.3. It is about receiving = data, >>>> and >>>> the content is covered in section 13. >>>>=20 >>>> I also suggest to change section 12.3 to 12.2.1, as the text is = only >>>> about >>>> sending media. >>>>=20 >>>> I also suggest to change section 13 to 12.3. It was always intended = to >>>> be >>>> a subsection to section 12. >>>=20 >>> No objection, but that goes beyond the scope of my comment :-) >>>=20 >>> (Normally I discourage lots of reorganization in bis drafts because = it >>> makes them harder to review against the original. But this is = already >>> enough of a re-write that this change would make little incremental >>> difference.) >>=20 >> Also note that =E2=80=9CReceiving media=E2=80=9D (section 13 in bis) = was a subsection in >> RFC 5245, so the 13->12.3 change will actually align the bis with the = RFC >> :) >>=20 >> =E2=80=94 >>=20 >>>>=20 >>>>> -17.2, last bullet: Why call out viruses specifically? It seems = like >>>>> there are a lot of ways a server might be compromised that do not >>>>> involve >>>>> viruses per se. (Same in 17.3). >>>>=20 >>>> My only answer is that this is text from RFC 5245. >>>> I can remove =C2=B3virus=C2=B2, and simply say: >>>>=20 >>>> "An attacker can compromise a STUN server, and cause it to send >>>> responses >>>> with incorrect mapped addresses.=C2=B2 (17.2) >>>>=20 >>>>=20 >>>> =C5=A0and: >>>>=20 >>>> "However, TURN servers are susceptible to DNS attacks for purposes = of >>>> turning it into a zombie or rogue server.=E2=80=9D >>>=20 >>> Okay. On reflection, I=E2=80=99m also okay leaving things as is in = deference to >>> 5245. >>=20 >> I already removed it in the PR, so if you are ok with that I won=E2=80=99= t put it >> back :) >>=20 >> --- >>=20 >>>>=20 >>>>> -17.4.1: Since the description of the voice hammer attack has been >>>>> removed, can you cite something that does describe it? (Appendix A >>>>> still >>>>> refers to section 17 to describe the voice hammer attack.) >>>>=20 >>>> I didn=C2=B9t really find a good citation, but maybe something = like: >>>>=20 >>>> "The STUN amplification attack is similar to a voice hammer attack, >>>> where >>>> the attacker causes other agents to direct media traffic towards = the >>>> attack target.=E2=80=9D >>>>=20 >>>=20 >>> WFM. Perhaps put =E2=80=9Cvoice hammer=E2=80=9D in quotes? >>=20 >> I will fix that. >>=20 >> --- >>=20 >>>>=20 >>>>> -22: Did you consider making this section an appendix? >>>>=20 >>>> I don=C2=B9t remember. I have no problem doing that, if you think = an appendix >>>> would be better. >>>=20 >>> On reflection, don=E2=80=99t worry about it. >>=20 >> Ok, I=E2=80=99ll keep it. >>=20 >> Updated PR: >>=20 >> https://github.com/ice-wg/rfc5245bis/pull/55 >>=20 >>=20 >> Regards, >>=20 >> Christer >>=20 >=20 --Apple-Mail=_3F0FB03E-B4C3-4D7A-ADE5-C6822E08CE30 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpWQPcACgkQgFZKbJXz 1A1OixAAol+dyqiA943XMA88XS1Ub9fZOYLeKzOACGUmVG21LRmltrxq7R4+9U5t ZgOg5N3nnppMqfXCruGiaqC1Q8bUcpuUU6Pwu9WIijKfcAw7TZ5sGrJvcopqskeI hSiQG371Lx/7+Alo74guVixz8ojr6gBAwt2HvSCMwqe5eOfDi3bExJkv6DcO+81d Zt5zEXxzWNbUp4UyGqzfed+Wjbb4sdTwhxpXKhAhJMjalkueq06EBzFGLj62H26R wqnnr0akwFucp89GLd3KRVlYul+GRbRUaQuijMetsGQ3SEKMOTEsxmwikaeykwqU BRR/J+wS4xIbWnIj48blXcCxiNPcIF1RQHZKlgu+QnOXF3VcAKGWfZ3qY5oanNX/ V+kSrb0S84YtHXIiPtDuWj1IB7lp2tVe2jr7muLARp24tyhoa5oaZgFWsygZpMB2 eaOmfz9vEVWe+uJKZR4tBwMaciGwUxL1kpoQ5lfjA665mlRCjOGRpUKFcnlD7lqo 7DKVXOwhecFX7MWikhRxah2FW1o1cY1mhCIM2ltPAtYnnRv8VLz0fugtOVFbSPEz qsEP0g4ZOMUhZHxjUUD+SwOBcJcl0t4j5UOROx8EyBIbyTR1M41zBWLCE+ufJjd+ 0UMRbmGCjbRBTK69BtAjEYCCPcgABXVo53s/WbVIP4Crkj+fGi0= =FjAU -----END PGP SIGNATURE----- --Apple-Mail=_3F0FB03E-B4C3-4D7A-ADE5-C6822E08CE30-- From nobody Wed Jan 10 10:34:40 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CDE12778D; Wed, 10 Jan 2018 10:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJbrB2ZVvJ04; Wed, 10 Jan 2018 10:34:37 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD5AA124BAC; Wed, 10 Jan 2018 10:34:36 -0800 (PST) X-AuditID: c1b4fb2d-b4dff70000007932-6f-5a565cbab5ef Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3B.E0.31026.ABC565A5; Wed, 10 Jan 2018 19:34:34 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Wed, 10 Jan 2018 19:34:34 +0100 From: Christer Holmberg To: =?utf-8?B?QXJpIEtlcsOkbmVu?= CC: Ben Campbell , "ice@ietf.org" , "draft-ietf-ice-rfc5245bis.all@ietf.org" Thread-Topic: AD Evaluation of draft-ietf-ice-rfc5245bis-15 Thread-Index: AQHTiPxCRxYiw9L/zEu/jMuzPPo1iKNrlLmAgAGjpgCAADf+UA== Date: Wed, 10 Jan 2018 18:34:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C0F7B58@ESESSMB109.ericsson.se> References: <28E9DD8B-5FEC-468D-B745-30D21E504B9D@nostrum.com> <4A671047-4C38-475C-A20F-D68C7E4A083A@ericsson.com> In-Reply-To: <4A671047-4C38-475C-A20F-D68C7E4A083A@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM2K7ge6umLAog4sdJhbzO0+zWxz/8Yfd 4tuFWgdmjyVLfjJ5zNr5hCWAKYrLJiU1J7MstUjfLoErY/m73ywFW/gqpnZNZ2lgbOHrYuTk kBAwkTjydBFzFyMXh5DAYUaJpdv2QTlLGCV6lrxg7GLk4GATsJDo/qcN0iAiYC3xd1YnO0gN s8AMRok5T5vZQBLCAlYSs1veM8IUff9zkw3CdpKYfGgBC4jNIqAqcWnZYzCbV8BXountIVaI ZcsYJRquPWICWcYp4CDxe78DSA2jgJjE91NrmEBsZgFxiVtP5jNBXC0gsWTPeWYIW1Ti5eN/ rBC2ksSi25/BxjALaEqs36UP0aooMaX7ITvEWkGJkzOfsExgFJ2FZOoshI5ZSDpmIelYwMiy ilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwWg5u+a27g3H1a8dDjAIcjEo8vIHBYVFCrIll xZW5hxglOJiVRHgXBwKFeFMSK6tSi/Lji0pzUosPMUpzsCiJ85705I0SEkhPLEnNTk0tSC2C yTJxcEo1MPaor3thVvFg05fzVYv+qS1lC4npOdvJ+uL3Bb/qJNP+ygcSlvuvs3tkaL4y7xFi DJlXuCcwn/tj4tGG49bFC10+vrPnsHgkvXP75Z0eU35Eh036K2exI2pictWELMF2jtgwt2rh 9y0vlFnqVI66+k/cZupmfU7cIEP9wt+tlsssykLNAubrK7EUZyQaajEXFScCAB33Z/qSAgAA Archived-At: Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-rfc5245bis-15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 18:34:39 -0000 SGksDQoNCj4+PiBTdWJzdGFudGl2ZSBDb21tZW50czoNCj4+PiANCj4+PiAtIDIuMSwgMm5kIHRv IGxhc3Q6IERvZXMgSUNFIHJlYWxseSBwcmlvcml0aXplIGEgcGF0aCB3aXRoIGZld2VyIE5BVHMg DQo+Pj4gb3ZlciBhIHBhdGggd2l0aCBtb3JlIE5BVHMsIG9yIGlzIGl0IG1vcmUgYSBtYXR0ZXIg b2Ygc2VsZWN0aW5nIGEgDQo+Pj4gcGF0aCB3aXRoIG5vIE5BVHMgb3ZlciBhIHBhdGggd2l0aCDC s3NvbWXCsiBOQVRzPyAoSWYgdGhlIGZvcm1lciwgaG93IA0KPj4+IGRvZXMgaXQgZmlndXJlIG91 dCBob3cgbWFueSBOQVRzIGFyZSBiZXR3ZWVuIGFuIGFnZW50IGFuZCBpdMK5cyBzZXJ2ZXJzIGFu ZCBwZWVycz8NCj4+PiBJcyB0aGlzIGp1c3QgYSBtYXR0ZXIgb2YgdGltaW5nPykNCj4+IA0KPj4g SUNFIGFnZW50cyBjYW7CuXQgZGV0ZXJtaW5lIGhvdyBtYW55IE5BVHMgdGhlcmUgYXJlLg0KPj4g DQo+PiBJIHN1Z2dlc3QgdG8gc2F5Og0KPj4gDQo+PiAgICJJbiBnZW5lcmFsLCB0aGUgcHJpb3Jp dHkgYWxnb3JpdGhtIGlzIGRlc2lnbmVkIHNvIHRoYXQgY2FuZGlkYXRlcyBvZg0KPj4gICAgc2lt aWxhciB0eXBlIGdldCBzaW1pbGFyIHByaW9yaXRpZXMgYW5kIHNvIHRoYXQgbW9yZSBkaXJlY3Qg cm91dGVzDQo+PiAgICAodGhhdCBpcywgcm91dGVzIHdpdGhvdXQgZGF0YSByZWxheXMgb3IgTkFU cykgYXJlIHByZWZlcnJlZCBvdmVyIA0KPj4gICBpbmRpcmVjdCByb3V0ZXMgKHJvdXRlcyB3aXRo IGRhdGEgcmVsYXlzIG9yIE5BVHMpLiINCj4NCj4gSUNFIG1ha2VzIGEgZGlmZmVyZW5jZSBiZXR3 ZWVuIG5vIE5BVHMsIG9uZSBhZ2VudCBiZWhpbmQgYSBOQVQsIGFuZCBib3RoIGFnZW50cyAob3Ig bW9yZSBzcGVjaWZpY2FsbHkgdGhlaXIgaW50ZXJmYWNlcyBiZWluZyBjaGVja2VkKSBiZWhpbmQg TkFUcy4gDQo+IEFuZCBhIHBhdGggd2l0aCBvbmx5IG9uZSBhZ2VudCBiZWhpbmQgYSBOQVQgd291 bGQgYmUgImZld2VyIE5BVHMiIHRoYW4gYm90aCBiZWhpbmQgTkFUcy4gQWRtaXR0ZWRseSB0aGVy ZSBjb3VsZCBiZSBhIGNhc2NhZGUgb2YgMyBOQVRzIGluIGZyb250IG9mIG9uZSBvZiB0aGUgYWdl bnRzIA0KPiBhbmQgdGhleSB3b3VsZCBiZSAiY291bnRlZCIgYXMgYSBzaW5nbGUgTkFULg0KDQpD b3JyZWN0LCB0aGF0J3Mgd2hhdCBJIG1lYW50Lg0KDQo+IFRoYXQgc2FpZCwgSSB0aGluayB0aGUg dGV4dCB5b3Ugc3VnZ2VzdGVkIGlzIGFsc28gY29ycmVjdC4gQW5kIHByb2JhYmx5IGxlc3MgY29u ZnVzaW5nIHRvby4NCg0KTWFraW5nIElDRSBsZXNzIGNvbmZ1c2luZyBoYXMgYmVlbiBteSBtaXNz aW9uIDopDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Wed Jan 10 11:47:40 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C386A126DED; Wed, 10 Jan 2018 11:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HV193F6_zAFJ; Wed, 10 Jan 2018 11:47:36 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B277124207; Wed, 10 Jan 2018 11:47:36 -0800 (PST) X-AuditID: c1b4fb25-48bff7000000341b-61-5a566dd6ffae Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 2C.BE.13339.6DD665A5; Wed, 10 Jan 2018 20:47:34 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Wed, 10 Jan 2018 20:47:33 +0100 From: Christer Holmberg To: Ben Campbell CC: "ice@ietf.org" , "draft-ietf-ice-rfc5245bis.all@ietf.org" Thread-Topic: AD Evaluation of draft-ietf-ice-rfc5245bis-15 Thread-Index: AQHTiPxCRxYiw9L/zEu/jMuzPPo1iKNrlLmAgAAmCACAAVgqgIAAKLyAgABJvBA= Date: Wed, 10 Jan 2018 19:47:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C0F7CBD@ESESSMB109.ericsson.se> References: <28E9DD8B-5FEC-468D-B745-30D21E504B9D@nostrum.com> <54D05F30-E2A1-42E4-BAEF-D39D134D0C49@nostrum.com> <583094F9-BFD0-4025-AA16-9E22A503E609@nostrum.com> In-Reply-To: <583094F9-BFD0-4025-AA16-9E22A503E609@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7je613LAogzlbxC3md55mtzj+4w+7 xbcLtQ7MHkuW/GTymLXzCUsAUxSXTUpqTmZZapG+XQJXxpqPa1gL9kVWTHj+mamBcUZ4FyMH h4SAicT8JTFdjFwcQgKHGSWuP/jMDOEsYZQ4fHwBE0gRm4CFRPc/7S5GTg4RASWJ581bWUDC zAJlEjNmM4OEhQWsJGa3vGeEKLGW+P7nJhuE7Sfx+/t+dhCbRUBV4tK6t2BxXgFfiaUr5jJB rOphknja0wU2iFPAXmJV9zywIkYBMYnvp9YwgdjMAuISt57MB7MlBAQkluw5zwxhi0q8fPyP FcJWkmhc8oQV4jZNifW79CFaFSWmdD9kh9grKHFy5hOWCYyis5BMnYXQMQtJxywkHQsYWVYx ihanFiflphsZ66UWZSYXF+fn6eWllmxiBEbKwS2/VXcwXn7jeIhRgINRiYe3NSMsSog1say4 MvcQowQHs5II7+JAoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHek568UUIC6YklqdmpqQWpRTBZ Jg5OqQZGNd5313g+BpWapZdL5Py56L5GN8+sLfTw1olmbJEKef13q3/ttAtLYJm+ILXx6u7P IfHrjqQ833/FOE33APvy2zEnvz5du1qi7lVrY3BlzCNh3Uszfq8Rn/arZ6qjyNptcWq5KYf3 RU04U/+9Yun/Ziv1DdLTIkr9Kp4G+N9rErf+d+6Cl3+eEktxRqKhFnNRcSIAJXOYs5ACAAA= Archived-At: Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-rfc5245bis-15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 19:47:40 -0000 SGksDQoNCkkgaGF2ZSB1cGRhdGVkIHRoZSBQUiwgYmFzZWQgb24gdGhlIGNvbW1lbnRzIGZyb20g QXJpLg0KDQpVbmxlc3MgeW91IG9iamVjdCwgSSBpbnRlbmQgdG8gc3VibWl0IGEgbmV3IHZlcnNp b24gb2YgdGhlIGRyYWZ0IHRvbW9ycm93IG1vcm5pbmcgOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCZW4gQ2FtcGJlbGwg W21haWx0bzpiZW5Abm9zdHJ1bS5jb21dIA0KU2VudDogMTAgSmFudWFyeSAyMDE4IDE4OjIyDQpU bzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkNj OiBpY2VAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXMuYWxsQGlldGYub3JnDQpT dWJqZWN0OiBSZTogQUQgRXZhbHVhdGlvbiBvZiBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzLTE1 DQoNCg0KDQo+IE9uIEphbiAxMCwgMjAxOCwgYXQgNTo0NSBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcg PGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSwNCj4gDQo+ Pj4gDQo+Pj4+IFNob3VsZCDCs3NlY3VyZSBzaWduYWxpbmcgdGVjaG5pcXVlc8KyIGRpc3Rpbmd1 aXNoIGJldHdlZW4gSEJIIGFuZCANCj4+Pj4gRTJFIHRlY2huaXF1ZXMsIGluIGxpZ2h0IG9mIHRo ZSBsYXRlciBkaXNjdXNzaW9uIGFib3V0IGluc2lkZXIgYXR0YWNrcz8NCj4+PiANCj4+PiBMYXRl ciBkb3duIGluIHRoZSByZXBseSBJIHN1Z2dlc3QgdG8gcmVtb3ZlIHRoZSBidWxsZXQgbGlzdC4N Cj4+IA0KPj4gT2theSwgZG9lcyBpdCBtYWtlIHNlbnNlIHRvIGRpc2N1c3MgSEJIIHZzIEUyRSBw cm90ZWN0aW9ucyBpbiB0aGUgDQo+PiBzZWN0aW9uIGFib3V0IGluc2lkZXIgYXR0YWNrcz8NCj4g DQo+IEkgZG9u4oCZdCBrbm93LiBEbyB3ZSBoYXZlIHRoZSByaWdodCBwZW9wbGU/IFdvdWxkIHdl IGdldCBhbnkgdXNlZnVsIGlucHV0Pw0KDQpJIHdhc27igJl0IGFza2luZyBmb3IgYSBkZXRhaWxl ZCBkaXNjdXNzaW9u4oCUbWF5YmUganVzdCBhIDEgc2VudGVuY2UgYWNrbm93bGVkZ2VtZW50IHRo YXQgdGhpbmdzIGxpa2UgU0lQUyBkbyBub3QgYnkgdGhlbXNlbHZlcyBwcmV2ZW50IGFuIGluc2lk ZXIgb3IgYSBjb21wcm9taXNlZCBwcm94eS9iMmJ1YSBmcm9tIGVhdmVzZHJvcHBpbmcgb24gYW5k L29yIHRhbXBlcmluZyB3aXRoIHRoZSBjYW5kaWRhdGUgZXhjaGFuZ2UuDQoNCj4gDQo+IE15IHN1 Z2dlc3Rpb24gd291bGQgYmUgdG8gd2FpdCBmb3IgdGhlIFNFQ0RJUi0gYW5kIFNFQyBBRCByZXZp ZXdzIGV0YywgDQo+IGFuZCBzZWUgd2hhdC9pZiB0aGV5IHNheS4NCg0KSeKAmW0gb2theSB3aXRo IHRoYXQuDQoNCltUaGUgcmVzdCBvZiB5b3VyIHJlc3BvbnNlcyBsb29rIGZpbmUuXQ0KDQpUaGFu a3MhDQoNCkJlbi4NCg0KPiANCj4gPT09PQ0KPiANCj4gRWRpdG9yaWFsIENvbW1lbnRzIGFuZCBO aXRzOg0KPiANCj4+Pj4gDQo+Pj4+IElzIHRoZXJlIGEgcmVhc29uIHRoYXQgdGhlIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zIGFuZCBJQU5BIA0KPj4+PiBjb25zaWRlcmF0aW9ucyBhcmUgbm90IGlu IHRoZSBjb252ZW50aW9uYWwgbG9jYXRpb25zIChpLmUuIHRoZSBsYXN0IA0KPj4+PiB0d28gc2Vj dGlvbnMgYmVmb3JlIHRoZSByZWZlcmVuY2VzKT8gKEkgc2VlIHRoYXQgaXMgYWxzbyB0cnVlIGlu IA0KPj4+PiA1MjQ1LCBzbyB0aGlzIGlzIG1vc3RseSBjdXJpb3NpdHkuKQ0KPj4+IA0KPj4+IE5v IHJlYXNvbi4NCj4+PiANCj4+PiBJIHN1Z2dlc3QgdG8gbW92ZSB0aGUgc2VjdGlvbnMuDQo+Pj4g DQo+PiANCj4+IE9rYXkuIChJ4oCZbSBhbHNvIG9rYXkgbGVhdmluZyBpdCBhcyBpcyB1bmxlc3Mg c29tZW9uZSBvYmplY3RzIGluIElFVEYgTEMpLg0KPiANCj4gSSBhbHJlYWR5IG1vdmVkIHRoZW0g aW4gdGhlIHB1bGwgcmVxdWVzdCA6KQ0KPiANCj4gLS0tDQo+IA0KPj4+IA0KPj4+IC0tLQ0KPj4+ IA0KPj4+PiDigLkgRGlkbid0IDUyNDUgYWxyZWFkeSBkZXByZWNhdGUgUkZDIDQwOTEgYW5kIDQw OTI/IFRoYXQgaXMsIF90aGlzXyANCj4+Pj4gZG9jdW1lbnQgZG9lcyBub3QgZG8gdGhhdC4NCj4+ PiANCj4+PiBJIHN1Z2dlc3QgdG8gcmVtb3ZlIHRoZSBzZW50ZW5jZSwgYW5kIHRoZSBSRkMgcmVm ZXJlbmNlcy4NCj4+IA0KPj4gSeKAmW0gb2theSB3aXRoIHRoYXQsIGJ1dCBpdCBtaWdodCBiZSBo ZWxwZnVsIHRvIG1lcmVseSBhZGp1c3QgdGhlIA0KPj4gd29yZGluZyB0byBzYXkgdGhhdCA1MjQ1 IGRlcHJlY2F0ZWQgdGhlbS4NCj4gDQo+IE9rLiBTbywgSSBzdWdnZXN0Og0KPiANCj4gICAiQmVj YXVzZSBJQ0UgZXhjaGFuZ2VzIGEgbXVsdGlwbGljaXR5IG9mIElQIGFkZHJlc3NlcyBhbmQgcG9y dHMgZm9yIA0KPiBlYWNoIG1lZGlhDQo+ICAgIHN0cmVhbSwgaXQgYWxzbyBhbGxvd3MgZm9yIGFk ZHJlc3Mgc2VsZWN0aW9uIGZvciBtdWx0aWhvbWVkIGFuZCBkdWFsLQ0KPiAgICBzdGFjayBob3N0 cy4gRm9yIHRoaXMgcmVhc29uIFJGQyA1MjQ1IFtSRkM1MjQ1XSBkZXByZWNhdGVkIFJGQyA0MDkx IA0KPiBbUkZDNDA5MV0gYW5kDQo+ICAgIFtSRkM0MDkyXS4iDQo+IA0KPiANCj4gLS0tDQo+IA0K PiANCj4+Pj4gLTIuMSwgNHRoIHBhcmFncmFwaCBmcm9tIGVuZDogSXQgd291bGQgYmUgaGVscGZ1 bCB0byBkZXNjcmliZSB3aGF0IA0KPj4+PiDCs3ZhbGlkIHBhaXLCsiBtZWFucyBlYXJsaWVyIGlu IHRoZSBkb2N1bWVudC4NCj4+PiANCj4+PiBJIGFzc3VtZSB5b3UgbWVhbiBzZWN0aW9uIDIuMj8N Cj4+IA0KPj4gU29ycnksIHllcy4NCj4+IA0KPj4+IA0KPj4+IEkgc3VnZ2VzdCB0byBmb2xsb3dp bmcgbW9kaWZpY2F0aW9uOg0KPj4+IA0KPj4+ICAgIlRoZSBhZ2VudCB3b3JrcyB0aHJvdWdoIHRo ZSBjaGVjayBsaXN0IGJ5IHNlbmRpbmcgYSBTVFVOIHJlcXVlc3QgZm9yDQo+Pj4gICAgdGhlIG5l eHQgY2FuZGlkYXRlIHBhaXIgb24gdGhlIGxpc3QgcGVyaW9kaWNhbGx5LiAgVGhlc2UgYXJlIGNh bGxlZA0KPj4+ICAgIG9yZGluYXJ5IGNoZWNrcy4gV2hlbiBhIFNUVU4gdHJhbnNhY3Rpb24gc3Vj Y2VlZHMsIG9uZSBvciBtb3JlDQo+Pj4gICAgY2FuZGlkYXRlIHBhaXJzIHdpbGwgYmVjb21lIHNv IGNhbGxlZCB2YWxpZCBwYWlycywgYW5kIHdpbGwgYmUgYWRkZWQNCj4+PiAgICB0byBhIGNhbmRp ZGF0ZSBwYWlyIGxpc3QgY2FsbGVkIHRoZSB2YWxpZCBsaXN0Lg0KPj4+IA0KPj4+IA0KPj4+ICAg IEFzIGFuIG9wdGltaXphdGlvbiwgYXMgc29vbiBhcyBSIGdldHMgTCdzIGNoZWNrIG1lc3NhZ2Us IFIgc2NoZWR1bGVzDQo+Pj4gICAgYSBjb25uZWN0aXZpdHkgY2hlY2sgbWVzc2FnZSB0byBiZSBz ZW50IHRvIEwgb24gdGhlIHNhbWUgY2FuZGlkYXRlDQo+Pj4gICAgcGFpci4gVGhpcyBpcyBjYWxs ZWQgYSB0cmlnZ2VyZWQgY2hlY2ssIGFuZCBhY2NlbGVyYXRlcyB0aGUgcHJvY2Vzcw0KPj4+ICAg IG9mIGZpbmRpbmcgdmFsaWQgcGFpcnMu4oCdDQo+PiANCj4+IFdGTQ0KPj4gDQo+Pj4gDQo+Pj4g DQo+Pj4gSSB3b3VsZCBub3QgbGlrZSB0byBhZGQgbW9yZSBkZXRhaWxzIHRvIHNlY3Rpb24gMiAo SSB0aGluayBpdMK5cyB0b28gDQo+Pj4gZGV0YWlsZWQgYWxyZWFkeSksIGJ1dCBJIHN1Z2dlc3Qg dG8gYWRkIHRoZSBmb2xsb3dpbmcgdG8gc2VjdGlvbiA0Og0KPj4+IA0KPj4+ICAgIlZhbGlkIFBh aXI6IEEgY2FuZGlkYXRlIHBhaXIgd2hvc2UgbG9jYWwgY2FuZGlkYXRlIGVxdWFscyB0aGUgDQo+ Pj4gbWFwcGVkIGFkZHJlc3Mgb2YgdGhlIGNvbm5lY3Rpdml0eSBjaGVjayByZXNwb25zZSwNCj4+ PiAgICBhbmQgd2hvc2UgcmVtb3RlIGNhbmRpZGF0ZSBlcXVhbHMgdGhlIGRlc3RpbmF0aW9uIGFk ZHJlc3MgdG8gDQo+Pj4gd2hpY2ggdGhlIGNvbm5lY3Rpdml0eSBjaGVjayByZXF1ZXN0IHdhcyBz ZW50LuKAnQ0KPj4gDQo+PiBBbHNvIFdGTS4NCj4+IA0KPj4+IA0KPj4+IA0KPj4+IFJlbGF0ZWQg dG8gdGhpcywgSSBub3RlIHRoYXQgdGhlIGRvY3VtZW50IHVzZXMgYm90aCDCs3ZhbGlkIHBhaXLC siBhbmQgDQo+Pj4gwrN2YWxpZCBjYW5kaWRhdGUgcGFpcsKyIHRlcm1pbm9sb2d5LiBQZXJoYXBz IGl0wrlzIGVub3VnaCB0byBzYXkgDQo+Pj4gwrN2YWxpZCBwYWlywrIgZXZlcnl3aGVyZS4NCj4+ PiANCj4+PiBSZWxhdGVkIHRvIHRoaXMsIHRoZXJlIGlzIGEgYnVnIGluIHNlY3Rpb24gMi4zLiBU aGUgdGV4dCBzaGFsbCBzYXk6DQo+Pj4gDQo+Pj4gICAiRm9yIGVhY2ggY29tcG9uZW50IG9mIGEg ZGF0YSBzdHJlYW0sIHRoZSBjb250cm9sbGluZyBhZ2VudCANCj4+PiBub21pbmF0ZXMgYSB2YWxp ZCBwYWlyIGZyb20NCj4+PiAgICB0aGUgdmFsaWQgbGlzdCB0byBiZSB1c2VkIGZvciBkYXRhLuKA nQ0KPj4gDQo+PiBJ4oCZbSBva2F5IGVpdGhlciB3YXkuIChXaGlsZSBJIHVzdWFsbHkgcHJlZmVy IGNvbnNpc3RlbmN5LCBJIGltYWdpbmUgDQo+PiB0aGF0IHBlb3BsZSBjYW4gZmlndXJlIHRoaXMg b25lIG91dC4pDQo+IA0KPiBUaGlzIGlzIG9uZSBvZiB0aGUgdGhpbmdzIEkgYWx3YXlzIGNoZWNr IHdoZW4gSSBkbyBHZW5BcnQgcmV2aWV3cyA6KQ0KPiANCj4gSSBoYWQgYSBsb29rLCBhbmQgdGhl cmUgd2VyZW7igJl0IHRvbyBtYW55IGluc3RhbmNlcyBvZiDigJx2YWxpZCBjYW5kaWRhdGUgDQo+ IHBhaXLigJ0sIHNvIEkgY2hhbmdlZCB0aGVtIHRvIOKAnHZhbGlkIHBhaXLigJ0gaW4gb3JkZXIg dG8gYWxpZ24uDQo+IA0KPiBJIGltcGxlbWVudGVkIHRoZSBjaGFuZ2VzIGluIHRoZSBQUi4NCj4g DQo+IA0KPiAtLS0NCj4gDQo+Pj4gDQo+Pj4+IC00OiBUaGVyZSBhcmUgYXQgbGVhc3QgYSBmZXcg dXNlcyBvZiBsb3dlciBjYXNlIMKzbXVzdMKyIGFuZCDCs3Nob3VsZMKyIA0KPj4+PiB0aGF0IGRv IG5vdCBhcHBlYXIgdG8gaGF2ZSBiZWVuIGludGVuZGVkIGFzIGtleXdvcmRzLiBJZiB0aGF0IGlz IA0KPj4+PiB0aGUgaW50ZW50LCBwbGVhc2UgdXBkYXRlIHRoaXMgdG8gdXNlIHRoZSBib2lsZXJw bGF0ZSBmcm9tIDgxNzQuICANCj4+Pj4gKFRoZSAyMTE5IGJvaWxlcnBsYXRlIGlzIGFtYmlndW91 cyBvbiB3aGV0aGVyIGxvd2VyIGNhc2UgaW5zdGFuY2VzIA0KPj4+PiBjb3VudCBhcw0KPj4+PiBr ZXl3b3Jkcy4pDQo+Pj4gDQo+Pj4gDQo+Pj4gSSBzdWdnZXN0IHdlIGtlZXAgdGhlIDIxMTkgYm9p bGVycGxhdGUsIGJ1dCBJIHdpbGwgZ28gdGhyb3VnaCB0aGUgDQo+Pj4gbG93ZXIgY2FzZSBpbnN0 YW5jZXMgYW5kIHNlZSB3aGV0aGVyIHRoZXkgc2hvdWxkIGJlIGNhcGl0YWxpemVkLg0KPj4gDQo+ PiBPa2F5LCBhbHRob3VnaCBpZiB5b3Uga2VlcCAyMTE5LCBpdCBtaWdodCBiZSBiZXR0ZXIgdG8g Y2hhbmdlIGFueSANCj4+IHRoYXQgc2hvdWxkIHJlbWFpbiBub24tY2FwaXRhbGl6ZWQgdG8gbm9u LWNvbGxpZGluZyB0ZXJtcy4NCj4gDQo+IEkgaGFkIGEgbG9vay4gSW4gbW9zdCBjYXNlcyBJIGNv dWxkIGNoYW5nZSB0byBhIG5vbi1jb2xsaWRpbmcgdGVybXMsIA0KPiBhbmQgaW4gMS0yIGNhc2Vz IEkgY2hhbmdlZCB0byB1cHBlciBjYXNlLg0KPiANCj4gSSBpbXBsZW1lbnRlZCB0aGUgY2hhbmdl cyBpbiB0aGUgUFIuDQo+IA0KPiDigJQNCj4gDQo+Pj4+IC0xMi4zOiDCsyBBcyBkaXNjdXNzZWQg YmVsb3csIElDRSBhZ2VudHMgYXJlIGVuY291cmFnZWQgdG8gcmUtYWRqdXN0IA0KPj4+PiBqaXR0 ZXIgYnVmZmVyc8WgwrIgUGxlYXNlIGNpdGUgdGhlIHNwZWNpZmljIHNlY3Rpb24ocykuDQo+Pj4g DQo+Pj4gSSBhY3R1YWxseSBzdWdnZXN0IHRvIHJlbW92ZSBzZWN0aW9uIDEyLjMuIEl0IGlzIGFi b3V0IHJlY2VpdmluZyANCj4+PiBkYXRhLCBhbmQgdGhlIGNvbnRlbnQgaXMgY292ZXJlZCBpbiBz ZWN0aW9uIDEzLg0KPj4+IA0KPj4+IEkgYWxzbyBzdWdnZXN0IHRvIGNoYW5nZSBzZWN0aW9uIDEy LjMgdG8gMTIuMi4xLCBhcyB0aGUgdGV4dCBpcyBvbmx5IA0KPj4+IGFib3V0IHNlbmRpbmcgbWVk aWEuDQo+Pj4gDQo+Pj4gSSBhbHNvIHN1Z2dlc3QgdG8gY2hhbmdlIHNlY3Rpb24gMTMgdG8gMTIu My4gSXQgd2FzIGFsd2F5cyBpbnRlbmRlZCANCj4+PiB0byBiZSBhIHN1YnNlY3Rpb24gdG8gc2Vj dGlvbiAxMi4NCj4+IA0KPj4gTm8gb2JqZWN0aW9uLCBidXQgdGhhdCBnb2VzIGJleW9uZCB0aGUg c2NvcGUgb2YgbXkgY29tbWVudCA6LSkNCj4+IA0KPj4gKE5vcm1hbGx5IEkgZGlzY291cmFnZSBs b3RzIG9mIHJlb3JnYW5pemF0aW9uIGluIGJpcyBkcmFmdHMgYmVjYXVzZSANCj4+IGl0IG1ha2Vz IHRoZW0gaGFyZGVyIHRvIHJldmlldyBhZ2FpbnN0IHRoZSBvcmlnaW5hbC4gQnV0IHRoaXMgaXMg DQo+PiBhbHJlYWR5IGVub3VnaCBvZiBhIHJlLXdyaXRlIHRoYXQgdGhpcyBjaGFuZ2Ugd291bGQg bWFrZSBsaXR0bGUgDQo+PiBpbmNyZW1lbnRhbA0KPj4gZGlmZmVyZW5jZS4pDQo+IA0KPiBBbHNv IG5vdGUgdGhhdCDigJxSZWNlaXZpbmcgbWVkaWHigJ0gKHNlY3Rpb24gMTMgaW4gYmlzKSB3YXMg YSBzdWJzZWN0aW9uIA0KPiBpbiBSRkMgNTI0NSwgc28gdGhlIDEzLT4xMi4zIGNoYW5nZSB3aWxs IGFjdHVhbGx5IGFsaWduIHRoZSBiaXMgd2l0aCANCj4gdGhlIFJGQw0KPiA6KQ0KPiANCj4g4oCU DQo+IA0KPj4+IA0KPj4+PiAtMTcuMiwgbGFzdCBidWxsZXQ6IFdoeSBjYWxsIG91dCB2aXJ1c2Vz IHNwZWNpZmljYWxseT8gSXQgc2VlbXMgDQo+Pj4+IGxpa2UgdGhlcmUgYXJlIGEgbG90IG9mIHdh eXMgYSBzZXJ2ZXIgbWlnaHQgYmUgY29tcHJvbWlzZWQgdGhhdCBkbyANCj4+Pj4gbm90IGludm9s dmUgdmlydXNlcyBwZXIgc2UuIChTYW1lIGluIDE3LjMpLg0KPj4+IA0KPj4+IE15IG9ubHkgYW5z d2VyIGlzIHRoYXQgdGhpcyBpcyB0ZXh0IGZyb20gUkZDIDUyNDUuDQo+Pj4gSSBjYW4gcmVtb3Zl IMKzdmlydXPCsiwgYW5kIHNpbXBseSBzYXk6DQo+Pj4gDQo+Pj4gIkFuIGF0dGFja2VyIGNhbiBj b21wcm9taXNlIGEgU1RVTiBzZXJ2ZXIsIGFuZCBjYXVzZSBpdCB0byBzZW5kIA0KPj4+IHJlc3Bv bnNlcyB3aXRoIGluY29ycmVjdCBtYXBwZWQgYWRkcmVzc2VzLsKyICgxNy4yKQ0KPj4+IA0KPj4+ IA0KPj4+IMWgYW5kOg0KPj4+IA0KPj4+ICJIb3dldmVyLCBUVVJOIHNlcnZlcnMgYXJlIHN1c2Nl cHRpYmxlIHRvIEROUyBhdHRhY2tzIGZvciBwdXJwb3NlcyANCj4+PiBvZiB0dXJuaW5nIGl0IGlu dG8gYSB6b21iaWUgb3Igcm9ndWUgc2VydmVyLuKAnQ0KPj4gDQo+PiBPa2F5LiBPbiByZWZsZWN0 aW9uLCAgSeKAmW0gYWxzbyBva2F5IGxlYXZpbmcgdGhpbmdzIGFzIGlzIGluIGRlZmVyZW5jZSAN Cj4+IHRvIDUyNDUuDQo+IA0KPiBJIGFscmVhZHkgcmVtb3ZlZCBpdCBpbiB0aGUgUFIsIHNvIGlm IHlvdSBhcmUgb2sgd2l0aCB0aGF0IEkgd29u4oCZdCBwdXQgDQo+IGl0IGJhY2sgOikNCj4gDQo+ IC0tLQ0KPiANCj4+PiANCj4+Pj4gLTE3LjQuMTogU2luY2UgdGhlIGRlc2NyaXB0aW9uIG9mIHRo ZSB2b2ljZSBoYW1tZXIgYXR0YWNrIGhhcyBiZWVuIA0KPj4+PiByZW1vdmVkLCBjYW4geW91IGNp dGUgc29tZXRoaW5nIHRoYXQgZG9lcyBkZXNjcmliZSBpdD8gKEFwcGVuZGl4IEEgDQo+Pj4+IHN0 aWxsIHJlZmVycyB0byBzZWN0aW9uIDE3IHRvIGRlc2NyaWJlIHRoZSB2b2ljZSBoYW1tZXIgYXR0 YWNrLikNCj4+PiANCj4+PiBJIGRpZG7CuXQgcmVhbGx5IGZpbmQgYSBnb29kIGNpdGF0aW9uLCBi dXQgbWF5YmUgc29tZXRoaW5nIGxpa2U6DQo+Pj4gDQo+Pj4gIlRoZSBTVFVOIGFtcGxpZmljYXRp b24gYXR0YWNrIGlzIHNpbWlsYXIgdG8gYSB2b2ljZSBoYW1tZXIgYXR0YWNrLCANCj4+PiB3aGVy ZSB0aGUgYXR0YWNrZXIgY2F1c2VzIG90aGVyIGFnZW50cyB0byBkaXJlY3QgbWVkaWEgdHJhZmZp YyANCj4+PiB0b3dhcmRzIHRoZSBhdHRhY2sgdGFyZ2V0LuKAnQ0KPj4+IA0KPj4gDQo+PiBXRk0u IFBlcmhhcHMgcHV0IOKAnHZvaWNlIGhhbW1lcuKAnSBpbiBxdW90ZXM/DQo+IA0KPiBJIHdpbGwg Zml4IHRoYXQuDQo+IA0KPiAtLS0NCj4gDQo+Pj4gDQo+Pj4+IC0yMjogRGlkIHlvdSBjb25zaWRl ciBtYWtpbmcgdGhpcyBzZWN0aW9uIGFuIGFwcGVuZGl4Pw0KPj4+IA0KPj4+IEkgZG9uwrl0IHJl bWVtYmVyLiBJIGhhdmUgbm8gcHJvYmxlbSBkb2luZyB0aGF0LCBpZiB5b3UgdGhpbmsgYW4gDQo+ Pj4gYXBwZW5kaXggd291bGQgYmUgYmV0dGVyLg0KPj4gDQo+PiBPbiByZWZsZWN0aW9uLCBkb27i gJl0IHdvcnJ5IGFib3V0IGl0Lg0KPiANCj4gT2ssIEnigJlsbCBrZWVwIGl0Lg0KPiANCj4gVXBk YXRlZCBQUjoNCj4gDQo+IGh0dHBzOi8vZ2l0aHViLmNvbS9pY2Utd2cvcmZjNTI0NWJpcy9wdWxs LzU1DQo+IA0KPiANCj4gUmVnYXJkcywNCj4gDQo+IENocmlzdGVyDQo+IA0KDQo= From nobody Wed Jan 10 12:38:23 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E5012711B; Wed, 10 Jan 2018 12:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2HC8g-YcxVg; Wed, 10 Jan 2018 12:38:19 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C4401271DF; Wed, 10 Jan 2018 12:38:19 -0800 (PST) Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0AKcCWg058169 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 Jan 2018 14:38:14 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F8834D16-571E-4FE8-9982-5ECA18DEFC18"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 10 Jan 2018 14:37:49 -0600 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C0F7CBD@ESESSMB109.ericsson.se> Cc: "ice@ietf.org" , "draft-ietf-ice-rfc5245bis.all@ietf.org" To: Christer Holmberg References: <28E9DD8B-5FEC-468D-B745-30D21E504B9D@nostrum.com> <54D05F30-E2A1-42E4-BAEF-D39D134D0C49@nostrum.com> <583094F9-BFD0-4025-AA16-9E22A503E609@nostrum.com> <7594FB04B1934943A5C02806D1A2204B6C0F7CBD@ESESSMB109.ericsson.se> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-rfc5245bis-15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 20:38:21 -0000 --Apple-Mail=_F8834D16-571E-4FE8-9982-5ECA18DEFC18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 By all means, please do so :-) > On Jan 10, 2018, at 1:47 PM, Christer Holmberg = wrote: >=20 > Hi, >=20 > I have updated the PR, based on the comments from Ari. >=20 > Unless you object, I intend to submit a new version of the draft = tomorrow morning :) >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: 10 January 2018 18:22 > To: Christer Holmberg > Cc: ice@ietf.org; draft-ietf-ice-rfc5245bis.all@ietf.org > Subject: Re: AD Evaluation of draft-ietf-ice-rfc5245bis-15 >=20 >=20 >=20 >> On Jan 10, 2018, at 5:45 AM, Christer Holmberg = wrote: >>=20 >> Hi, >>=20 >>>>=20 >>>>> Should =C2=B3secure signaling techniques=C2=B2 distinguish between = HBH and >>>>> E2E techniques, in light of the later discussion about insider = attacks? >>>>=20 >>>> Later down in the reply I suggest to remove the bullet list. >>>=20 >>> Okay, does it make sense to discuss HBH vs E2E protections in the >>> section about insider attacks? >>=20 >> I don=E2=80=99t know. Do we have the right people? Would we get any = useful input? >=20 > I wasn=E2=80=99t asking for a detailed discussion=E2=80=94maybe just a = 1 sentence acknowledgement that things like SIPS do not by themselves = prevent an insider or a compromised proxy/b2bua from eavesdropping on = and/or tampering with the candidate exchange. >=20 >>=20 >> My suggestion would be to wait for the SECDIR- and SEC AD reviews = etc, >> and see what/if they say. >=20 > I=E2=80=99m okay with that. >=20 > [The rest of your responses look fine.] >=20 > Thanks! >=20 > Ben. >=20 >>=20 >> =3D=3D=3D=3D >>=20 >> Editorial Comments and Nits: >>=20 >>>>>=20 >>>>> Is there a reason that the Security Considerations and IANA >>>>> considerations are not in the conventional locations (i.e. the = last >>>>> two sections before the references)? (I see that is also true in >>>>> 5245, so this is mostly curiosity.) >>>>=20 >>>> No reason. >>>>=20 >>>> I suggest to move the sections. >>>>=20 >>>=20 >>> Okay. (I=E2=80=99m also okay leaving it as is unless someone objects = in IETF LC). >>=20 >> I already moved them in the pull request :) >>=20 >> --- >>=20 >>>>=20 >>>> --- >>>>=20 >>>>> =E2=80=B9 Didn't 5245 already deprecate RFC 4091 and 4092? That = is, _this_ >>>>> document does not do that. >>>>=20 >>>> I suggest to remove the sentence, and the RFC references. >>>=20 >>> I=E2=80=99m okay with that, but it might be helpful to merely adjust = the >>> wording to say that 5245 deprecated them. >>=20 >> Ok. So, I suggest: >>=20 >> "Because ICE exchanges a multiplicity of IP addresses and ports for >> each media >> stream, it also allows for address selection for multihomed and = dual- >> stack hosts. For this reason RFC 5245 [RFC5245] deprecated RFC 4091 >> [RFC4091] and >> [RFC4092]." >>=20 >>=20 >> --- >>=20 >>=20 >>>>> -2.1, 4th paragraph from end: It would be helpful to describe what >>>>> =C2=B3valid pair=C2=B2 means earlier in the document. >>>>=20 >>>> I assume you mean section 2.2? >>>=20 >>> Sorry, yes. >>>=20 >>>>=20 >>>> I suggest to following modification: >>>>=20 >>>> "The agent works through the check list by sending a STUN request = for >>>> the next candidate pair on the list periodically. These are = called >>>> ordinary checks. When a STUN transaction succeeds, one or more >>>> candidate pairs will become so called valid pairs, and will be = added >>>> to a candidate pair list called the valid list. >>>>=20 >>>>=20 >>>> As an optimization, as soon as R gets L's check message, R = schedules >>>> a connectivity check message to be sent to L on the same = candidate >>>> pair. This is called a triggered check, and accelerates the = process >>>> of finding valid pairs.=E2=80=9D >>>=20 >>> WFM >>>=20 >>>>=20 >>>>=20 >>>> I would not like to add more details to section 2 (I think it=C2=B9s = too >>>> detailed already), but I suggest to add the following to section 4: >>>>=20 >>>> "Valid Pair: A candidate pair whose local candidate equals the >>>> mapped address of the connectivity check response, >>>> and whose remote candidate equals the destination address to >>>> which the connectivity check request was sent.=E2=80=9D >>>=20 >>> Also WFM. >>>=20 >>>>=20 >>>>=20 >>>> Related to this, I note that the document uses both =C2=B3valid = pair=C2=B2 and >>>> =C2=B3valid candidate pair=C2=B2 terminology. Perhaps it=C2=B9s = enough to say >>>> =C2=B3valid pair=C2=B2 everywhere. >>>>=20 >>>> Related to this, there is a bug in section 2.3. The text shall say: >>>>=20 >>>> "For each component of a data stream, the controlling agent >>>> nominates a valid pair from >>>> the valid list to be used for data.=E2=80=9D >>>=20 >>> I=E2=80=99m okay either way. (While I usually prefer consistency, I = imagine >>> that people can figure this one out.) >>=20 >> This is one of the things I always check when I do GenArt reviews :) >>=20 >> I had a look, and there weren=E2=80=99t too many instances of = =E2=80=9Cvalid candidate >> pair=E2=80=9D, so I changed them to =E2=80=9Cvalid pair=E2=80=9D in = order to align. >>=20 >> I implemented the changes in the PR. >>=20 >>=20 >> --- >>=20 >>>>=20 >>>>> -4: There are at least a few uses of lower case =C2=B3must=C2=B2 = and =C2=B3should=C2=B2 >>>>> that do not appear to have been intended as keywords. If that is >>>>> the intent, please update this to use the boilerplate from 8174. >>>>> (The 2119 boilerplate is ambiguous on whether lower case instances >>>>> count as >>>>> keywords.) >>>>=20 >>>>=20 >>>> I suggest we keep the 2119 boilerplate, but I will go through the >>>> lower case instances and see whether they should be capitalized. >>>=20 >>> Okay, although if you keep 2119, it might be better to change any >>> that should remain non-capitalized to non-colliding terms. >>=20 >> I had a look. In most cases I could change to a non-colliding terms, >> and in 1-2 cases I changed to upper case. >>=20 >> I implemented the changes in the PR. >>=20 >> =E2=80=94 >>=20 >>>>> -12.3: =C2=B3 As discussed below, ICE agents are encouraged to = re-adjust >>>>> jitter buffers=C5=A0=C2=B2 Please cite the specific section(s). >>>>=20 >>>> I actually suggest to remove section 12.3. It is about receiving >>>> data, and the content is covered in section 13. >>>>=20 >>>> I also suggest to change section 12.3 to 12.2.1, as the text is = only >>>> about sending media. >>>>=20 >>>> I also suggest to change section 13 to 12.3. It was always intended >>>> to be a subsection to section 12. >>>=20 >>> No objection, but that goes beyond the scope of my comment :-) >>>=20 >>> (Normally I discourage lots of reorganization in bis drafts because >>> it makes them harder to review against the original. But this is >>> already enough of a re-write that this change would make little >>> incremental >>> difference.) >>=20 >> Also note that =E2=80=9CReceiving media=E2=80=9D (section 13 in bis) = was a subsection >> in RFC 5245, so the 13->12.3 change will actually align the bis with >> the RFC >> :) >>=20 >> =E2=80=94 >>=20 >>>>=20 >>>>> -17.2, last bullet: Why call out viruses specifically? It seems >>>>> like there are a lot of ways a server might be compromised that do >>>>> not involve viruses per se. (Same in 17.3). >>>>=20 >>>> My only answer is that this is text from RFC 5245. >>>> I can remove =C2=B3virus=C2=B2, and simply say: >>>>=20 >>>> "An attacker can compromise a STUN server, and cause it to send >>>> responses with incorrect mapped addresses.=C2=B2 (17.2) >>>>=20 >>>>=20 >>>> =C5=A0and: >>>>=20 >>>> "However, TURN servers are susceptible to DNS attacks for purposes >>>> of turning it into a zombie or rogue server.=E2=80=9D >>>=20 >>> Okay. On reflection, I=E2=80=99m also okay leaving things as is in = deference >>> to 5245. >>=20 >> I already removed it in the PR, so if you are ok with that I won=E2=80=99= t put >> it back :) >>=20 >> --- >>=20 >>>>=20 >>>>> -17.4.1: Since the description of the voice hammer attack has been >>>>> removed, can you cite something that does describe it? (Appendix A >>>>> still refers to section 17 to describe the voice hammer attack.) >>>>=20 >>>> I didn=C2=B9t really find a good citation, but maybe something = like: >>>>=20 >>>> "The STUN amplification attack is similar to a voice hammer attack, >>>> where the attacker causes other agents to direct media traffic >>>> towards the attack target.=E2=80=9D >>>>=20 >>>=20 >>> WFM. Perhaps put =E2=80=9Cvoice hammer=E2=80=9D in quotes? >>=20 >> I will fix that. >>=20 >> --- >>=20 >>>>=20 >>>>> -22: Did you consider making this section an appendix? >>>>=20 >>>> I don=C2=B9t remember. I have no problem doing that, if you think = an >>>> appendix would be better. >>>=20 >>> On reflection, don=E2=80=99t worry about it. >>=20 >> Ok, I=E2=80=99ll keep it. >>=20 >> Updated PR: >>=20 >> https://github.com/ice-wg/rfc5245bis/pull/55 >>=20 >>=20 >> Regards, >>=20 >> Christer >>=20 >=20 --Apple-Mail=_F8834D16-571E-4FE8-9982-5ECA18DEFC18 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpWeZ0ACgkQgFZKbJXz 1A2/kxAAz9RiBfz/NBmTIVymr6fRRH5KqCTBY4EmZR3005vy1KX65USYFb76niia rhSrv8CKey7V0y5cPY/prAue5OeEERUOsj+7DZvJQYKb9GCEptsf0RDyGFCCcqZl FV9SGKpKp8z6B6FZLjw+z79HnxgoNWzb2GU7XX9xaI/rKEgzlAiyy+slugKzpkSO srFh8JliiSf4GbbGiKDtf8hdCJcAmYyJY9RD4eiMH4nnZJk+qVAMoDWgtlC+mtui 8aryWYBCp/Ue1pfxsAO29rufgIrD4xYXtprcmW4z+Z/nqNhZdGqwz493q/0tDpge c0Fkp5qu8z6PhH0Mr2ZVRiZva5V5EbY7ifOWa3H6Zr/GS185bdOgmx59hoUbAci0 RSqHtuR6PT05Lt0GCxVCWU8XiqCdtW509tsaZUYTVIdLgn/ni7sWc67DVC0EyFFE 6coMHW3+hO8zsb5+QsNfQK1AHlw20WSJqOK5jP2iq2eSfHn4Ax3/zswmBMSmUP5k n9j5TkrmAe3qFl578n+wlO3ARyJudKU3bLIJh7GRb5MAcfSooLxQPOTrPnG37kUs cs/8QiJsBtBWlVdGpf946Zc1aSdVlemzPTHn/lhuew65qRr7v9SIQH2R/jsMmwpU y+CXilrpoVXs9SQzvPtvW1vDIXjacHr7ziax8iVlYQ+KykJZ2Y4= =REOx -----END PGP SIGNATURE----- --Apple-Mail=_F8834D16-571E-4FE8-9982-5ECA18DEFC18-- From nobody Wed Jan 10 23:27:38 2018 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6A312EA59; Wed, 10 Jan 2018 23:27:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151565565675.24674.14497093033196509234@ietfa.amsl.com> Date: Wed, 10 Jan 2018 23:27:36 -0800 Archived-At: Subject: [Ice] I-D Action: draft-ietf-ice-rfc5245bis-16.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 07:27:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interactive Connectivity Establishment WG of the IETF. Title : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal Authors : Ari Keranen Christer Holmberg Jonathan Rosenberg Filename : draft-ietf-ice-rfc5245bis-16.txt Pages : 93 Date : 2018-01-10 Abstract: This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). This document obsoletes RFC 5245. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-16 https://datatracker.ietf.org/doc/html/draft-ietf-ice-rfc5245bis-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-rfc5245bis-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 10 23:29:35 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71C112EA91; Wed, 10 Jan 2018 23:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDJN5cmejoPo; Wed, 10 Jan 2018 23:29:25 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1CB12EA90; Wed, 10 Jan 2018 23:29:24 -0800 (PST) X-AuditID: c1b4fb2d-b35ff70000007932-bc-5a5712522f09 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9D.A4.31026.252175A5; Thu, 11 Jan 2018 08:29:23 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Thu, 11 Jan 2018 08:29:22 +0100 From: Christer Holmberg To: "ice@ietf.org" CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" Thread-Topic: Draft new version: ICEbis-16 Thread-Index: AQHTiq3mpDGrOLVPbUKC7dmZ2ePlWg== Date: Thu, 11 Jan 2018 07:29:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D67CE17228C78christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbE9UDdYKDzK4PFTZovjP/6wW3y7UOvA 5LFkyU+mAMYoLpuU1JzMstQifbsEroxNDz8wFaznqFg9t5utgXEFexcjJ4eEgInE9jVHWLsY uTiEBA4zSqxZfIsFwlnCKHGp8yZTFyMHB5uAhUT3P22QBhEBRYmZLc+YQWxmgXCJpyfns4LY wgKqEr0be9ggarQkvr79zwJh60m8nPcVbAwLUM3nSbkgYV4Ba4ljHR/AShgFxCS+n1rDBDFS XOLWk/lMELcJSCzZc54ZwhaVePn4H9gqUaCRG07cZgcZKSGgJDFtaxpEa4LEjB+/GCHGC0qc nPmEZQKj8CwkU2chKZuFpAwibiDx/tx8ZghbW2LZwtdQtr7Exi9nGSFsa4nP3V9ZkNUsYORY xShanFpcnJtuZKyXWpSZXFycn6eXl1qyiREYRwe3/Nbdwbj6teMhRgEORiUe3jlc4VFCrIll xZW5hxglOJiVRHgXB4ZFCfGmJFZWpRblxxeV5qQWH2KU5mBREuc96ckbJSSQnliSmp2aWpBa BJNl4uCUamBsj4g9+bgqoOTrJ9mVN9/oyadtjejzWF9078hCmW0OLqKryo9MfD1Xcv3dqwuv 6R7e1fPhyRWXqrnHK+e+q2pg59dIu/zA8Zjo7r1y/1Pa2P7X/LItcn5m0aVqtPWsQ5RPV7SF CmeWtLb/rzIP/4164vERrRlH9jVsPjSzUK5ym9EkHqe1B2WVWIozEg21mIuKEwGkGZv2nwIA AA== Archived-At: Subject: [Ice] Draft new version: ICEbis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 07:29:27 -0000 --_000_D67CE17228C78christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Based on Ben=92s AD review comments, I have submitted a new version (-16) o= f draft-5245bis. Regards, Christer --_000_D67CE17228C78christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2755E96CB43DD0498D6AA38FC850DA1F@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Based on Ben=92s AD review comments, I have submitted a new version (-= 16) of draft-5245bis.

Regards,

Christer
--_000_D67CE17228C78christerholmbergericssoncom_-- From nobody Thu Jan 11 21:26:10 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661C112D96C; Thu, 11 Jan 2018 21:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZT1a9y40X_77; Thu, 11 Jan 2018 21:26:06 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75DB912D96B; Thu, 11 Jan 2018 21:26:06 -0800 (PST) Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0C5Q1h9074188 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 Jan 2018 23:26:02 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105] From: Ben Campbell Message-Id: <0FF99E4A-D643-4A26-98CB-BC2FD6802C60@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_8E58FBFB-4BBB-4ADE-96E3-5AC08DCDA906"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 11 Jan 2018 23:26:00 -0600 In-Reply-To: Cc: "ice@ietf.org" , "draft-ietf-ice-rfc5245bis.all@ietf.org" To: Christer Holmberg References: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ice] Draft new version: ICEbis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 05:26:08 -0000 --Apple-Mail=_8E58FBFB-4BBB-4ADE-96E3-5AC08DCDA906 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think this version is ready for IETF LC. I will request that shortly. Peter (as shepherd): The shepherd=E2=80=99s report says there are no = downrefs, but there is in fact a normative downref to RFC6928 = (experimental.) Please update the shepherd report to reflect that. Thanks! Ben. > On Jan 11, 2018, at 1:29 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 > Based on Ben=E2=80=99s AD review comments, I have submitted a new = version (-16) of draft-5245bis. >=20 > Regards, >=20 > Christer --Apple-Mail=_8E58FBFB-4BBB-4ADE-96E3-5AC08DCDA906 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpYRugACgkQgFZKbJXz 1A12SxAAjsN2qmlQxtDquZ9YpCuME+frTZrZidNLhi3IVq/OilSIyYkV/2i/MYBB 3fa7JMj0jP+SC/R1RnxsIo38c+j3Avfy1sogFatHj8i0mVya+wlTiyp3qlmQLnXE rT00sPNp9BQLvzB4vqLxCHty3s2qV9zow842uYjdHZiUQX/9yYbVNLRfojLzw6bQ cqOhLbMj5Jvv0d+VAIswQWwlQkWz8OTBbyJt9W7/tf3h9XF4rxpGKvoEWnORT5lR 5n4eHN7JiRNVSPQpaLJ1u3LaSqp6XB7Mynh9D40dwcvXhgX7bxBISc3F39LRsOex 01HLmsoIak7I56dSgWP2sA97mVGSuG3IibuOTX2ZcL4JRyrPuDn3Gl86IuTQuXvt PuSyyPkRRXRI7e5vFkRAW4NSNYZxUoLwi5xtS5CHFHDgXfpM0+wVHR4xd5qDomcV beFY2PCsmNHX9NW/YKxjNAMetOHryYIV5I3MPwC+jvF4iVFqRO8oaH4SBheHRdb+ 52rFoZfKqeLQZXHaZs8M8fXuXLg8allPWN4xyOrhAgoLuj/1Jj2EVuAzKq06B5ft 0VsEYUWcN6hnD4Tru7H0XWldggDXZNHldy83HV+nkAuXLhIOGSiNJMm4LKYN5zo6 niw1zLLO/XQSD4+iznHgn5pzxdUETIxMyDiRwKFvE+dD8zCGSYU= =BjEr -----END PGP SIGNATURE----- --Apple-Mail=_8E58FBFB-4BBB-4ADE-96E3-5AC08DCDA906-- From nobody Fri Jan 12 06:21:40 2018 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E86E12E04D; Fri, 12 Jan 2018 06:21:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk CC: ben@nostrum.com, ice-chairs@ietf.org, ice@ietf.org, draft-ietf-ice-rfc5245bis@ietf.org, pthatcher@google.com, Peter Thatcher Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151576689534.18609.12559649596799686089.idtracker@ietfa.amsl.com> Date: Fri, 12 Jan 2018 06:21:35 -0800 Archived-At: Subject: [Ice] Last Call: (Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal) to Proposed Standard X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 14:21:35 -0000 The IESG has received a request from the Interactive Connectivity Establishment WG (ice) to consider the following document: - 'Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-01-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). This document obsoletes RFC 5245. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3115/ The document contains these normative downward references. See RFC 3967 for additional information: rfc6928: Increasing TCP's Initial Window (Experimental - IETF stream) From nobody Fri Jan 12 13:58:40 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A24612D863 for ; Fri, 12 Jan 2018 13:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITAP2ZgSgGV4 for ; Fri, 12 Jan 2018 13:58:27 -0800 (PST) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1CE112D830 for ; Fri, 12 Jan 2018 13:58:26 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id e41so6153386wre.9 for ; Fri, 12 Jan 2018 13:58:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z8kQGlfDyvOpkEa1q1APQkcWSowX1s8tRvmZBrwfrCE=; b=GIk3itXD2X5SwLS2Vc6wN7aq3ZlhdIuSX81c2atrMA+fvQvYPlTa6WND2FaYn4Z5/G iMBx7NS2PK18RY0aUS8fIoU5ccquHNind1xnmi+xC39F5DtNWvgJ7JDlyzqsitaSXJ2k IVDcozigf43UT6bW7/XCLgzOwPMm39PDbubFrvLSES7LyZeYFFE4zJvEVBAjuUdg+8I0 6vMBssTeWyB6mGjgxUDcTHIyvyJWRNEFg2bl9bJhg7ss2TvOCbE66MXYZzCJd8G66Lgs UfHUoxzRqiEEh82MOGVfI5ZwXvWBqyY4/c9by9h2ELISc7J3kZdRsIeZSREGf1JEHmmY gfXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z8kQGlfDyvOpkEa1q1APQkcWSowX1s8tRvmZBrwfrCE=; b=ZRz5KD75gO1dWBZa+PfLsuEN/BZrsX/zn03jkG0xu8s76LV93qyTxsKBUM7MBFRTN2 jMOugGy/LVk+qAmN/RtRJsU7WkSFu2qhHjnGV3PijOnNqo+z1/EUEfEeALxOO+2B1V10 4tdN3qaXNTNX8CnoiPdbPse16IskaWzThnVKX04zBu5tAf8K39RIdZe4Fm+hg/fYk4FZ BNV29vOV7l5hMpsu4HhLUrN05Oq7FFI1fjGxJ3NUCMJpH5W6ZdOVil/AK8doobW9dFel aFfviTVzl2iKAPJ/nJ4k7d0DE+vLVeOXx1iXmU5UN1x8aPsxUfkqmm92xTQm2qVrd79v S97w== X-Gm-Message-State: AKGB3mK1aMKCa2AUVoqSlZ+XS8BJwxrWHnuzvBYNuatPgDoZsDV7e3WR 0NO95lqCxa5oqC6tuPZno4PaPK7p0Y8q5t5xBNUHv+Et X-Google-Smtp-Source: ACJfBosztgUND1NE3TSwopg+4TKQqoVU8TwfgAh7TRYFFioHM3rQF+1Rwg3F+IcmLwQAepiysfAbDJuGOs4OUK7TeA4= X-Received: by 10.223.169.163 with SMTP id b32mr22968260wrd.208.1515794304998; Fri, 12 Jan 2018 13:58:24 -0800 (PST) MIME-Version: 1.0 References: <0FF99E4A-D643-4A26-98CB-BC2FD6802C60@nostrum.com> In-Reply-To: <0FF99E4A-D643-4A26-98CB-BC2FD6802C60@nostrum.com> From: Peter Thatcher Date: Fri, 12 Jan 2018 21:58:14 +0000 Message-ID: To: Ben Campbell Cc: Christer Holmberg , "ice@ietf.org" , "draft-ietf-ice-rfc5245bis.all@ietf.org" Content-Type: multipart/alternative; boundary="001a113c58301abc5405629b5d65" Archived-At: Subject: Re: [Ice] Draft new version: ICEbis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 21:58:31 -0000 --001a113c58301abc5405629b5d65 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There are some typos I found in reviewing https://github.com/ice-wg/rfc5245bis/pull/55 that I hope will be fixed. Is it OK to go to the IETF LC without those fixes? The publication request has been updated with the downref to 6928. On Thu, Jan 11, 2018 at 9:26 PM Ben Campbell wrote: > I think this version is ready for IETF LC. I will request that shortly. > > Peter (as shepherd): The shepherd=E2=80=99s report says there are no down= refs, but > there is in fact a normative downref to RFC6928 (experimental.) Please > update the shepherd report to reflect that. > > Thanks! > > Ben. > > > On Jan 11, 2018, at 1:29 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > > Hi, > > > > Based on Ben=E2=80=99s AD review comments, I have submitted a new versi= on (-16) > of draft-5245bis. > > > > Regards, > > > > Christer > > --001a113c58301abc5405629b5d65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There are some typos I found in reviewing=C2=A0https://github.com/ice-wg/rfc= 5245bis/pull/55=C2=A0that I hope will be fixed.=C2=A0 Is it OK to go to= the IETF LC without those fixes?

The publication reques= t has been updated with the downref to 6928.

=
On Thu, Jan 11, 2018 at 9:2= 6 PM Ben Campbell <ben@nostrum.com> wrote:
I think this version i= s ready for IETF LC. I will request that shortly.

Peter (as shepherd): The shepherd=E2=80=99s report says there are no downre= fs, but there is in fact a normative downref to RFC6928 (experimental.) Ple= ase update the shepherd report to reflect that.

Thanks!

Ben.

> On Jan 11, 2018, at 1:29 AM, Christer Holmberg <christer.holmberg@ericsson= .com> wrote:
>
> Hi,
>
> Based on Ben=E2=80=99s AD review comments, I have submitted a new vers= ion (-16) of draft-5245bis.
>
> Regards,
>
> Christer

--001a113c58301abc5405629b5d65-- From nobody Fri Jan 12 21:19:08 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67486124F57; Fri, 12 Jan 2018 21:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZuirR3HdjJL; Fri, 12 Jan 2018 21:19:04 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B6C1241F3; Fri, 12 Jan 2018 21:19:04 -0800 (PST) Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0D5IvB4034852 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 12 Jan 2018 23:18:58 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105] From: Ben Campbell Message-Id: <71004A2D-98AB-4304-B86A-3B8CB8BB8FB8@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_BFA42C80-6E2E-47A6-B45E-3B6150E807B1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 12 Jan 2018 23:17:42 -0600 In-Reply-To: Cc: Christer Holmberg , "ice@ietf.org" , "draft-ietf-ice-rfc5245bis.all@ietf.org" To: Peter Thatcher References: <0FF99E4A-D643-4A26-98CB-BC2FD6802C60@nostrum.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ice] Draft new version: ICEbis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 05:19:06 -0000 --Apple-Mail=_BFA42C80-6E2E-47A6-B45E-3B6150E807B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 12, 2018, at 3:58 PM, Peter Thatcher = wrote: >=20 > There are some typos I found in reviewing = https://github.com/ice-wg/rfc5245bis/pull/55 that I hope will be fixed. = Is it OK to go to the IETF LC without those fixes? Yes, we can treat those as IETF LC feedback. >=20 > The publication request has been updated with the downref to 6928. Thanks! >=20 >=20 > On Thu, Jan 11, 2018 at 9:26 PM Ben Campbell wrote: > I think this version is ready for IETF LC. I will request that = shortly. >=20 > Peter (as shepherd): The shepherd=E2=80=99s report says there are no = downrefs, but there is in fact a normative downref to RFC6928 = (experimental.) Please update the shepherd report to reflect that. >=20 > Thanks! >=20 > Ben. >=20 > > On Jan 11, 2018, at 1:29 AM, Christer Holmberg = wrote: > > > > Hi, > > > > Based on Ben=E2=80=99s AD review comments, I have submitted a new = version (-16) of draft-5245bis. > > > > Regards, > > > > Christer >=20 --Apple-Mail=_BFA42C80-6E2E-47A6-B45E-3B6150E807B1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpZlnYACgkQgFZKbJXz 1A30URAAr91p9CIBxJwfjqSC2zJrt6II6w/Zmyobc63MyyJnQW6DhMNeh5M/yL2z BTAFGKABYngklTZJlTiUkuUelPDycoRk2fPMrB6aASrLlw1q0rRjHeAKCPr5G0rO h0km3RH7IhvvENiPCG5+aSqMauXGc2VUkupKMaGR1a45HbcAyUL9UeRv3e3Sq/m8 j5gqjeR99sGcR2j1iirhnsEGv3ZZJKhuBE+gv2HIRvabzIxZlZsMNL5SZRGbqdbK nE/IAlsxCm3qcLijxtVEy0LLWimRPLBNCjwWlIgF3OKhBKDwR6z1/BP1hW+YBuZD UWV5VLyQ9dG+KW1RGGUJXr/vS6DvPd34JdVg7kaKZ14fm/o08PizJLzc+5knnFpF 3KdrzJrx6DgMHAWatXctLUz1udGWiVDh5AxDmBjm4CX7myd+hYF791PKppnQdgXp B7dKJl770wU78J38a3d5LFwWRY55P57sqN207XBk6TNetEs1+mMkQgIyTexT1YZk FSU7Dmpnaxyp4pq2XHvtO0BIBFPNN32sTptsMTCEsJzbQIOrLaC16/fe1lL68/H3 S+J02/Z76Zn1b2nSXWrM70Dv4SdSB3Aru8Nd3QCKlsRSpucRDvT8xaPj4i2+VsmA /RE/THi0Ngyav7Afww34HANXfpJFKZg+u4Un8yNR0Ha5rwArbhQ= =jXO0 -----END PGP SIGNATURE----- --Apple-Mail=_BFA42C80-6E2E-47A6-B45E-3B6150E807B1-- From nobody Sat Jan 13 01:06:56 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849171242F5; Sat, 13 Jan 2018 01:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLoqNpXW628J; Sat, 13 Jan 2018 01:06:53 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53307124239; Sat, 13 Jan 2018 01:06:53 -0800 (PST) X-AuditID: c1b4fb3a-34dff700000037f2-60-5a59cc2bc431 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 39.65.14322.B2CC95A5; Sat, 13 Jan 2018 10:06:51 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0352.000; Sat, 13 Jan 2018 10:06:50 +0100 From: Christer Holmberg To: Ben Campbell , Peter Thatcher CC: "ice@ietf.org" , "draft-ietf-ice-rfc5245bis.all@ietf.org" Thread-Topic: Draft new version: ICEbis-16 Thread-Index: AQHTiq3mpDGrOLVPbUKC7dmZ2ePlWqNvpYoAgAEVOgCAAHrJAIAAUGpA Date: Sat, 13 Jan 2018 09:06:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C109C51@ESESSMB109.ericsson.se> References: <0FF99E4A-D643-4A26-98CB-BC2FD6802C60@nostrum.com> <71004A2D-98AB-4304-B86A-3B8CB8BB8FB8@nostrum.com> In-Reply-To: <71004A2D-98AB-4304-B86A-3B8CB8BB8FB8@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbHdQ1f7TGSUwfnN0hbzO0+zWxz/8Yfd 4tuFWotry1+zOrB4LNhU6rFkyU8mj1k7n7AEMEdx2aSk5mSWpRbp2yVwZew6s4S14IxARUtP VQPjFIEuRg4OCQETiTuv8rsYuTiEBA4zSpzYd50FwlnCKHF02UxWkCI2AQuJ7n/aXYycHCIC nhLrO68wgoSZBcokZsxmBgkLC2hKrNyznR2iREvi69v/LBC2m8S/2zsZQWwWAVWJac0n2EBs XgFfiVvLpjNCrHrDKPHy7gqwZk4Be4lTn6+ADWUUEJP4fmoNE4jNLCAucevJfDBbQkBAYsme 88wQtqjEy8f/WCFsJYlFtz8zQdymKbF+lz5Eq6LElO6H7BB7BSVOznzCMoFRdBaSqbMQOmYh 6ZiFpGMBI8sqRtHi1OLi3HQjI73Uoszk4uL8PL281JJNjMDIObjlt9UOxoPPHQ8xCnAwKvHw Fh2JjBJiTSwrrsw9xCjBwawkwht2OiJKiDclsbIqtSg/vqg0J7X4EKM0B4uSOK9TmkWUkEB6 YklqdmpqQWoRTJaJg1OqgXEx55S6qX/+bjexKtZikl296fXN6k1WPim3z8+cV7PNotLT+LdG xq8s/is3ly7eVc8sYHQm9sXqwyI7VVMlY6ZJHfn/8kDGa3mNR8nLo5/l/ypvLbLOWxv1W9vO y9S0cvmrTV7PX1/a/c3kU7xBr9GkKVf+2k5dNo2hopNT/9CnP4kr9s3/s+aJEktxRqKhFnNR cSIA0swQKJgCAAA= Archived-At: Subject: Re: [Ice] Draft new version: ICEbis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 09:06:55 -0000 SGksDQoNCkkgaGF2ZSBhbHNvIGZvdW5kIGEgY291cGxlIG9mIGVkaXRvcmlhbCBuaXRzLCBidXQg SSB3aWxsIGZpeCB0aGVtIGFzIHBhcnQgb2YgdGhlIElFVEYgTEMgZml4ZXMuDQoNCkkgd2lsbCBj cmVhdGUgR2l0SHViIGlzc3Vlcy9QUnMgYXNhcCwgdGhvdWdoLCBzbyBhbnlvbmUgY2FuIHNlZSB3 aGF0IHRob3NlIGlzc3VlcyBhcmUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCZW4gQ2FtcGJlbGwgW21haWx0bzpiZW5Abm9zdHJ1 bS5jb21dIA0KU2VudDogMTMgSmFudWFyeSAyMDE4IDA3OjE4DQpUbzogUGV0ZXIgVGhhdGNoZXIg PHB0aGF0Y2hlckBnb29nbGUuY29tPg0KQ2M6IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20+OyBpY2VAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaWNlLXJmYzUy NDViaXMuYWxsQGlldGYub3JnDQpTdWJqZWN0OiBSZTogRHJhZnQgbmV3IHZlcnNpb246IElDRWJp cy0xNg0KDQoNCg0KPiBPbiBKYW4gMTIsIDIwMTgsIGF0IDM6NTggUE0sIFBldGVyIFRoYXRjaGVy IDxwdGhhdGNoZXJAZ29vZ2xlLmNvbT4gd3JvdGU6DQo+IA0KPiBUaGVyZSBhcmUgc29tZSB0eXBv cyBJIGZvdW5kIGluIHJldmlld2luZyBodHRwczovL2dpdGh1Yi5jb20vaWNlLXdnL3JmYzUyNDVi aXMvcHVsbC81NSB0aGF0IEkgaG9wZSB3aWxsIGJlIGZpeGVkLiAgSXMgaXQgT0sgdG8gZ28gdG8g dGhlIElFVEYgTEMgd2l0aG91dCB0aG9zZSBmaXhlcz8NCg0KWWVzLCB3ZSBjYW4gdHJlYXQgdGhv c2UgYXMgSUVURiBMQyBmZWVkYmFjay4NCg0KPiANCj4gVGhlIHB1YmxpY2F0aW9uIHJlcXVlc3Qg aGFzIGJlZW4gdXBkYXRlZCB3aXRoIHRoZSBkb3ducmVmIHRvIDY5MjguDQoNClRoYW5rcyENCg0K PiANCj4gDQo+IE9uIFRodSwgSmFuIDExLCAyMDE4IGF0IDk6MjYgUE0gQmVuIENhbXBiZWxsIDxi ZW5Abm9zdHJ1bS5jb20+IHdyb3RlOg0KPiBJIHRoaW5rIHRoaXMgdmVyc2lvbiBpcyByZWFkeSBm b3IgSUVURiBMQy4gSSB3aWxsIHJlcXVlc3QgdGhhdCBzaG9ydGx5Lg0KPiANCj4gUGV0ZXIgKGFz IHNoZXBoZXJkKTogVGhlIHNoZXBoZXJk4oCZcyByZXBvcnQgc2F5cyB0aGVyZSBhcmUgbm8gZG93 bnJlZnMsIGJ1dCB0aGVyZSBpcyBpbiBmYWN0IGEgbm9ybWF0aXZlIGRvd25yZWYgdG8gUkZDNjky OCAoZXhwZXJpbWVudGFsLikgUGxlYXNlIHVwZGF0ZSB0aGUgc2hlcGhlcmQgcmVwb3J0IHRvIHJl ZmxlY3QgdGhhdC4NCj4gDQo+IFRoYW5rcyENCj4gDQo+IEJlbi4NCj4gDQo+ID4gT24gSmFuIDEx LCAyMDE4LCBhdCAxOjI5IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4gQmFzZWQgb24gQmVu 4oCZcyBBRCByZXZpZXcgY29tbWVudHMsIEkgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiAo LTE2KSBvZiBkcmFmdC01MjQ1YmlzLg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPg0KPiA+IENocmlz dGVyDQo+IA0KDQo= From nobody Fri Jan 19 16:01:52 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3C912D962 for ; Fri, 19 Jan 2018 16:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUVyA_00Xe6z for ; Fri, 19 Jan 2018 16:01:50 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8884912E057 for ; Fri, 19 Jan 2018 16:01:49 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id b141so6396576wme.1 for ; Fri, 19 Jan 2018 16:01:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=pt8UmIs43auOKyS4eWYSXHNZ1fAfzwohvm/AdwRwVKo=; b=JtaaIPIgQwft1+wjvRyIkrFnyGwPtuA7iPKa6UhgvH+cLHfIma92qw3MgjlTwgQc3q IInvPhP7z0NAsr5E7c25vgFvufMVHRJu8w6kJADap7SNQ8p1NijGtarI5Bw9JV0x7RHJ Hbd51C1J1P9jEkqP++dG+6lBxVwehRa7P3qB6UQVbxHCO1vzxVa8z2sdUmN/jio8WA0A efezWr65A1matZjX5+RnOa0tqUyD6r3l/2monu3FNpcUXIhcDBWzmk7gmxPFlBCPnWOu Ja2iSD+eTIiPIxP5yWZanN2NJu93HpnLIRkCPaJ6F4sKQLXmEYJsS//QWfM3+BFxVFEI UBFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pt8UmIs43auOKyS4eWYSXHNZ1fAfzwohvm/AdwRwVKo=; b=G9RcLtcvNp2RrhyLCtREVF/euZXNz3h+bTkbhD0VsTPckMA3V/uAq/abUW+mSHW72Z H3CaouPAZ2gb6DXmd9Y//lOIAQv7ptB2522a1Jm62K6DWA3g+GRjwNp77uEDbHuDy4YZ Ynz7fgTUxKRUrlLQvtQckHWPIL6RTqGpezwPqbO/driBr30B9ryw1UCNGCZ5lD1iTeTr mWE+lO59w8yS0HpJ4R3JyEVc4n540cbLbHVyMMFq+U1yUgcNHYxV89sbyyzMwrvA1UAd tlSs97wj65quXfJfsS0Cxl07G4JxqhVrVYP1E8zCZfzF75rYNQu8B/powy3LlMIy1ISB /iBQ== X-Gm-Message-State: AKwxyte8x8oBmha/IZs/u+lXbitAcWZsW0We0eEVYCwhjV3+mTp2kQHt Y3ExR02hWZfqMVcCwNbVSMn6oyUg8Fp80sVCZU2VOKwO X-Google-Smtp-Source: AH8x227X5VxVM6hkg7YOOc+OhX8A1mPpgJRmugq+k4PkLnEQPMgm3erzP+ngPRnjDx+zTDibpGKTAEFEw7g0aTrFfaw= X-Received: by 10.28.222.5 with SMTP id v5mr387078wmg.161.1516406507596; Fri, 19 Jan 2018 16:01:47 -0800 (PST) MIME-Version: 1.0 From: Peter Thatcher Date: Sat, 20 Jan 2018 00:01:35 +0000 Message-ID: To: ICE WG Content-Type: multipart/alternative; boundary="001a114b15e6390df9056329e743" Archived-At: Subject: [Ice] No ICE meeting in London? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2018 00:01:52 -0000 --001a114b15e6390df9056329e743 Content-Type: text/plain; charset="UTF-8" We don't see anything that would go on the agenda for a meeting in London, so we are currently not planning a meeting in London. If you have anything that they would like to meet about and add to the agenda, please let it be known now. Thanks, The ICE WG chairs --001a114b15e6390df9056329e743 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We don't see anything that would go on the agenda for = a meeting in London, so we are currently not planning a meeting in London.<= div>
If you have anything that they would like to meet about = and add to the agenda, please let it be known now.

=
Thanks,
The ICE WG chairs
--001a114b15e6390df9056329e743-- From nobody Wed Jan 24 11:15:19 2018 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59997127601; Wed, 24 Jan 2018 11:15:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Ari_Ker=C3=A4nen?= To: X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Cc: nohlmeier@mozilla.com, ice-chairs@ietf.org, Nils Ohlmeier , iesg-secretary@ietf.org, ice@ietf.org Message-ID: <151682131730.22693.6816710337922881618.idtracker@ietfa.amsl.com> Date: Wed, 24 Jan 2018 11:15:17 -0800 Archived-At: Subject: [Ice] Publication has been requested for draft-ietf-ice-trickle-15 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 19:15:17 -0000 Ari Keränen has requested publication of draft-ietf-ice-trickle-15 as Proposed Standard on behalf of the ICE working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ From nobody Thu Jan 25 13:56:47 2018 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D51F127522; Thu, 25 Jan 2018 13:56:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stewart Bryant To: Cc: draft-ietf-ice-rfc5245bis.all@ietf.org, ietf@ietf.org, ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151691740516.8342.10156383952294498449@ietfa.amsl.com> Date: Thu, 25 Jan 2018 13:56:45 -0800 Archived-At: Subject: [Ice] Genart last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 21:56:45 -0000 Reviewer: Stewart Bryant Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ice-rfc5245bis-16 Reviewer: Stewart Bryant Review Date: 2018-01-25 IETF LC End Date: 2018-01-26 IESG Telechat date: Not scheduled for a telechat Summary: This is a well written document and I am sure it will serve its target audience well. However Genart reviews take the perspective of someone new to the field, and although I am sure it is probably correct and complete when taken together with its references the learning curve is perhaps a little steeper than it needs to be due to the extent of assumed knowledge. In the nits section of this review I make a few simple suggestions that I think would make it easier for the new reader. Major issues: None Minor issues: None Nits/editorial comments: "in the XOR-RELAYED-ADDRESS attribute. " SB> As far as I can see this not yet been defined or a reference provided in the document. The table in Figure 8 illustrates an example. SB> There is something wierd going on here. SB> Figure 8 seems malformed possibly spread over a page break. SB> You introduce Ta, but it would be so much kinder to the reader to give it a real name. SB> DSCP is not well known so needs to defined SB> You introduce FINGERPRINT without a pointer to where it is defined SB> The 487 error comes out of a hat without a pointer to where it is defined SB> ICE-CONTROLLED comes out of the same hat without a pointer/definition, same with PRIORITY, MESSAGE-INTEGRITY, ALTERNATE-SERVER, XOR_MAPPED_ADDRESS, USE-CANDIDATE, CHECK-LIST Section 7.3.1.4, the agent sets the nominated flag of the pair to SB> should that be nominated or NOMINATED? In section 8.3.1 it says: " The procedures in Section 8" which is true but strangely self referencing 7.3.1.4. Triggered Checks Next, the agent constructs a pair.... SB> Next after what? and a pair of what? You say "Let HTO" again a user friendly name would be helpful to the new reader Appendix B is great, particularly from section B5 onwards. It would be great to forward reference this to help the reader understand the normative text earlier in the document. From nobody Fri Jan 26 02:33:30 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0914F12E3AE; Fri, 26 Jan 2018 02:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkQ-x7tDT_qk; Fri, 26 Jan 2018 02:33:17 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BBD912E870; Fri, 26 Jan 2018 02:33:16 -0800 (PST) X-AuditID: c1b4fb3a-335ff700000037f2-53-5a6b03ea1cab Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B2.70.14322.AE30B6A5; Fri, 26 Jan 2018 11:33:14 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0352.000; Fri, 26 Jan 2018 11:33:14 +0100 From: Christer Holmberg To: Stewart Bryant , "gen-art@ietf.org" CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" Thread-Topic: Genart last call review of draft-ietf-ice-rfc5245bis-16 Thread-Index: AQHTlidlFcjVN0hAZUOXDa/c5U88WKOFL91A Date: Fri, 26 Jan 2018 10:33:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C13FB29@ESESSMB109.ericsson.se> References: <151691740516.8342.10156383952294498449@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyM2K7me4r5uwog8+XlSyO//jDbnH11WcW i28Xai2ebZzPYnHqQaIDq8fOWXfZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbF93SPmgrdSFTuv LGJqYHwk0sXIySEhYCLx98oK1i5GLg4hgcOMEs3/WtkgnCWMElcXdTJ3MXJwsAlYSHT/0wZp EBEIk7i84TozSA2zwExGidc/XzKCJIQFXCS6fm1ihyhylbh48g+UbSSxuP8AM4jNIqAqsf3I XjYQm1fAV+Lo6nWsILaQgLPErqP/weoZBcQkvp9awwRiMwuIS9x6Mp8J4lIBiSV7zjND2KIS Lx//A+sVFdCT2HDiNjtEXFGi/WkDI0SvnsSNqVPYIGxridObHrNC2NoSyxa+Zoa4QVDi5Mwn LBMYxWYhWTcLSfssJO2zkLTPQtK+gJF1FaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgzB3c 8ttqB+PB546HGAU4GJV4eGf+yYoSYk0sK67MPcQowcGsJMIrqAsU4k1JrKxKLcqPLyrNSS0+ xCjNwaIkzuuUZhElJJCeWJKanZpakFoEk2Xi4JRqYKxnidTM874i/e2etOgidVnOxzyzb6/z OG/ud5InVKyGL+aij/S8nZOEVaJUj7q8+7Zjk1RDVs/1T00zRJ7NDGq9t/13yf3Gx3I8b5/1 xfzeIv47OHGyG/8WJtfezn5t9Y3ufQ77VXKkLuxIOP6D/XCi66PTsS9Uq4rezFqY+DJL6d/s k8Ga/EosxRmJhlrMRcWJAL9YqGG1AgAA Archived-At: Subject: Re: [Ice] Genart last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 10:33:19 -0000 Hi Stewart, Thank You for the review! Please see inline. > Summary: This is a well written document and I am sure it will serve its >target audience=20 > well. However Genart reviews take the perspective of someone new to the >field, and=20 > although I am sure it is probably correct and complete when taken >together with its > references the learning curve is perhaps a little steeper than it needs >to be due to the=20 > extent of assumed knowledge. In the nits section of this review I make a >few simple=20 > suggestions that I think would make it easier for the new reader. Thanks! :) ... Nits/editorial comments: > "in the XOR-RELAYED-ADDRESS attribute. " > >SB> As far as I can see this not yet been defined or a reference >SB> provided in the document. I will add a reference to RFC 5766. --- The table in Figure 8 illustrates an example. SB> There is something wierd going on here. SB> Figure 8 seems malformed possibly spread over a page break. I=B9ll check that. --- > SB> You introduce Ta, but it would be so much kinder to the reader to > SB> give it a real name. Ta was defined in RFC 5245, and it's commonly used in ICE-related discussions, so I think it would cause confusion to change the name at this point. --- > SB> DSCP is not well known so needs to defined I will expand to "DiffServe Codepoint", and add a reference to RFC 2474, on first occurrence. --- SB> You introduce FINGERPRINT without a pointer to where it is defined I will add a reference to RFC 5389 on first occurrence. --- SB> The 487 error comes out of a hat without a pointer to where it is SB> defined It's defined in section 16.2. I can add a reference to that section on first occurrence. --- >SB> ICE-CONTROLLED comes out of the same hat without a >SB> pointer/definition, >same >with PRIORITY, MESSAGE-INTEGRITY, ALTERNATE-SERVER, XOR_MAPPED_ADDRESS, >USE->CANDIDATE, CHECK-LIST Some are defined in section 16.1. I will a reference to that section on first occurrence. Some are defined in RFC 5389 and RFC 5766. I will add references on first occurrence. ---- >Section 7.3.1.4, the agent sets the nominated flag of the pair to >SB> should that be nominated or NOMINATED? "nominated" --- >In section 8.3.1 it says: " The procedures in Section 8" which is true >but strangely self referencing The text actually references the text later in the section :) So, I suggest to remove the first sentence: "The procedures in Section 8 require that an ICE agent continue to listen for STUN requests and continue to generate triggered checks for a data stream, even once processing for that stream completes." --- >7.3.1.4. Triggered Checks > > Next, the agent constructs a pair.... > >SB> Next after what? and a pair of what? "candidate pair" I will fix it. --- >You say "Let HTO" again a user friendly name would be helpful to the new >reader The name was provided by transport people that provided text. As it=B9s similar to RTO, I=B9d like to keep it. --- >Appendix B is great, particularly from section B5 onwards. It would be >great to forward reference this to help the reader understand the >normative text earlier in the document. Any particular place where you would like to have the reference? In the Introduction? --- Regards, Christer From nobody Fri Jan 26 02:47:23 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A57012D9FF; Fri, 26 Jan 2018 02:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVmNFVvWD72r; Fri, 26 Jan 2018 02:47:14 -0800 (PST) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6756512D779; Fri, 26 Jan 2018 02:47:14 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id s5so124514wra.0; Fri, 26 Jan 2018 02:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=i6XtA7xWmkciNDoNHtGLN1jfdhzQqVZebXTjROz9a70=; b=ZIgLiK6xrWUh9fZsQVD9BAQyp0+iRX11xOvG9FuPsbAlJ444DvJbP31ig4sRxMxUZq /eBjdA/lruII6L7AoXAgIc1x90M+XRcBTR2lPumDM5dXgngq2sfExJdruXnsAD9lKGOi OTUB/cbOpRutaba1L0mxA12FiOz7s755EBLW8zs1jQ+1UsPlF5c8ERuXWatw9gOO7ZtX WiZlOudIDAkTQQ/phoYpmQcmjshX1faV7UMpsRjzwFs7n6VPOv76CDJ95KnT0aGbkGgk gkixzPVLZLBW9FWeJKwFqAY7daOD/4/3n5Mzz9Whly2w6wLhg9d9EjbdCdtK47Wjeeme u6ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=i6XtA7xWmkciNDoNHtGLN1jfdhzQqVZebXTjROz9a70=; b=tQog6i4FJ94gjPYJd1/IEN9ZpGHjyx87WMSCJtwPsJUXxQPCToIgAvIRPwKofKrIOF +7VG0jc/CclAG/tec6iaYtFowIogJGg1PiBE2aFVbjd/4ViAG7lCkXB/KSB9DeEzHfXV qbvHk7l7AIiA+JBi56jVC+7ZpW+/QjUAD+UycFaRMsJe/bxOZOvhq47cgCgfWt3hWywW nqPAzyr/Hc993kvKuMKmyYfVqKuObkED6OvMmbT2dBW0KJ4np1uRHu8dNuzWiKZzMu4N zFMNnMddFe6vYRR8ZFX/of9+6kStd84J7t88nfeJcVFhYvv4A0wsk9s2gAsNuRS0r5fc X19Q== X-Gm-Message-State: AKwxyte38hUmKi7N9XuXkfoDXIKDYtQsxhMKLwDxyStkcu3TeOTLFtC7 n3nXnfzn+X+y/M+QTlA1ZSuZw13+ X-Google-Smtp-Source: AH8x224QIlrKZ/wCZ2/+XGWAuvqHxvaIit2DVar2fSih0M8rRNawxXOuGiRY6MMPJZvu0ixQ8GsDPg== X-Received: by 10.223.170.11 with SMTP id p11mr11214654wrd.26.1516963632748; Fri, 26 Jan 2018 02:47:12 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id 123sm3987061wmt.31.2018.01.26.02.47.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jan 2018 02:47:12 -0800 (PST) To: Christer Holmberg , "gen-art@ietf.org" Cc: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" References: <151691740516.8342.10156383952294498449@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C13FB29@ESESSMB109.ericsson.se> From: Stewart Bryant Message-ID: <2e40bec1-ce67-edd5-c2f8-73b00344e856@gmail.com> Date: Fri, 26 Jan 2018 10:47:11 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C13FB29@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [Ice] Genart last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 10:47:16 -0000 Hi Christer Thanks for your reply A few follow-up comments inline. On 26/01/2018 10:33, Christer Holmberg wrote: > > --- > >> SB> You introduce Ta, but it would be so much kinder to the reader to >> SB> give it a real name. > Ta was defined in RFC 5245, and it's commonly used in ICE-related > discussions, so I think it would cause confusion to change the name at > this point. I understand. Maybe some words to explain it a little. Perhaps "the foo timer known in this technology as Ta" of something similar. > >> You say "Let HTO" again a user friendly name would be helpful to the new >> reader > The name was provided by transport people that provided text. As it¹s > similar to RTO, I¹d like to keep it. I see what you are doing. You could however give it a name and say known as HTO. A name just makes it easier to remember what it does. > > --- > >> Appendix B is great, particularly from section B5 onwards. It would be >> great to forward reference this to help the reader understand the >> normative text earlier in the document. > Any particular place where you would like to have the reference? In the > Introduction?  Yes a heads up to to Appendix in the Intro would be useful, the a pointer to the specific section when you first introduce a parameter doing something in the protocol. Thanks Stewart From nobody Fri Jan 26 08:49:06 2018 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A4A126BFD; Fri, 26 Jan 2018 08:49:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell To: Cc: draft-ietf-ice-rfc5245bis.all@ietf.org, ietf@ietf.org, ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151698534014.492.17944720668568287169@ietfa.amsl.com> Date: Fri, 26 Jan 2018 08:49:00 -0800 Archived-At: Subject: [Ice] Secdir last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 16:49:00 -0000 Reviewer: Stephen Farrell Review result: Has Issues (1) I think a bit more work on the security and privacy issues around ICE would improve the document, and hopefully, ICE implementations. - There has been (IMO somewhat justified) concern [1] about exposing all possible addresses, for example where one is from a VPN intended to preserve privacy, say if a user is aiming to circumvent local censorship or surveillance. 5.1.1.1 has a SHOULD that, as I read it, says to always include such addresses. [1] https://www.w3.org/wiki/Privacy/IPAddresses (Note: I'm not claiming [1] is authoritative, it's just a page I found that describes the issue reasonably well.) There is a bit of text about this (1st para in section 19), but IMO it's a bit weak. - Did the WG consider REQUIRING or RECOMMENDING agent implementations provide some local interface that allows the host or an application to say "Don't use interface to generate any candidates until I tell you otherwise"? That might be better than having VPN operators recommending to turn off WebRTC entirely for example. (Note: this is my main comment, the rest are mostly suggested things to think about, if you've not already.) - Even if the text isn't changed, a reference to [2] would I think be useful. (Assuming [2] is still being worked on in rtcweb, though mind you, I don't like how [2] refers to "consent" as I doubt a random person can really provide meaningful consent for things like this.) [2] https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-04 - Separately [1] also describes another potential privacy issue with STUN urls. I think it'd be worthwhile noting such issues that have been found with deployments of ICE here, as any protocol using ICE and accepting non locally configured STUN/TURN URLs may have issues like that. For example, a recent paper [3] also describes some attacks (in section 4.2 mostly) that could (I guess) be mounted against any ICE agent and not only WebRTC clients. That'd be worth a reference and maybe thinking about which attacks are generic ICE issues and don't only affect WebRTC. [3] https://doi.org/10.1145/3019612.3019844 - I also wondered if I can fingerprint a host based on how it does ICE? I suspect that might work, but haven't tried to figure out details. - Could I probe an internal network based on feeding it candidates to check? E.g. checking timing of reactions. If I could that seems noteworthy. (2) 5.3: "...MUST contain ... bits of randomness" Don't you need to say when these values MUST be different and when they're ok to be re-used? I forget if STUN/TURN do that. (Also - the phrasing isn't that great - how do I "contain" randomness? But that's just a nit.) Nits: I took at look at the diff [4] between this and 5245, but that wasn't really that useful, so this review is based on a read of the draft without comparing it to 5245. Apologies if that causes me to comment on text that's unchanged - in such cases, I think it's fine to not heed those particular comments. [4] https://tools.ietf.org/rfcdiff?url1=rfc5245&url2=draft-ietf-ice-rfc5245bis-16.txt - 2.1: Why "only UDP specified here"? Does that include QUIC which is UDP-based, but not UDP? I assume so. - 2.3: how the controlling/controlled stuff works isn't clear from this, nor even (as I was reading it) in section 7.3.1.1 - I wasn't clear how the tie-breaker value is initialised until I got to 16.1. In any case I think a bit more explanatory text in 2.3 might be good. (But if implementers haven't had a problem with this, maybe it's just me.) - 5.2: "The procedures in this section is common across the initiating and responding agents." s/is/are/ I guess? - 6.1.1: What is "3PCC"? That note could maybe also do with a reference, as I at least don't get what you're trying to tell me. Ah - it's 3rd party call control (mentioned in 7.3.1.1). - 16.1: For a given ICE session, are the random numbers in the ICE-CONTROLLED and ICE-CONTROLLING attributes sent by the same agent supposed to have the same value? I wasn't clear. If they are the same, I understand how tie-breaking happens. If they can differ, I'm not sure. (But I didn't go back and re-read 7.3.1.1, so it may be ok either way:-) In any case saying "referred to as the tie-breaker value" twice seems odd. - 16.1: (mega-mega-nit:-) the fact that tie-breaker is split over a line-breaker here is why I didn't find this when I was reading 2.3/7.3.1.1 - maybe tweak the words so a grep will find it?) - 17: "looking to deploy ICE" is a bit confusing - do you mean "looking to be nice to ICE"? My assumption is that endpoints deploy ICE agents but network operators don't, though they might deploy STUN/TURN servers I guess. But maybe I'm thinking too much about WebRTC there. - 18: I wondered if this is still needed, given that 5245 already said it (I didn't check if the text has been updated). Saying this once would seem sufficient to me anyway. I guess leaving it in is the easier path. - 19: s/DNS-SEC/DNSSEC/ would be more common - 19.4.1: 1st sentence if missing a "T" - s/he/The/ From nobody Sun Jan 28 04:57:44 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EA812EBCC; Sun, 28 Jan 2018 04:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9JxMJJ3W51I; Sun, 28 Jan 2018 04:57:29 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938AB12EBC6; Sun, 28 Jan 2018 04:57:28 -0800 (PST) X-AuditID: c1b4fb25-48bff7000000341b-35-5a6dc8b6b585 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FB.83.13339.6B8CD6A5; Sun, 28 Jan 2018 13:57:26 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0352.000; Sun, 28 Jan 2018 13:57:25 +0100 From: Christer Holmberg To: Stephen Farrell , "secdir@ietf.org" CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-ice-rfc5245bis-16 Thread-Index: AQHTlsWSdlXqvNmVDEWzQ6CHG1vNgKOG2Qlg Date: Sun, 28 Jan 2018 12:57:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C143E76@ESESSMB109.ericsson.se> References: <151698534014.492.17944720668568287169@ietfa.amsl.com> In-Reply-To: <151698534014.492.17944720668568287169@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbHdTHfbidwog5OX+C2O//jDbvHtQq3F s43zWSw+LHzIYjF97zV2B1aPtd1X2TyWLPnJFMAUxWWTkpqTWZZapG+XwJWx+NlZpoJ3SRUr Zu1ib2BckdDFyMkhIWAisW9KJ0sXIxeHkMBhRokD0z4yQThLGCUOP1zF3sXIwcEmYCHR/U8b pEFEIEzi/vtDrCA1zAIzGSVe/3zJCJIQFnCRePmtjRWiyFVi5aYfTBC2kcSh1w3MIDaLgKrE rAULwGp4BXwldh6YBBYXEnCSePp6FhuIzSngLNG7oJkdxGYUEJP4fmoN2BxmAXGJW0/mM0Fc LSCxZM95ZghbVOLl43+sELaSxKLbn5lAbmYW0JRYv0sfolVRYkr3Q3aItYISJ2c+YZnAKDoL ydRZCB2zkHTMQtKxgJFlFaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZgBB3c8lt1B+PlN46H GAU4GJV4eCfszo0SYk0sK67MPcQowcGsJMJ7bDpQiDclsbIqtSg/vqg0J7X4EKM0B4uSOO9J T94oIYH0xJLU7NTUgtQimCwTB6dUA2OAa92DZ3OXf6vM8vy/+1j5+Vu6fcYnmrRTZl090TKB 1fuHVafEDd2vYfUCUlNNkhtP7H915brJXS7TB6v4K45ev1DtvVNY5F7NwU7WhvN3AlJPHjBS KOu/9yb5TDDLg9wgm7cK/RaHIz4ZVuc+EdkeulKKpVjy/tUZLfe9X7X7Rr/+JZQvKaHEUpyR aKjFXFScCADbg0U4nAIAAA== Archived-At: Subject: Re: [Ice] Secdir last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 12:57:32 -0000 SGkgU3RlcGhlbiwNCg0KVGhhbmsgWW91IGZvciB5b3VyIHJldmlldyEgUGxlYXNlIHNlZSBpbmxp bmUuDQoNCj5SZXZpZXdlcjogU3RlcGhlbiBGYXJyZWxsDQo+UmV2aWV3IHJlc3VsdDogSGFzIElz c3Vlcw0KPg0KPigxKSBJIHRoaW5rIGEgYml0IG1vcmUgd29yayBvbiB0aGUgc2VjdXJpdHkgYW5k IHByaXZhY3kgaXNzdWVzIGFyb3VuZCBJQ0Ugd291bGQgaW1wcm92ZSA+dGhlIGRvY3VtZW50LCBh bmQgaG9wZWZ1bGx5LCBJQ0UgaW1wbGVtZW50YXRpb25zLg0KPg0KPi0gVGhlcmUgaGFzIGJlZW4g KElNTyBzb21ld2hhdCBqdXN0aWZpZWQpIGNvbmNlcm4gWzFdIGFib3V0IGV4cG9zaW5nIGFsbCBw b3NzaWJsZSA+YWRkcmVzc2VzLCBmb3IgZXhhbXBsZSB3aGVyZSBvbmUgaXMgZnJvbSBhIFZQTiBp bnRlbmRlZCB0byBwcmVzZXJ2ZSBwcml2YWN5LCBzYXkgaWYgYSA+dXNlciBpcyBhaW1pbmcgdG8g Y2lyY3VtdmVudCBsb2NhbCBjZW5zb3JzaGlwIG9yIHN1cnZlaWxsYW5jZS4gIDUuMS4xLjEgaGFz IGEgU0hPVUxEIHRoYXQsID5hcyBJIHJlYWQgaXQsIHNheXMgdG8gYWx3YXlzIGluY2x1ZGUgc3Vj aCBhZGRyZXNzZXMuICANCj4NCj4gICBbMV0gaHR0cHM6Ly93d3cudzMub3JnL3dpa2kvUHJpdmFj eS9JUEFkZHJlc3Nlcw0KPg0KPihOb3RlOiBJJ20gbm90IGNsYWltaW5nIFsxXSBpcyBhdXRob3Jp dGF0aXZlLCBpdCdzIGp1c3QgYSBwYWdlIEkgZm91bmQgdGhhdCBkZXNjcmliZXMgdGhlIGlzc3Vl IHJlYXNvbmFibHkgd2VsbC4pDQo+DQo+VGhlcmUgaXMgYSBiaXQgb2YgdGV4dCBhYm91dCB0aGlz ICgxc3QgcGFyYSBpbiBzZWN0aW9uIDE5KSwgYnV0IElNTyBpdCdzIGEgYml0IHdlYWsuIA0KPg0K Pi0gRGlkIHRoZSBXRyBjb25zaWRlciBSRVFVSVJJTkcgb3IgUkVDT01NRU5ESU5HIGFnZW50IGlt cGxlbWVudGF0aW9ucw0KPiAgcHJvdmlkZSBzb21lIGxvY2FsIGludGVyZmFjZSB0aGF0IGFsbG93 cyB0aGUgaG9zdCBvciBhbiBhcHBsaWNhdGlvbiB0byBzYXkgIkRvbid0IHVzZSANCj4gPHRoaXM+ IGludGVyZmFjZSB0byBnZW5lcmF0ZSBhbnkgY2FuZGlkYXRlcyB1bnRpbCBJIHRlbGwgeW91IG90 aGVyd2lzZSI/ICBUaGF0IG1pZ2h0IGJlIA0KPiBiZXR0ZXIgdGhhbiBoYXZpbmcgVlBOIG9wZXJh dG9ycyByZWNvbW1lbmRpbmcgdG8gdHVybiBvZmYgV2ViUlRDIGVudGlyZWx5IGZvciANCj4gZXhh bXBsZS4gKE5vdGU6IHRoaXMgaXMgbXkgbWFpbiBjb21tZW50LCB0aGUgcmVzdCBhcmUgbW9zdGx5 IHN1Z2dlc3RlZCB0aGluZ3MgdG8gdGhpbmsgDQo+IGFib3V0LCBpZiB5b3UndmUgbm90IGFscmVh ZHkuKQ0KPg0KPiAtIEV2ZW4gaWYgdGhlIHRleHQgaXNuJ3QgY2hhbmdlZCwgYSByZWZlcmVuY2Ug dG8gWzJdIHdvdWxkIEkgdGhpbmsgYmUNCj4gIHVzZWZ1bC4gKEFzc3VtaW5nIFsyXSBpcyBzdGls bCBiZWluZyB3b3JrZWQgb24gaW4gcnRjd2ViLCB0aG91Z2ggbWluZCB5b3UsIEkgZG9uJ3QgbGlr ZSANCj4gaG93IFsyXSByZWZlcnMgdG8gImNvbnNlbnQiIGFzIEkgZG91YnQgYSByYW5kb20gcGVy c29uIGNhbiByZWFsbHkgcHJvdmlkZSBtZWFuaW5nZnVsIA0KPiBjb25zZW50IGZvciB0aGluZ3Mg bGlrZSB0aGlzLikNCj4NCj4gICBbMl0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtcnRjd2ViLWlwLWhhbmRsaW5nLTA0DQoNCkkgd291bGQgbm90IHdhbnQgdG8gUkVRVUlS RSBpbXBsZW1lbnRpbmcgYSBsb2NhbCBpbnRlcmZhY2UgZm9yIGNvbnRyb2xsaW5nIHRoZSBjYW5k aWRhdGVzLCBhcyBJQ0UgaXMgYWxzbyB1c2VkIGJ5IGRpZmZlcmVudCB0eXBlcyBvZiBuZXR3b3Jr IGVudGl0aWVzIChnYXRld2F5cyBldGMpLiBCdXQsIEkgYW0gb2sgdG8gUkVDT01NRU5ELg0KDQpX aGF0IGFib3V0Og0KDQpPTEQ6DQoNCiAgICJJbmRpdmlkdWFsIGltcGxlbWVudGF0aW9ucyBtYXkg YWxzbyBoYXZlIGltcGxlbWVudGF0aW9uLXNwZWNpZmljIHJ1bGVzIGZvciBjb250cm9sbGluZyB3 aGljaA0KICAgYWRkcmVzc2VzIGFyZSByZXZlYWxlZC4iDQoNCk5FVzoNCg0KICAgIkluZGl2aWR1 YWwgaW1wbGVtZW50YXRpb25zIG1heSBhbHNvIGhhdmUgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMg cnVsZXMgZm9yIGNvbnRyb2xsaW5nIHdoaWNoDQogICBhZGRyZXNzZXMgYXJlIHJldmVhbGVkLiBJ dCBpcyBSRUNPTU1FTkRFRCB0aGF0IGFwcGxpY2F0aW9ucyBpbnRlcmFjdGluZyB3aXRoIGh1bWFu IHVzZXJzIHByb3ZpZGUgDQogICBhIHVzZXIgaW50ZXJmYWNlcyB0aGF0IGFsbG93cyB0aGUgdXNl cnMgdG8gY29udHJvbCB3aGljaCBpbnRlcmZhY2VzIGFyZSB1c2VkIHRvIGdlbmVyYXRlIGNhbmRp ZGF0ZXMsIG9yIA0KICAgd2hlbiB0byB1c2UgY2FuZGlkYXRlcyBnZW5lcmF0ZWQgZm9yIHRoZSBp bnRlcmZhY2VzLg0KDQogICBbUkVGLXRvLSBkcmFmdC1pZXRmLXJ0Y3dlYi1pcC1oYW5kbGluZ10g cHJvdmlkZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFuZA0KICAgUmVxdWlyZW1lbnRzIHJlZ2Fy ZGluZyB0aGUgaGFuZGluZyBvZiBJUCBhZGRyZXNzZXMgZm9yIFdlYlJUQyBhcHBsaWNhdGlvbnMu Ig0KDQo+IC0gU2VwYXJhdGVseSBbMV0gYWxzbyBkZXNjcmliZXMgYW5vdGhlciBwb3RlbnRpYWwg cHJpdmFjeSBpc3N1ZSB3aXRoDQo+ICBTVFVOIHVybHMuIEkgdGhpbmsgaXQnZCBiZSB3b3J0aHdo aWxlIG5vdGluZyBzdWNoIGlzc3VlcyB0aGF0IGhhdmUgYmVlbiBmb3VuZCB3aXRoIGRlcGxveW1l bnRzIG9mIA0KPiBJQ0UgaGVyZSwgYXMgYW55IHByb3RvY29sIHVzaW5nIElDRSBhbmQgYWNjZXB0 aW5nIG5vbiBsb2NhbGx5IGNvbmZpZ3VyZWQgU1RVTi9UVVJOIFVSTHMgbWF5IGhhdmUgDQo+IGlz c3VlcyBsaWtlIHRoYXQuIEZvciBleGFtcGxlLCBhIHJlY2VudCBwYXBlciBbM10gYWxzbyBkZXNj cmliZXMgc29tZSBhdHRhY2tzIChpbiBzZWN0aW9uIDQuMiBtb3N0bHkpIHRoYXQgDQo+IGNvdWxk IChJIGd1ZXNzKSBiZSBtb3VudGVkIGFnYWluc3QgYW55IElDRSBhZ2VudCBhbmQgbm90IG9ubHkg V2ViUlRDIGNsaWVudHMuIFRoYXQnZCBiZSB3b3J0aCBhIHJlZmVyZW5jZSANCj4gYW5kIG1heWJl IHRoaW5raW5nIGFib3V0IHdoaWNoIGF0dGFja3MgYXJlIGdlbmVyaWMgSUNFIGlzc3VlcyBhbmQg ZG9uJ3Qgb25seSBhZmZlY3QgV2ViUlRDLg0KPg0KPiAgIFszXSBodHRwczovL2RvaS5vcmcvMTAu MTE0NS8zMDE5NjEyLjMwMTk4NDQNCg0KSSBhbSBzdHJ1Z2dsaW5nIHRvIGZpZ3VyZSBvdXQgZXhh Y3RseSB3aGF0IHRvIGRvIGhlcmUuLi4gSSByZWFsbHkgaG9wZSB3ZSBkb24ndCBoYXZlIHRvIHBl cmZvbSBhIHN0dWR5IG9uIFszXSwgYW5kIHNlZSB3aGF0IGlzIGdlbmVyYWwsIGFuZCB3aGF0IGlz IFdlYlJUQy1zcGVjaWZpYy4gQXJlIHdlIGV2ZW4gYWxsb3dlZCB0byByZWZlcmVuY2UgWzNdLCBh cyBpdCdzIG5vdCBmcmVlbHkgYXZhaWxhYmxlPw0KDQpTb21lIGhlbHAgYW5kIGd1aWRhbmNlIHdv dWxkIGJlIGFwcHJlY2lhdGVkIDopDQoNCi0tLQ0KDQo+IC0gSSBhbHNvIHdvbmRlcmVkIGlmIEkg Y2FuIGZpbmdlcnByaW50IGEgaG9zdCBiYXNlZCBvbiBob3cgaXQgZG9lcyBJQ0U/ICANCj4gIEkg IHN1c3BlY3QgdGhhdCBtaWdodCB3b3JrLCBidXQgaGF2ZW4ndCB0cmllZCB0byBmaWd1cmUgb3V0 IGRldGFpbHMuDQo+DQo+IC0gQ291bGQgSSBwcm9iZSBhbiBpbnRlcm5hbCBuZXR3b3JrIGJhc2Vk IG9uIGZlZWRpbmcgaXQgY2FuZGlkYXRlcyB0bw0KPiAgY2hlY2s/IEUuZy4gY2hlY2tpbmcgdGlt aW5nIG9mIHJlYWN0aW9ucy4gIElmIEkgY291bGQgdGhhdCBzZWVtcyBub3Rld29ydGh5Lg0KDQpT b21ldGhpbmcgbGlrZT8NCg0KIkJhc2VkIG9uIHRoZSB0eXBlcyBvZiBjYW5kaWRhdGVzIHByb3Zp ZGVkIGJ5IHRoZSBwZWVyLCBhbmQgdGhlIHJlc3VsdHMgb2YgdGhlIGNvbm5lY3Rpdml0eSB0ZXN0 cyBwZXJmb3JtZWQgDQpBZ2FpbnN0IHRob3NlIGNhbmRpZGF0ZXMsIGFuIGFnZW50IG1pZ2h0IGJl IGFibGUgdG8gZGV0ZXJtaW5lIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgcGVlciBuZXR3b3JrLiIN Cg0KLS0tDQoNCj4gKDIpIDUuMzogIi4uLk1VU1QgY29udGFpbiAuLi4gPGZvbz4gYml0cyBvZiBy YW5kb21uZXNzIiBEb24ndCB5b3UgbmVlZCB0byBzYXkgd2hlbiB0aGVzZSB2YWx1ZXMgTVVTVCBi ZSBkaWZmZXJlbnQgYW5kIHdoZW4gdGhleSdyZSBvayB0byBiZSByZS11c2VkPyBJIGZvcmdldCBp ZiBTVFVOL1RVUk4gZG8gdGhhdC4gDQoNClNlY3Rpb24gNy4yLjIgc2F5czoNCg0KIkEgY29ubmVj dGl2aXR5IGNoZWNrIEJpbmRpbmcgcmVxdWVzdCBNVVNUIHV0aWxpemUgdGhlIFNUVU4gc2hvcnQt dGVybSBjcmVkZW50aWFsIG1lY2hhbmlzbS4iDQoNClJGQyA1Mzg5IChTVFVOKSBzYXlzOg0KDQog ICAgICAiU2hvcnQtVGVybSBDcmVkZW50aWFsOiAgQSB0ZW1wb3JhcnkgdXNlcm5hbWUgYW5kIGFz c29jaWF0ZWQgcGFzc3dvcmQNCiAgICAgIHRoYXQgcmVwcmVzZW50IGEgc2hhcmVkIHNlY3JldCBi ZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyLiAgU2hvcnQtDQogICAgICB0ZXJtIGNyZWRlbnRpYWxz IGFyZSBvYnRhaW5lZCB0aHJvdWdoIHNvbWUga2luZCBvZiBwcm90b2NvbA0KICAgICAgbWVjaGFu aXNtIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgc2VydmVyLCBwcmVjZWRpbmcgdGhlIFNUVU4NCiAg ICAgIGV4Y2hhbmdlLiAgQSBzaG9ydC10ZXJtIGNyZWRlbnRpYWwgaGFzIGFuIGV4cGxpY2l0IHRl bXBvcmFsIHNjb3BlLA0KICAgICAgd2hpY2ggbWF5IGJlIGJhc2VkIG9uIGEgc3BlY2lmaWMgYW1v dW50IG9mIHRpbWUgKHN1Y2ggYXMgNQ0KICAgICAgbWludXRlcykgb3Igb24gYW4gZXZlbnQgKHN1 Y2ggYXMgdGVybWluYXRpb24gb2YgYSBTSVAgZGlhbG9nKS4NCiAgICAgIFRoZSBzcGVjaWZpYyBz Y29wZSBvZiBhIHNob3J0LXRlcm0gY3JlZGVudGlhbCBpcyBkZWZpbmVkIGJ5IHRoZQ0KICAgICAg YXBwbGljYXRpb24gdXNhZ2UuIg0KDQpJZiBhbnl0aGluZyBleHRyYSBpcyBuZWVkZWQsIEkgdGhp bmsgdGhhdCBzaG91bGQgYmUgZG9uZSBhcyBhbiB1cGRhdGUgdG8gU1RVTi4NCg0KID4gKEFsc28g LSB0aGUgcGhyYXNpbmcgaXNuJ3QgdGhhdCBncmVhdCAtIGhvdyBkbyBJICJjb250YWluIiByYW5k b21uZXNzPyBCdXQgdGhhdCdzIGp1c3QgYSBuaXQuKQ0KDQpEbyB5b3UgaGF2ZSBhIHN1Z2dlc3Rp b24gZm9yIGEgYmV0dGVyIHdvcmQ/DQoNCj09PT09PT09PT09PT09PT09PT09PT09PQ0KDQpOaXRz Og0KDQo+IEkgdG9vayBhIGxvb2sgYXQgdGhlIGRpZmYgWzRdIGJldHdlZW4gdGhpcyBhbmQgNTI0 NSwgYnV0IHRoYXQgd2Fzbid0IHJlYWxseSB0aGF0IHVzZWZ1bCwgc28gdGhpcyByZXZpZXcgaXMg YmFzZWQgb24NCj4gYSByZWFkIG9mIHRoZSBkcmFmdCB3aXRob3V0IGNvbXBhcmluZyBpdCB0byA1 MjQ1LiBBcG9sb2dpZXMgaWYgdGhhdCBjYXVzZXMgbWUgdG8gY29tbWVudCBvbiB0ZXh0IHRoYXQn cw0KPiB1bmNoYW5nZWQgLSBpbiBzdWNoIGNhc2VzLCBJIHRoaW5rIGl0J3MgZmluZSB0byBub3Qg aGVlZCB0aG9zZSBwYXJ0aWN1bGFyIGNvbW1lbnRzLiANCj4NCj4gICBbNF0gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9cmZjNTI0NSZ1cmwyPWRyYWZ0LWlldGYtaWNlLXJmYzUy NDViaXMtMTYudHh0DQo+DQo+IC0gMi4xOiBXaHkgIm9ubHkgVURQIHNwZWNpZmllZCBoZXJlIj8g RG9lcyB0aGF0IGluY2x1ZGUgUVVJQyB3aGljaCBpcw0KPiAgIFVEUC1iYXNlZCwgYnV0IG5vdCBV RFA/IEkgYXNzdW1lIHNvLg0KDQpUaGVyZSBpcyBhIHNlcGFyYXRlIHNwZWNpZmljYXRpb24sIFJG QyA2NTQ0LCBmb3IgVENQIGJhc2VkIGNhbmRpZGF0ZXMuDQoNClJlZ2FyZGluZyBRVUlDLCBJIGRv bid0IGtub3cuIFFVSUMgd2Fzbid0IGRpc2N1c3NlZCBkdXJpbmcgdGhlIHdvcmssIGJ1dCBob3cv aWYgdGhlIHByb2NlZHVyZXMgYWxzbyBhcHBseSB0byBRVUlDIHdpdGhvdXQgYW55IG1vZGlmaWNh dGlvbnMgZXRjIEkgZG9uJ3Qga25vdy4NCg0KPiAtIDIuMzogaG93IHRoZSBjb250cm9sbGluZy9j b250cm9sbGVkIHN0dWZmIHdvcmtzIGlzbid0IGNsZWFyIGZyb20NCj4gIHRoaXMsIG5vciBldmVu IChhcyBJIHdhcyByZWFkaW5nIGl0KSBpbiBzZWN0aW9uIDcuMy4xLjEgLSBJIHdhc24ndCBjbGVh ciBob3cgdGhlIHRpZS1icmVha2VyIHZhbHVlIGlzIGluaXRpYWxpc2VkIHVudGlsIEkgZ290IHRv IDE2LjEuDQo+IEluIGFueSBjYXNlIEkgdGhpbmsgYSBiaXQgbW9yZSBleHBsYW5hdG9yeSB0ZXh0 IGluIDIuMyBtaWdodCBiZSBnb29kLg0KPiAoQnV0IGlmIGltcGxlbWVudGVycyBoYXZlbid0IGhh ZCBhIHByb2JsZW0gd2l0aCB0aGlzLCBtYXliZSBpdCdzIGp1c3QgbWUuKQ0KDQpJbiBnZW5lcmFs LCBvbmUgb2YgdGhlIHRhc2tzIG9mIHRoZSBiaXMgd29yayB3YXMgdG8gKnNpbXBsaWZ5KiBzZWN0 aW9uIDIsIGJlY2F1c2UgdGhlIHByZXZpb3VzIHZlcnNpb24gd2FzIHRvbyBkZXRhaWxlZCBmb3Ig bm9uLWltcGxlbWVudGVycyB3aG8ganVzdCB3YW50IHRvIGZpZ3VyZSBvdXQgd2hhdCBJQ0UgaXMg YWxsIGFib3V0IChpbiBvcmRlciB0byAgYWN0dWFsbHkgaW1wbGVtZW50IElDRSwgcmVhZGluZyBz ZWN0aW9uIDIgaXMgb2J2aW91c2x5IG5vdCBlbm91Z2gpLiBGb3IgdGhhdCByZWFzb24sIG15IG9w aW5pb24gd2FzIHRoYXQgc2VjdGlvbiAyIGRvZXNuJ3QgcmVhbGx5IG5lZWQgdG8gdGFsayBhYm91 dCByb2xlIGNvbmZsaWN0cyBhbmQgdGllLWJyZWFrZXIgdmFsdWVzLCBhcyBpdCdzIG5vdCBlc3Nl bnRpYWwgZm9yIGEgaGlnaC1sZXZlbCBkZXNjcmlwdGlvbiBvZiBJQ0UuDQoNCi0tLQ0KDQo+IC0g NS4yOiAiVGhlIHByb2NlZHVyZXMgaW4gdGhpcyBzZWN0aW9uIGlzIGNvbW1vbiBhY3Jvc3MgdGhl IGluaXRpYXRpbmcNCj4gIGFuZCByZXNwb25kaW5nIGFnZW50cy4iIHMvaXMvYXJlLyBJIGd1ZXNz Pw0KDQpZZXMuIEkgd2lsbCBmaXggYXMgc3VnZ2VzdGVkLg0KDQotLS0NCg0KPiAtIDYuMS4xOiBX aGF0IGlzICIzUENDIj8gVGhhdCBub3RlIGNvdWxkIG1heWJlIGFsc28gZG8gd2l0aCBhDQo+ICBy ZWZlcmVuY2UsIGFzIEkgYXQgbGVhc3QgZG9uJ3QgZ2V0IHdoYXQgeW91J3JlIHRyeWluZyB0byB0 ZWxsIG1lLiBBaA0KPiAtIGl0J3MgM3JkIHBhcnR5IGNhbGwgY29udHJvbCAobWVudGlvbmVkIGlu IDcuMy4xLjEpLg0KDQpJIGNhbiB1c2UgIjNQQ0MgKDNyZCBQYXJ0eSBDYWxsIENvbnRyb2wpIiBp biBzZWN0aW9uIDYuMS4xLg0KDQpBcyB0aGUgc3BlYyBpcyBwcm90b2NvbCBpbmRlcGVuZGVudCwg SSBkb24ndCB0aGluayB0aGVyZSBhcmUgYW55IHJlZmVyZW5jZXMgdGhhdCBjYW4gYmUgYWRkZWQu DQoNCi0tLQ0KDQo+IC0gMTYuMTogRm9yIGEgZ2l2ZW4gSUNFIHNlc3Npb24sIGFyZSB0aGUgcmFu ZG9tIG51bWJlcnMgaW4gdGhlDQo+ICBJQ0UtQ09OVFJPTExFRCBhbmQgSUNFLUNPTlRST0xMSU5H IGF0dHJpYnV0ZXMgc2VudCBieSB0aGUgc2FtZSBhZ2VudCBzdXBwb3NlZCB0byBoYXZlDQo+IHRo ZSBzYW1lIHZhbHVlPyBJIHdhc24ndCBjbGVhci4gSWYgdGhleSBhcmUgdGhlIHNhbWUsIEkgdW5k ZXJzdGFuZCBob3cgdGllLWJyZWFraW5nIGhhcHBlbnMuIA0KPiBJZiB0aGV5IGNhbiBkaWZmZXIs IEknbSBub3Qgc3VyZS4gKEJ1dCBJIGRpZG4ndCBnbyBiYWNrIGFuZCByZS1yZWFkIDcuMy4xLjEs IHNvIGl0IG1heSBiZSBvayBlaXRoZXIgDQo+IHdheTotKSANCg0KSXQgaXMgY292ZXJlZCBpbiB0 aGUgMm5kIHBhcmFncmFwaCBvZiBzZWN0aW9uIDcuMi41LjEsIHdoaWNoIHNheXMgdGhhdCB0aGUg YWdlbnQgTUFZIGNoYW5nZSB0aGUgdmFsdWUgd2hlbiBpdCBzd2l0Y2hlcyByb2xlLg0KDQo+IElu IGFueSBjYXNlIHNheWluZyAicmVmZXJyZWQgdG8gYXMgdGhlIHRpZS1icmVha2VyIHZhbHVlIiB0 d2ljZSBzZWVtcyBvZGQuIA0KDQpJJ2xsIHJlbW92ZSBpdCBmcm9tIHRoZSBJQ0UtQ09OVFJPTExJ TkcgZGVmaW5pdGlvbi4NCg0KLS0tDQoNCj4gLSAxNi4xOiAobWVnYS1tZWdhLW5pdDotKSB0aGUg ZmFjdCB0aGF0IHRpZS1icmVha2VyIGlzIHNwbGl0IG92ZXIgYQ0KPiAgbGluZS1icmVha2VyIGhl cmUgaXMgd2h5IEkgZGlkbid0IGZpbmQgdGhpcyB3aGVuIEkgd2FzIHJlYWRpbmcNCj4gMi4zLzcu My4xLjEgLSBtYXliZSB0d2VhayB0aGUgd29yZHMgc28gYSBncmVwIHdpbGwgZmluZCBpdD8pDQoN Ckdvb2QgY2F0Y2guIEknbGwgZml4IGl0Lg0KDQpJdCB3b3VsZCBiZSByZWFsbHkgY29vbCBpZiBz ZWFyY2ggZnVuY3Rpb25zIGNvdWxkIGRpc2NhcmQgbGluZS1icmVha3Mgd2hlbiBzZWFyY2hpbmcg Zm9yIHN0cmluZ3MuDQoNCi0tLQ0KDQo+IC0gMTc6ICJsb29raW5nIHRvIGRlcGxveSBJQ0UiIGlz IGEgYml0IGNvbmZ1c2luZyAtIGRvIHlvdSBtZWFuDQo+ICAibG9va2luZyB0byBiZSBuaWNlIHRv IElDRSI/IE15IGFzc3VtcHRpb24gaXMgdGhhdCBlbmRwb2ludHMgZGVwbG95IElDRSBhZ2VudHMg YnV0IA0KPiBuZXR3b3JrIG9wZXJhdG9ycyBkb24ndCwgdGhvdWdoIHRoZXkgbWlnaHQgZGVwbG95 IFNUVU4vVFVSTiBzZXJ2ZXJzIEkgZ3Vlc3MuIEJ1dCANCj4gbWF5YmUgSSdtIHRoaW5raW5nIHRv byBtdWNoIGFib3V0IFdlYlJUQyB0aGVyZS4NCg0KUGVyaGFwcyBzb21ldGhpbmcgbGlrZToNCg0K ICAgIlRoaXMgc2VjdGlvbiBkaXNjdXNzZXMgaXNzdWVzIHJlbGV2YW50IHRvIG9wZXJhdG9ycyBv cGVyYXRpbmcgbmV0d29ya3Mgd2hlcmUgSUNFIHdpbGwgYmUgdXNlZCBieSBlbmRwb2ludHMuIg0K DQotLS0NCg0KPiAtIDE4OiBJIHdvbmRlcmVkIGlmIHRoaXMgaXMgc3RpbGwgbmVlZGVkLCBnaXZl biB0aGF0IDUyNDUgYWxyZWFkeSBzYWlkDQo+ICBpdCAoSSBkaWRuJ3QgY2hlY2sgaWYgdGhlIHRl eHQgaGFzIGJlZW4gdXBkYXRlZCkuIFNheWluZyB0aGlzIG9uY2Ugd291bGQgc2VlbSBzdWZmaWNp ZW50IA0KPiB0byBtZSBhbnl3YXkuIEkgZ3Vlc3MgbGVhdmluZyBpdCBpbiBpcyB0aGUgZWFzaWVy IHBhdGguDQoNCkknbGwgbGVhdmUgaXQgOikNCg0KLS0tDQoNCj4gLSAxOTogcy9ETlMtU0VDL0RO U1NFQy8gd291bGQgYmUgbW9yZSBjb21tb24NCg0KSSB3aWxsIGZpeCBhcyBzdWdnZXN0ZWQuDQoN Ci0tLQ0KDQo+IC0gMTkuNC4xOiAxc3Qgc2VudGVuY2UgaWYgbWlzc2luZyBhICJUIiAtIHMvaGUv VGhlLw0KDQpJIHdpbGwgZml4IGFzIHN1Z2dlc3RlZC4NCg0KLS0tDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNCg== From nobody Sun Jan 28 05:28:48 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8FA12EBFC; Sun, 28 Jan 2018 05:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtmvFMOPKdkb; Sun, 28 Jan 2018 05:28:40 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC8612EBF8; Sun, 28 Jan 2018 05:28:39 -0800 (PST) X-AuditID: c1b4fb25-48bff7000000341b-ef-5a6dd0058253 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 23.C5.13339.500DD6A5; Sun, 28 Jan 2018 14:28:38 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Sun, 28 Jan 2018 14:28:37 +0100 From: Christer Holmberg To: Stewart Bryant , "gen-art@ietf.org" CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" Thread-Topic: Genart last call review of draft-ietf-ice-rfc5245bis-16 Thread-Index: AQHTlidlFcjVN0hAZUOXDa/c5U88WKOFL91AgAC5GoCAA1oYEA== Date: Sun, 28 Jan 2018 13:28:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C143F85@ESESSMB109.ericsson.se> References: <151691740516.8342.10156383952294498449@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C13FB29@ESESSMB109.ericsson.se> <2e40bec1-ce67-edd5-c2f8-73b00344e856@gmail.com> In-Reply-To: <2e40bec1-ce67-edd5-c2f8-73b00344e856@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGbFdWpftQm6UwYftrBbHf/xht7j66jOL xbcLtRbPNs5nsTj1INGB1WPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgylj8oqjgi1jF+ecL mBsYV4h1MXJySAiYSHz/fJGpi5GLQ0jgMKPEpql/WSCcJYwSR7vnAzkcHGwCFhLd/7RBGkQE wiQub7jODFLDLDCTUeL1z5eMIAlhAReJrl+b2CGKXCUunvwDZTtJ7Ln8hgXEZhFQlfg59SAb iM0r4Cux+vwGZohluxgllv15BzaIU8BWonvmWTCbUUBM4vupNUwgNrOAuMStJ/OZIM4WkFiy 5zwzhC0q8fLxP1YIW0li0e3PTCBHMwtoSqzfpQ/RqigxpfshO8ReQYmTM5+wTGAUnYVk6iyE jllIOmYh6VjAyLKKUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzB+Dm75rbqD8fIbx0OMAhyM Sjy8E3bnRgmxJpYVV+YeYpTgYFYS4T02HSjEm5JYWZValB9fVJqTWnyIUZqDRUmc96Qnb5SQ QHpiSWp2ampBahFMlomDU6qBseSO5459+1xvm6fHLgpeatKnnSUpxjypq39RHkuLNav02nmS eb++rReWWKUUUrlSPd7QwOUY1z+/Nx4fd8XNevkxw2nrdUd5Do1jVcFHL+1muet9xaf1zqys ZulpMVUvZguYi36vtTjOajUhPbDm2IYHDcV12eGVz2XtjEXm1OdKPnmecmSxEktxRqKhFnNR cSIAQNqaYpsCAAA= Archived-At: Subject: Re: [Ice] Genart last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 13:28:42 -0000 SGkgU3Rld2FyZCwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCj4gLS0tDQo+DQo+PiBTQj4gWW91 IGludHJvZHVjZSBUYSwgYnV0IGl0IHdvdWxkIGJlIHNvIG11Y2gga2luZGVyIHRvIHRoZSByZWFk ZXIgdG8gDQo+PiBTQj4gZ2l2ZSBpdCBhIHJlYWwgbmFtZS4NCj4gVGEgd2FzIGRlZmluZWQgaW4g UkZDIDUyNDUsIGFuZCBpdCdzIGNvbW1vbmx5IHVzZWQgaW4gSUNFLXJlbGF0ZWQgDQo+IGRpc2N1 c3Npb25zLCBzbyBJIHRoaW5rIGl0IHdvdWxkIGNhdXNlIGNvbmZ1c2lvbiB0byBjaGFuZ2UgdGhl IG5hbWUgYXQgDQo+IHRoaXMgcG9pbnQuDQo+DQo+IEkgdW5kZXJzdGFuZC4gTWF5YmUgc29tZSB3 b3JkcyB0byBleHBsYWluIGl0IGEgbGl0dGxlLiBQZXJoYXBzICJ0aGUgZm9vIHRpbWVyIGtub3du IGluIHRoaXMgdGVjaG5vbG9neSBhcyBUYSIgb2Ygc29tZXRoaW5nIHNpbWlsYXIuDQo+DQo+Pj4g WW91IHNheSAiTGV0IEhUTyIgYWdhaW4gYSB1c2VyIGZyaWVuZGx5IG5hbWUgd291bGQgYmUgaGVs cGZ1bCB0byB0aGUgDQo+Pj4gbmV3IHJlYWRlcg0KPj4gVGhlIG5hbWUgd2FzIHByb3ZpZGVkIGJ5 IHRyYW5zcG9ydCBwZW9wbGUgdGhhdCBwcm92aWRlZCB0ZXh0LiBBcyBpdMK5cyANCj4+IHNpbWls YXIgdG8gUlRPLCBJwrlkIGxpa2UgdG8ga2VlcCBpdC4NCj4NCj4gSSBzZWUgd2hhdCB5b3UgYXJl IGRvaW5nLiBZb3UgY291bGQgaG93ZXZlciBnaXZlIGl0IGEgbmFtZSBhbmQgc2F5IGtub3duIGFz IEhUTy4gQSBuYW1lIGp1c3QgbWFrZXMgaXQgZWFzaWVyIHRvIHJlbWVtYmVyIHdoYXQgaXQgZG9l cy4NCg0KRmlyc3QsIEkgYW0gbm90IHN1cmUgd2hpY2ggZ2VuZXJpYyB0aW1lciBUYSBjb3VsZCBi ZSBhc3NvY2lhdGVkIHdpdGguIFRhIGlzIHZlcnkgSUNFIHNwZWNpZmljLCBhcyBpdCBjb250cm9s cyB0aGUgU1RVTi9UVVJOIHRyYW5zYWN0aW9ucy4gDQoNClNlY3Rpb24gNS4xLjEuMiBzYXlzOg0K DQogICAiVGhlIGdhdGhlcmluZyBwcm9jZXNzIGlzIGNvbnRyb2xsZWQgdXNpbmcgYSB0aW1lciwg VGEuICBFdmVyeSB0aW1lIFRhDQogICBleHBpcmVzLCB0aGUgYWdlbnQgY2FuIGdlbmVyYXRlIGFu b3RoZXIgbmV3IFNUVU4gb3IgVFVSTiB0cmFuc2FjdGlvbi4iDQoNCldvdWxkIGl0IGhlbHAgaWYg SSBhZGRlZCB0aGUgdGltZXIgZGVzY3JpcHRpb25zIHRvIHRoZSBUZXJtaW5vbG9neSBzZWN0aW9u PyBTb21ldGhpbmcgbGlrZToNCg0KVGltZXIgVGE6CVRoZSB0aW1lciBmb3IgZ2VuZXJhdGluZyBu ZXcgU1RVTiBvciBUVVJOIHRyYW5zYWN0aW9ucy4NClRpbWVyIFJUTzoJVGhlIHJldHJhbnNtaXNz aW9uIHRpbWVyIGZvciBhIGdpdmVuIFNUVU4gb3IgVFVSTiB0cmFuc2FjdGlvbi4NClRpbWVyIEhU TzoJVGhlIHRpbWVvdXQgdGltZXIgZm9yIGEgZ2l2ZW4gU1RVTiBvciBUVVJOIHRyYW5zYWN0aW9u LgkNCg0KLS0tDQoNCj4+PiBBcHBlbmRpeCBCIGlzIGdyZWF0LCBwYXJ0aWN1bGFybHkgZnJvbSBz ZWN0aW9uIEI1IG9ud2FyZHMuIEl0IHdvdWxkIA0KPj4+IGJlIGdyZWF0IHRvIGZvcndhcmQgcmVm ZXJlbmNlIHRoaXMgdG8gaGVscCB0aGUgcmVhZGVyIHVuZGVyc3RhbmQgdGhlIA0KPj4+IG5vcm1h dGl2ZSB0ZXh0IGVhcmxpZXIgaW4gdGhlIGRvY3VtZW50Lg0KPj4gQW55IHBhcnRpY3VsYXIgcGxh Y2Ugd2hlcmUgeW91IHdvdWxkIGxpa2UgdG8gaGF2ZSB0aGUgcmVmZXJlbmNlPyBJbiB0aGUgSW50 cm9kdWN0aW9uPw0KPiBZZXMgYSBoZWFkcyB1cCB0byB0byBBcHBlbmRpeCBpbiB0aGUgSW50cm8g d291bGQgYmUgdXNlZnVsLCB0aGUgYSBwb2ludGVyIHRvIHRoZSBzcGVjaWZpYyBzZWN0aW9uIA0K PiB3aGVuIHlvdSBmaXJzdCBpbnRyb2R1Y2UgYSBwYXJhbWV0ZXIgZG9pbmcgc29tZXRoaW5nIGlu IHRoZSBwcm90b2NvbC4NCg0KV2hhdCBhYm91dCBhZGRpbmcgdGhlIGZvbGxvd2luZyBuZXcgcGFy YWdyYXBoIHRvIHRoZSBlbmQgb2YgdGhlIEludHJvZHVjdGlvbi4NCg0KIltSRUYtdG8tQXBwZW5k aXgtQl0gcHJvdmlkZSBiYWNrZ3JvdW5kIGluZm9ybWF0aW9uIGFuZCBtb3RpdmF0aW9ucyByZWdh cmRpbmcgdGhlIGRlc2lnbg0KZGVjaXNpb25zIHRoYXQgd2VyZSBtYWRlIHdoZW4gZGVzaWduaW5n IElDRS4iDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= From nobody Sun Jan 28 15:35:27 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D342913148C; Sun, 28 Jan 2018 15:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5pJETEkCUtl; Sun, 28 Jan 2018 15:35:19 -0800 (PST) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF0F131478; Sun, 28 Jan 2018 15:35:19 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id 16so5272072wry.12; Sun, 28 Jan 2018 15:35:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d16jsK3X1VaDMsHHCWa/+sBWPDQibIdQHsrR3Gla0pM=; b=gN6tMYKwYqlw/QXOQVfcwxuydMPycn9sVrzW/m5HDthwd3Pudi/PMQU5yT534X5b/R i9LmSZ0MvgWii1w/l03MqqjB45rLmPsA/ffllmOr9c9AWUtoEGi0Hq8but5jKELrLzOg kM7SNAVVA5LncYfi57zGAJaOrQIEevKsfTmwyfWKG1uBZXjiRV5TePy67zn7VA1RIPGL hyF8zdp1jN4135cpE3hU+oxoK4WXvYzRhw30tmyJT9EfFmnWgn13Q/RBH5L7JQX7CbeV nXiCxuEmWFVo1mfTrRyBdrmMUJzN7RIpFbjHiZsgk4akBv+8GW999fCKLvDJfSiBNYnb D5FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d16jsK3X1VaDMsHHCWa/+sBWPDQibIdQHsrR3Gla0pM=; b=dCZ/G9VezFaMqZ2mLVIGoqJcWr6U5dj/1IgsYu6cB5aSMZy9P5O6BoFwqc7SJcmYAs ph9VK9jlFxI+eHot9bGXBwOVkz+1U2CNqW1kafv+PPgPBff1ukj9Ukyh0mkAWV6kin8U quy8EZ+CcB2gXY8MHbA9RkIKxB8cDmj3xKY3iUhqyAn1Fmm7xhJP7vG64aBr0WeO0beq vJL5QPs9a9W5WyUhIOcJFBgJzitCEgUmSR8erqx/X8GBRGAHs4tKdgfLX3rby4vES2Ks XyHEqy792QlC7p6kxofMSFICP7z48SnUMvmQVuecVCdU/ztEAefO4bShHcGg17iP02YD eXFw== X-Gm-Message-State: AKwxytdz6lon0EbszoCvULAUDaMNKEh+VtBt49kRfapH3v3frkcXIaju EFHLmA8qWRuaoL7lumkDvoSCrPM6 X-Google-Smtp-Source: AH8x225QQyQQs39ngFy6B7uza1X1MyNiUpFICF64jeijfRRFWNtw37FS5uuAWiM41Sn9zxRRlLyaGQ== X-Received: by 10.223.184.102 with SMTP id u35mr17069634wrf.143.1517182517370; Sun, 28 Jan 2018 15:35:17 -0800 (PST) Received: from [192.168.2.173] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id x127sm7977861wmb.36.2018.01.28.15.35.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Jan 2018 15:35:16 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Stewart Bryant X-Mailer: iPad Mail (15C153) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C143F85@ESESSMB109.ericsson.se> Date: Sun, 28 Jan 2018 23:35:15 +0000 Cc: "gen-art@ietf.org" , "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <02C75B51-EA38-42C7-BD9B-FAC477FF0AC8@gmail.com> References: <151691740516.8342.10156383952294498449@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C13FB29@ESESSMB109.ericsson.se> <2e40bec1-ce67-edd5-c2f8-73b00344e856@gmail.com> <7594FB04B1934943A5C02806D1A2204B6C143F85@ESESSMB109.ericsson.se> To: Christer Holmberg Archived-At: Subject: Re: [Ice] Genart last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 23:35:21 -0000 Yes, both would be excellent clarifications that would have helped me. Thanks Stewart Sent from my iPad > On 28 Jan 2018, at 13:28, Christer Holmberg wrote: >=20 > Hi Steward, >=20 > Please see inline. >=20 >> --- >>=20 >>> SB> You introduce Ta, but it would be so much kinder to the reader to=20= >>> SB> give it a real name. >> Ta was defined in RFC 5245, and it's commonly used in ICE-related=20 >> discussions, so I think it would cause confusion to change the name at=20= >> this point. >>=20 >> I understand. Maybe some words to explain it a little. Perhaps "the foo t= imer known in this technology as Ta" of something similar. >>=20 >>>> You say "Let HTO" again a user friendly name would be helpful to the=20= >>>> new reader >>> The name was provided by transport people that provided text. As it=C2=B9= s=20 >>> similar to RTO, I=C2=B9d like to keep it. >>=20 >> I see what you are doing. You could however give it a name and say known a= s HTO. A name just makes it easier to remember what it does. >=20 > First, I am not sure which generic timer Ta could be associated with. Ta i= s very ICE specific, as it controls the STUN/TURN transactions.=20 >=20 > Section 5.1.1.2 says: >=20 > "The gathering process is controlled using a timer, Ta. Every time Ta > expires, the agent can generate another new STUN or TURN transaction." >=20 > Would it help if I added the timer descriptions to the Terminology section= ? Something like: >=20 > Timer Ta: The timer for generating new STUN or TURN transactions. > Timer RTO: The retransmission timer for a given STUN or TURN transactio= n. > Timer HTO: The timeout timer for a given STUN or TURN transaction. =20= >=20 > --- >=20 >>>> Appendix B is great, particularly from section B5 onwards. It would=20 >>>> be great to forward reference this to help the reader understand the=20= >>>> normative text earlier in the document. >>> Any particular place where you would like to have the reference? In the I= ntroduction? >> Yes a heads up to to Appendix in the Intro would be useful, the a pointer= to the specific section=20 >> when you first introduce a parameter doing something in the protocol. >=20 > What about adding the following new paragraph to the end of the Introducti= on. >=20 > "[REF-to-Appendix-B] provide background information and motivations regard= ing the design > decisions that were made when designing ICE." >=20 > Regards, >=20 > Christer From nobody Sun Jan 28 23:31:23 2018 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E86D1316F7; Sun, 28 Jan 2018 23:31:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Qin Wu To: Cc: draft-ietf-ice-rfc5245bis.all@ietf.org, ietf@ietf.org, ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151721108111.3093.7915132093422888914@ietfa.amsl.com> Date: Sun, 28 Jan 2018 23:31:21 -0800 Archived-At: Subject: [Ice] Opsdir last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 07:31:21 -0000 Reviewer: Qin Wu Review result: Ready I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed: draft-ietf-ice-rfc5245bis-16 Summary: This document defines ICE protocol for NAT traversal in the UDP-based communication. The draft is well written, especially operational consideration section and security section. I believe it is ready for publication. Major issue: None Minor issue: Editorial 1.This draft discuss the difference between ICE and ICE difference in many places, e.g., “ 17.3. ICE and ICE-lite Deployments utilizing a mix of ICE and ICE-lite interoperate perfectly. They have been explicitly designed to do so, without loss of function. “ “ 4. Terminology Full Implementation: An ICE implementation that performs the complete set of functionality defined by this specification. Lite Implementation: An ICE implementation that omits certain functions, implementing only as much as is necessary for a peer implementation that is full to gain the benefits of ICE. Lite implementations do not maintain any of the state machines and do not generate connectivity checks. “ “ Appendix A. Lite and Full Implementations ICE allows for two types of implementations. A full implementation supports the controlling and controlled roles in a session, and can also perform address gathering. In contrast, a lite implementation is a minimalist implementation that does little but respond to STUN checks. “ I would suggest to make them consistent, e.g., in section 17.3, it mentions that deploying combination of ICE and ICE-Lite can be designed to interoperate perfect without loss of function, however ICE-Lite in section 4 is defines as one implementation that could omit some of function. Also I want to know whether lite implementation supports the controlling and controlled roles in Appendix A. 2. Section 17.2.2 said: " The gathering phase and the connectivity check phase are meant to generate traffic at roughly the same bandwidth as the data traffic itself. " " Of course, the ICE checks will cause a marginal increase in the total utilization; however, this will typically be an extremely small increase. " I am wondering whether generated traffic in the first sentence is referred to connectivity check signaling traffic+ gathering signaling traffic+ user data traffic, in other words, whether connectivity check signaling traffic+ gathering signaling traffic can be ignored comparing with the total volume of data traffic? 3. Section 19.4.1 said: “ 19.4.1. STUN Amplification Attack he STUN amplification attack is similar to a "voice hammer" attack, “ s/he STUN amplification attack/The STUN amplification attack From nobody Mon Jan 29 00:57:09 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB88131782; Mon, 29 Jan 2018 00:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSNChHU16VaA; Mon, 29 Jan 2018 00:56:50 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D9A13176A; Mon, 29 Jan 2018 00:56:09 -0800 (PST) X-AuditID: c1b4fb30-11d5e9c000006bc7-87-5a6ee1a71eae Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 96.7D.27591.7A1EE6A5; Mon, 29 Jan 2018 09:56:07 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Mon, 29 Jan 2018 09:56:06 +0100 From: Christer Holmberg To: Qin Wu , "ops-dir@ietf.org" CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-ice-rfc5245bis-16 Thread-Index: AQHTmNMqK/aCiONLJUGo7wTEPWPJ26OKoFAA Date: Mon, 29 Jan 2018 08:56:05 +0000 Message-ID: References: <151721108111.3093.7915132093422888914@ietfa.amsl.com> In-Reply-To: <151721108111.3093.7915132093422888914@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <335E550DCAF8574CA5A48D3568A5F0CE@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM2K7tO7yh3lRBg9aFC0ez13AanH8xx92 i28Xai2ebZzPYtHbtITZgdWj5chbVo8lS34yBTBFcdmkpOZklqUW6dslcGV8f2xcMEmxYsL/ ncwNjDOkuhg5OSQETCT23p/C0sXIxSEkcJhR4tyjeVDOEkaJA3M3s3UxcnCwCVhIdP/TBmkQ EXCTuL1pHxtIDbPATEaJ1z9fMoIkhAVcJNrfdTFDFLlK/Ho6lxHCNpL4vPAjWJxFQFVi1b+N rCAzeQWsJd4/CAYJCwk4SZyc0sQCYnMKOEs8mL+ADcRmFBCT+H5qDROIzSwgLnHryXwmiKMF JJbsOc8MYYtKvHz8jxXEFhXQk9hw4jY7RFxJ4seGSywQvXoSN6ZOAXuFGWjt19N6EGFtiWUL X4ON4RUQlDg58wnLBEbxWUi2zULSPQuhexaS7llIuhcwsq5iFC1OLU7KTTcy0kstykwuLs7P 08tLLdnECIzCg1t+G+xgfPnc8RCjAAejEg9v/4m8KCHWxLLiytxDjBIczEoivPcKgUK8KYmV ValF+fFFpTmpxYcYpTlYlMR5T3ryRgkJpCeWpGanphakFsFkmTg4pRoYl534He+iMG1KlsVU 2cbgilOHI/Mn7Pu1r+rrlVNbKjoi/pzfJP3zWr1njMzsdTdX2CbPT1Uw/Jzcfa1d+fq5Bhep 6knh979tz8zXK3XOPTpjTZzM3rLVLxbXW64NdJN0vnsnnfMw89wvT4y/7Jkza+vqE5KrX8T9 yhW5uKpEKlPXvGePkA6bkxJLcUaioRZzUXEiAOaSoRC+AgAA Archived-At: Subject: Re: [Ice] Opsdir last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 08:56:53 -0000 Hi Qin, Thank You for the review! Please see inline. >Summary: >This document defines ICE protocol for NAT traversal in the UDP-based >communication. The draft is well written, especially operational >consideration >section and security section. I believe it is ready for publication. > >Major issue: None >Minor issue: Editorial >1.This draft discuss the difference between ICE and ICE difference in many >places, e.g., =B3 17.3. ICE and ICE-lite > > Deployments utilizing a mix of ICE and ICE-lite interoperate > perfectly. They have been explicitly designed to do so, without loss > of function. >=B3 >=B3 >4. Terminology > > Full Implementation: An ICE implementation that performs the > complete set of functionality defined by this specification. > > Lite Implementation: An ICE implementation that omits certain > functions, implementing only as much as is necessary for a peer > implementation that is full to gain the benefits of ICE. Lite > implementations do not maintain any of the state machines and do > not generate connectivity checks. >=B3 >=B3 >Appendix A. Lite and Full Implementations > > ICE allows for two types of implementations. A full implementation > supports the controlling and controlled roles in a session, and can > also perform address gathering. In contrast, a lite implementation > is a minimalist implementation that does little but respond to STUN > checks. >=B3 >I would suggest to make them consistent, e.g., in section 17.3, it >mentions >that deploying combination of ICE and ICE-Lite can be designed to >interoperate >perfect without loss of function, however ICE-Lite in section 4 is >defines as >one implementation that could omit some of function. I think the =B3without loss of function=B2 part is a little misleading, as = the lite implementation will not perform certain tasks. I suggest to simply say: "Deployments utilizing a mix of ICE and ICE-lite interoperate perfectly. They have been explicitly designed to do so." >Also I want to know whether lite implementation supports the controlling >and >controlled roles in Appendix A. I suggest to modify the following sentence: OLD: "In contrast, a lite implementation is a minimalist implementation that does little but respond to STUN checks.=B2 NEW: "In contrast, a lite implementation only is a minimalist implementation that does little but respond to STUN Checks, and only supports the controlled role in a session.=B2 --- >2. Section 17.2.2 said: >" >The gathering phase and the connectivity > check phase are meant to generate traffic at roughly the same > bandwidth as the data traffic itself. >" >" > Of course, the ICE > checks will cause a marginal increase in the total utilization; > however, this will typically be an extremely small increase. >" >I am wondering whether generated traffic in the first sentence is >referred to >connectivity check signaling traffic+ gathering signaling traffic+ user >data >traffic, in other words, whether connectivity check signaling traffic+ >gathering signaling traffic can be ignored comparing with the total >volume of >data traffic? The intension is to say that the ICE process (gathering and connectivity check) will not consume more bandwidth than, once ICE has concluded, the data itself. Would the following modified sentence be more clear? "The gathering phase and the connectivity check phase are meant to generate traffic at roughly the same bandwidth as the data traffic itself will consume once the ICE process conclude.=B2 I also think the second sentence could be clarified: =B3Once ICE has concluded, the subsequent ICE keep-alives will later cause a marginal increase in the total bandwidth utilization; however, this will typically be an extremely small increase." --- >3. Section 19.4.1 said: >=B3 >19.4.1. STUN Amplification Attack > > he STUN amplification attack is similar to a "voice hammer" attack, >=B3 >s/he STUN amplification attack/The STUN amplification attack Will fix as suggested. Regards, Christer From nobody Mon Jan 29 07:38:22 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C2B126DCA; Mon, 29 Jan 2018 07:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-hLbWewh5ca; Mon, 29 Jan 2018 07:38:16 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181E212025C; Mon, 29 Jan 2018 07:38:14 -0800 (PST) X-AuditID: c1b4fb2d-b35ff70000007932-63-5a6f3fe5e224 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 75.61.31026.5EF3F6A5; Mon, 29 Jan 2018 16:38:13 +0100 (CET) Received: from [100.94.50.217] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.60) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 29 Jan 2018 16:38:12 +0100 To: , , From: Magnus Westerlund Message-ID: <05d4e10e-e326-32b9-a324-db833a2e57f9@ericsson.com> Date: Mon, 29 Jan 2018 16:38:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070008020603050003030508" X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM2K7je5T+/wog8YlfBbHf/xht/h2odZi 1p5FLA7MHkuW/GQKYIzisklJzcksSy3St0vgynj+cA9zwaTait0vJrM0MC7K6WLk4JAQMJE4 9zGii5GTQ0jgMKPE1B6fLkYuIHsTo8T5mc3MIAkRgSCJDXt+s4DYbAIWEjd/NLKB2MICXhKN vw6D1fAK2Ev8vjSRCWQmi4CqxLpHZSBhUYEYiQXNh6BKBCVOznzCAjKfWaCbUaLl6D0WiMXa Eg1NHawgtoSAksT1eddZJjDyzkLSMwtZD0iCWcBW4s7c3cwQtrbEsoWvoWxxiaYvK1khbGuJ Gb8OskHYihJTuh+yQ9imEq+PfmSEsI0k3u1pZF/AyLmKUbQ4tbg4N93IWC+1KDO5uDg/Ty8v tWQTIzC4D275rbuDcfVrx0OMAhyMSjy8qjr5UUKsiWXFlbmHGFWA5jzasPoCoxRLXn5eqpII 773CvCgh3pTEyqrUovz4otKc1OJDjNIcLErivCc9eaOEBNITS1KzU1MLUotgskwcnFINjJEu Mfc4f5ilBnateGW359LFOxappRdnfuF/31e0eeHS7PbjaufD7I2CtbZk8kjXXJ9+w+BoS8D6 6c0sRmfXXWF+prHQ1YpTsuFGodTj+To2zJ/2THux5MzG9C9Ntuf2vvzOP2X7c6+gzshXSSuO B1b8eby24PqU2O6ot2LetxPiDl98vmsbR6wSS3FGoqEWc1FxIgAxyLKGdgIAAA== Archived-At: Subject: [Ice] TSV-ART Review of draft-ietf-ice-rfc5245bis-16 (Not complete yet) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 15:38:20 -0000 --------------ms070008020603050003030508 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-GB I've reviewed this document as part of the transport area directorate's=20 ongoing effort to review key IETF documents. These comments were written = primarily for the transport area directors, but are copied to the=20 document's authors for their information and to allow them to address=20 any issues raised. When done at the time of IETF Last Call, the authors=20 should consider this review together with any other last-call comments=20 they receive. Please always CC tsv-dir@=85 if you reply to or forward thi= s=20 review. Unfortunately there was an error in the datatracker that resulted in=20 that review requests was not timely sent. Thus, I got this request the=20 day before the deadline. Therefore I am late with the review. Also, I=20 have not yet completed it. I have only reviewed the document to end of=20 section 7. So I send this out now for heads up, and intended to update=20 it the next few days. I know that this is an update to an published RFC. But, I have reviewed=20 it on a general level without considering what is changed or not. This draft is on the right track but has open issues, described in the=20 review. Significant Issues: A. Section 5.2: =A0=A0 Lite implementations only utilize host candidates.=A0 A lite =A0=A0 implementation MUST, for each component of each data stream, allo= cate =A0=A0 zero or one IPv4 candidates.=A0 It MAY allocate zero or more IPv6= =A0=A0 candidates, but no more than one per each IPv6 address utilized b= y =A0=A0 the host.=A0 Since there can be no more than one IPv4 candidate p= er =A0=A0 component of each data stream, if an ICE agent has multiple IPv4 =A0=A0 addresses, it MUST choose one for allocating the candidate.=A0 If= a =A0=A0 host is dual-stack, it is RECOMMENDED that it allocate one IPv4 =A0=A0 candidate and one global IPv6 address.=A0 With the lite implement= ation, =A0=A0 ICE cannot be used to dynamically choose amongst candidates. =A0=A0 Therefore, including more than one candidate from a particular sc= ope =A0=A0 is NOT RECOMMENDED, since only a connectivity check can truly =A0=A0 determine whether to use one address or the other. I find it quite strange that the above text says there can only be=20 single IPv4 based candidate, while for IPv6 a LITE implementation may=20 have one candidate per IPv6 address. Isn't the LITE implication of=20 having multiple candidates for the same address family similar? Yes,=20 IPv6 kind of forces the need for dealing with multiple IPv6 addresses on = any host. However, I can see that certain servers will actually be=20 multi-homed in IPv4 and thus can in a sensible way actually have=20 multiple IPv4 candidates, and let the clients select which interface has = the best reachability. Can you please be explicit on what in ICE prevents things to work for=20 IPv4 but the same case works for IPv6? B. Section 6.1.1: =A0=A0 An agent MUST be prepared that the peer might re-determine the ro= les =A0=A0 as part of any ICE restart, even if the criteria for doing so are= not =A0=A0 fulfilled.=A0 This can happen if the peer is compliant with an ol= der =A0=A0 version of this specification. What does it mean to be prepared for a peer that re-determine the roles? = What is it one MUST do? If the peer changes its role upon an ICE=20 restart, isn't that going to result in a role mismatch? Thus causing yet = another ICE restart, where also this peer will re-evalute? Isn't that=20 good enough? Or is it something else it can do? C. Section 6.1.3: =A0=A0 The ICE agent has a state determined by the state of the check li= sts. =A0=A0 The state is Completed if all check lists are Completed, Failed i= f =A0=A0 all check lists are Failed, and Running otherwise. Does failed really require all the checklists to fail, or simply any to=20 fail if the others are completed? D. Section 6.1.4.2: I don't know if I misunderstand the algorithm here in the bullet list.=20 To me it appears that it will terminate prior to have initiated all=20 possible tests, as it appears that it will not unfreeze some of the=20 candidate pairs. If one have tests running for a foundation, but all=20 other candidate checks have been started, then the steps are aborted. Is = the bullet list rechecked every Ta? E. Section 7.2.5.2.2.=A0 ICMP Error =A0=A0 An ICE agent MAY support processing of ICMP errors for connectivi= ty =A0=A0 checks.=A0 If the agent supports processing of ICMP errors, and i= f a =A0=A0 Binging request generates an ICMP error, the agent SHOULD set the= =A0=A0 state of the candidate pair to Failed. I am a bit worried by this blanket statement on ICMP errors. I think it=20 should be clarified which ICMP message types that are relevant to=20 consider as errors? I assume Type 3 (Destination Unreachable) but maybe=20 not all responde codes as Codes 4, 11,12 may be addressable in other=20 ways, and likely Type 11 (Time exceeded) with response code 0, response=20 code 1 is not a clear indication of a non working path. F. Section 7.2.5.2.3.=A0 Timeout =A0=A0 If the Binding request times out, the ICE agent MUST set the =A0=A0 candidate pair state to Failed. Isn't this erroneous? Timeout for the connectivity check is happening=20 when all the (re-)transmissions have timed out, isn't it? or as simple=20 as missing the word "transaction"? Minor/Editorial Issues: 1.=A0 Section 5.1.2: This section doesn't make it clear that higher priority values are more=20 prioritized over lower values. That really should be defined here. Now=20 that information only becomes evident implicitly in section 5.1.2.1. 2. Section 2.1. =A0=A0 In order to execute ICE, an ICE agent has to identify all of its =A0=A0 address candidates. I think this sentence is raising a too high requirement. An ICE agent=20 has attempt to identify as many of the address candidates as possible.=20 The better coverage of the potential candidates the more likely it is to = function. I would also argue that there are multiple cases where you=20 will not figure out that there are candidates that you don't know about. = An obvious example is in cases of two NATs between the local address=20 realm and the STUN server, the agent can't figure out that there was an=20 address given to the flow in the middle address realm between the two=20 NATs. That can be only learn if the agent has a STUN server in that=20 address realm. Secondly, there are cases where policy may be applied to=20 exclude certain interfaces and their related candidates. I also noted that this first paragraph and the second has a strange=20 relation. The first part of first paragraph is general, then there is=20 the part of the host candidate. Then the second part starts with STUN=20 and TURN derived candidates. Maybe the first paragraph should be split=20 between the general and the host part, or some other bridging is needed. 3. Section 2.3: If the transactions above succeed, the agents will set =A0=A0 the nominated flag for the pairs, and will cancel any future chec= ks =A0=A0 for that component of the data stream. Although what is stated is normal, it is not guaranteed to happen, I=20 know this is intended as a simplified overview, but ignoring that there=20 can occur some shuffling back and forth if high priority checks complete = after low priority ones should at least be hinted or at least allowed by = the use of words. 4. Section 3. As RFC 7825 do describe a significant enough different usage of ICE from = SIP, I think it would be good to actually included an informational=20 reference to this usage. 5. Section 5.1.1.4: An ICE agent SHOULD =A0=A0 monitor the interfaces it uses, invalidate candidates whose base = has =A0=A0 gone away, and acquire new candidates as appropriate when new =A0=A0 interfaces appear. I am missing discussion of new addresses here. If the base disappears,=20 it might be that there is a new IP address that one should use. That=20 doesn't necessary imply a new interface. 6. Section 7.2.5.1: =A0=A0 If the Binding request generates a 487 (Role Conflict) error =A0=A0 response, and if the ICE agent included an ICE-CONTROLLED attribu= te =A0=A0 in the request, the agent MUST switch to the controlling role. If= =A0=A0 the agent included an ICE-CONTROLLING attribute in the request, t= he =A0=A0 agent MUST switch to the controlled role. I think the first sentence should have a forward reference to Section=20 7.3.1.1 where the rest of the solution is described. 7. Section 7.3: If the agent is using Diffserv Codepoint markings [RFC2475] in its =A0=A0 data packets, it SHOULD apply the same markings to Binding respon= ses. I find this sentence a bit unclear. Is it intended to say: If the agent receiving the binding request, intended to use DSCP=20 markings !=3D0 for the data, it SHOULD set, the same marking to binding=20 responses. or If the agent receives a binding request with DSCP markings, then it=20 should apply to corresponding code point when forming the binding respons= e? There are unclarity of which agent is referenced and whom "it" is in the = sentence. Cheers Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------ms070008020603050003030508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME-kryptografisk signatur MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DNEwggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNV BAoMCEVyaWNzc29uMRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJ ARYebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+ laqg5eXTqonqnzT9ykEGL2dx9mBT+2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJ HGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iV IiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpigGFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36o gzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkrbdmdnjKGrYSnJigmxw14pJugxL/Vb2Ee VcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDov L2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCBggYI KwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29t MEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29u bmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJp Y3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0 dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQG CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3 DQEBCwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4Q ihhoQR3cvhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXD yF9mhWYbSAkJyx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6 H3zO3nsq++KBmsOiSKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvE lup5n7l864FqxnC2friDo4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl 60rmc8SJlt6QXKw0wXEOE1MubauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwD ig3SZi1qP7D/Ds4V+JLIjjUJc25l9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8K v7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLCQaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3 UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Zla71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzY VBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd//n4YbY2QhDCCBsIwggSqoAMCAQICEFO4 foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUx MDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw ggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfS Tm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbX ILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfp VdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2 PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2 H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4 rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX 1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjv Zibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FN VSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoGCCsG AQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEu Y29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5j b20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAE TjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnku dHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3Js LTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7 GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDU JQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHG vw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYn nl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwf ixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ8 5AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4Hd Dc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOE EHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd 3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/du jp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDGCAzswggM3AgEB MFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMA0GCWCGSAFlAwQCAQUA oIIBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAxMjkx NTM4MTJaMC8GCSqGSIb3DQEJBDEiBCCLZ/t5kb7GmP6zoscS/E/KzJF+0dkECbVlQQpXEns+ cjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBlrrZreXF5 7TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMGwGCyqGSIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nz b24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62 a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAT48fkxziAM5aOoDeOmCa9QSxTiSQ/XT3lQE/ZIdN /BWf8/w/Z9szWujd/xUqGMN2R8Gp+iIDD/cGX+530NwHO7OueFM5zWgPHJ6dKhqEkqoOEpC0 GQ4soSgLFMS1uEe7Wlnovb529aIpl03r149BSW+NRtGS7Y7s2hMaOD18zTAWaHpEWSVGRQrS B39b/HZnwUBaWSXklcCpXSQD9Ba/rYJ2rqGXEEsH6jEum9MqdsXs1rSOooe1HLq2t9VDr7vN kzWXvY4TytpcX5oa3rAkgm+lVR3vd/HEpy4Nh9j3N/IcYE6PGxvWuQ9pV6L07quh9lbv8Dii NjIKD8yFyvEIiwAAAAAAAA== --------------ms070008020603050003030508-- From nobody Mon Jan 29 18:53:48 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06361273E2; Mon, 29 Jan 2018 18:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8LBhTMPQaAu; Mon, 29 Jan 2018 18:53:40 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91A41314D6; Mon, 29 Jan 2018 18:53:39 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 093A72D2E7BBC; Tue, 30 Jan 2018 02:53:36 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 30 Jan 2018 02:53:37 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.231]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Tue, 30 Jan 2018 10:53:30 +0800 From: Qin Wu To: Christer Holmberg , "ops-dir@ietf.org" CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-ice-rfc5245bis-16 Thread-Index: AQHTmN8FNcBNiXVxRUW6BrVhA9ymqKOLuRLg Date: Tue, 30 Jan 2018 02:53:29 +0000 Message-ID: References: <151721108111.3093.7915132093422888914@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.67] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ice] Opsdir last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 02:53:42 -0000 VGhhbmtzIENocmlzdGVyLCB5b3UgYWRkcmVzcyBteSBjb21tZW50cy4NCg0KLVFpbg0KLS0tLS3p gq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBDaHJpc3RlciBIb2xtYmVyZyBbbWFpbHRvOmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbV0gDQrlj5HpgIHml7bpl7Q6IDIwMTjlubQx5pyI Mjnml6UgMTY6NTYNCuaUtuS7tuS6ujogUWluIFd1OyBvcHMtZGlyQGlldGYub3JnDQrmioTpgIE6 IGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXMuYWxsQGlldGYub3JnOyBpZXRmQGlldGYub3JnOyBp Y2VAaWV0Zi5vcmcNCuS4u+mimDogUmU6IE9wc2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0 LWlldGYtaWNlLXJmYzUyNDViaXMtMTYNCg0KSGkgUWluLA0KDQpUaGFuayBZb3UgZm9yIHRoZSBy ZXZpZXchIFBsZWFzZSBzZWUgaW5saW5lLg0KDQo+U3VtbWFyeToNCj5UaGlzIGRvY3VtZW50IGRl ZmluZXMgSUNFIHByb3RvY29sIGZvciBOQVQgdHJhdmVyc2FsIGluIHRoZSBVRFAtYmFzZWQgDQo+ Y29tbXVuaWNhdGlvbi4gVGhlIGRyYWZ0IGlzIHdlbGwgd3JpdHRlbiwgZXNwZWNpYWxseSBvcGVy YXRpb25hbCANCj5jb25zaWRlcmF0aW9uIHNlY3Rpb24gYW5kIHNlY3VyaXR5IHNlY3Rpb24uIEkg YmVsaWV2ZSBpdCBpcyByZWFkeSBmb3IgDQo+cHVibGljYXRpb24uDQo+DQo+TWFqb3IgaXNzdWU6 IE5vbmUNCj5NaW5vciBpc3N1ZTogRWRpdG9yaWFsDQo+MS5UaGlzIGRyYWZ0IGRpc2N1c3MgdGhl IGRpZmZlcmVuY2UgYmV0d2VlbiBJQ0UgYW5kIElDRSBkaWZmZXJlbmNlIGluIA0KPm1hbnkgcGxh Y2VzLCBlLmcuLCDCsyAxNy4zLiAgSUNFIGFuZCBJQ0UtbGl0ZQ0KPg0KPiAgIERlcGxveW1lbnRz IHV0aWxpemluZyBhIG1peCBvZiBJQ0UgYW5kIElDRS1saXRlIGludGVyb3BlcmF0ZQ0KPiAgIHBl cmZlY3RseS4gIFRoZXkgaGF2ZSBiZWVuIGV4cGxpY2l0bHkgZGVzaWduZWQgdG8gZG8gc28sIHdp dGhvdXQgbG9zcw0KPiAgIG9mIGZ1bmN0aW9uLg0KPsKzDQo+wrMNCj40LiAgVGVybWlub2xvZ3kN Cj4NCj4gICBGdWxsIEltcGxlbWVudGF0aW9uOiAgQW4gSUNFIGltcGxlbWVudGF0aW9uIHRoYXQg cGVyZm9ybXMgdGhlDQo+ICAgICAgY29tcGxldGUgc2V0IG9mIGZ1bmN0aW9uYWxpdHkgZGVmaW5l ZCBieSB0aGlzIHNwZWNpZmljYXRpb24uDQo+DQo+ICAgTGl0ZSBJbXBsZW1lbnRhdGlvbjogIEFu IElDRSBpbXBsZW1lbnRhdGlvbiB0aGF0IG9taXRzIGNlcnRhaW4NCj4gICAgICBmdW5jdGlvbnMs IGltcGxlbWVudGluZyBvbmx5IGFzIG11Y2ggYXMgaXMgbmVjZXNzYXJ5IGZvciBhIHBlZXINCj4g ICAgICBpbXBsZW1lbnRhdGlvbiB0aGF0IGlzIGZ1bGwgdG8gZ2FpbiB0aGUgYmVuZWZpdHMgb2Yg SUNFLiAgTGl0ZQ0KPiAgICAgIGltcGxlbWVudGF0aW9ucyBkbyBub3QgbWFpbnRhaW4gYW55IG9m IHRoZSBzdGF0ZSBtYWNoaW5lcyBhbmQgZG8NCj4gICAgICBub3QgZ2VuZXJhdGUgY29ubmVjdGl2 aXR5IGNoZWNrcy4NCj7Csw0KPsKzDQo+QXBwZW5kaXggQS4gIExpdGUgYW5kIEZ1bGwgSW1wbGVt ZW50YXRpb25zDQo+DQo+ICAgSUNFIGFsbG93cyBmb3IgdHdvIHR5cGVzIG9mIGltcGxlbWVudGF0 aW9ucy4gIEEgZnVsbCBpbXBsZW1lbnRhdGlvbg0KPiAgIHN1cHBvcnRzIHRoZSBjb250cm9sbGlu ZyBhbmQgY29udHJvbGxlZCByb2xlcyBpbiBhIHNlc3Npb24sIGFuZCBjYW4NCj4gICBhbHNvIHBl cmZvcm0gYWRkcmVzcyBnYXRoZXJpbmcuICBJbiBjb250cmFzdCwgYSBsaXRlIGltcGxlbWVudGF0 aW9uDQo+ICAgaXMgYSBtaW5pbWFsaXN0IGltcGxlbWVudGF0aW9uIHRoYXQgZG9lcyBsaXR0bGUg YnV0IHJlc3BvbmQgdG8gU1RVTg0KPiAgIGNoZWNrcy4NCj7Csw0KPkkgd291bGQgc3VnZ2VzdCB0 byBtYWtlIHRoZW0gY29uc2lzdGVudCwgZS5nLiwgaW4gc2VjdGlvbiAxNy4zLCBpdCANCj5tZW50 aW9ucyB0aGF0IGRlcGxveWluZyBjb21iaW5hdGlvbiBvZiBJQ0UgYW5kIElDRS1MaXRlIGNhbiBi ZSBkZXNpZ25lZCANCj50byBpbnRlcm9wZXJhdGUgcGVyZmVjdCB3aXRob3V0IGxvc3Mgb2YgZnVu Y3Rpb24sIGhvd2V2ZXIgSUNFLUxpdGUgaW4gDQo+c2VjdGlvbiA0IGlzIGRlZmluZXMgYXMgb25l IGltcGxlbWVudGF0aW9uIHRoYXQgY291bGQgb21pdCBzb21lIG9mIA0KPmZ1bmN0aW9uLg0KDQpJ IHRoaW5rIHRoZSDCs3dpdGhvdXQgbG9zcyBvZiBmdW5jdGlvbsKyIHBhcnQgaXMgYSBsaXR0bGUg bWlzbGVhZGluZywgYXMgdGhlIGxpdGUgaW1wbGVtZW50YXRpb24gd2lsbCBub3QgcGVyZm9ybSBj ZXJ0YWluIHRhc2tzLg0KDQpJIHN1Z2dlc3QgdG8gc2ltcGx5IHNheToNCg0KICJEZXBsb3ltZW50 cyB1dGlsaXppbmcgYSBtaXggb2YgSUNFIGFuZCBJQ0UtbGl0ZSBpbnRlcm9wZXJhdGUNCiAgcGVy ZmVjdGx5LiAgVGhleSBoYXZlIGJlZW4gZXhwbGljaXRseSBkZXNpZ25lZCB0byBkbyBzby4iDQoN Cg0KPkFsc28gSSB3YW50IHRvIGtub3cgd2hldGhlciBsaXRlIGltcGxlbWVudGF0aW9uIHN1cHBv cnRzIHRoZSANCj5jb250cm9sbGluZyBhbmQgY29udHJvbGxlZCByb2xlcyBpbiBBcHBlbmRpeCBB Lg0KDQpJIHN1Z2dlc3QgdG8gbW9kaWZ5IHRoZSBmb2xsb3dpbmcgc2VudGVuY2U6DQoNCk9MRDoN Cg0KICAgIkluIGNvbnRyYXN0LCBhIGxpdGUgaW1wbGVtZW50YXRpb24gaXMgYSBtaW5pbWFsaXN0 IGltcGxlbWVudGF0aW9uIHRoYXQgZG9lcyBsaXR0bGUgYnV0IHJlc3BvbmQgdG8gU1RVTg0KICAg IGNoZWNrcy7Csg0KDQoNCk5FVzoNCg0KICAgIkluIGNvbnRyYXN0LCBhIGxpdGUgaW1wbGVtZW50 YXRpb24gb25seSBpcyBhIG1pbmltYWxpc3QgaW1wbGVtZW50YXRpb24gdGhhdCBkb2VzIGxpdHRs ZSBidXQgcmVzcG9uZCB0byBTVFVODQogICAgQ2hlY2tzLCBhbmQgb25seSBzdXBwb3J0cyB0aGUg Y29udHJvbGxlZCByb2xlIGluIGEgc2Vzc2lvbi7Csg0KDQoNCi0tLQ0KDQoNCj4yLiBTZWN0aW9u IDE3LjIuMiBzYWlkOg0KPiINCj5UaGUgZ2F0aGVyaW5nIHBoYXNlIGFuZCB0aGUgY29ubmVjdGl2 aXR5DQo+ICAgY2hlY2sgcGhhc2UgYXJlIG1lYW50IHRvIGdlbmVyYXRlIHRyYWZmaWMgYXQgcm91 Z2hseSB0aGUgc2FtZQ0KPiAgIGJhbmR3aWR0aCBhcyB0aGUgZGF0YSB0cmFmZmljIGl0c2VsZi4N Cj4iDQo+Ig0KPiAgIE9mIGNvdXJzZSwgdGhlIElDRQ0KPiAgIGNoZWNrcyB3aWxsIGNhdXNlIGEg bWFyZ2luYWwgaW5jcmVhc2UgaW4gdGhlIHRvdGFsIHV0aWxpemF0aW9uOw0KPiAgIGhvd2V2ZXIs IHRoaXMgd2lsbCB0eXBpY2FsbHkgYmUgYW4gZXh0cmVtZWx5IHNtYWxsIGluY3JlYXNlLg0KPiIN Cj5JIGFtIHdvbmRlcmluZyB3aGV0aGVyIGdlbmVyYXRlZCB0cmFmZmljIGluIHRoZSBmaXJzdCBz ZW50ZW5jZSBpcyANCj5yZWZlcnJlZCB0byBjb25uZWN0aXZpdHkgY2hlY2sgc2lnbmFsaW5nIHRy YWZmaWMrIGdhdGhlcmluZyBzaWduYWxpbmcgDQo+dHJhZmZpYysgdXNlciBkYXRhIHRyYWZmaWMs IGluIG90aGVyIHdvcmRzLCB3aGV0aGVyIGNvbm5lY3Rpdml0eSBjaGVjayANCj5zaWduYWxpbmcg dHJhZmZpYysgZ2F0aGVyaW5nIHNpZ25hbGluZyB0cmFmZmljIGNhbiBiZSBpZ25vcmVkIGNvbXBh cmluZyANCj53aXRoIHRoZSB0b3RhbCB2b2x1bWUgb2YgZGF0YSB0cmFmZmljPw0KDQoNClRoZSBp bnRlbnNpb24gaXMgdG8gc2F5IHRoYXQgdGhlIElDRSBwcm9jZXNzIChnYXRoZXJpbmcgYW5kIGNv bm5lY3Rpdml0eQ0KY2hlY2spIHdpbGwgbm90IGNvbnN1bWUgbW9yZSBiYW5kd2lkdGggdGhhbiwg b25jZSBJQ0UgaGFzIGNvbmNsdWRlZCwgdGhlIGRhdGEgaXRzZWxmLg0KDQpXb3VsZCB0aGUgZm9s bG93aW5nIG1vZGlmaWVkIHNlbnRlbmNlIGJlIG1vcmUgY2xlYXI/DQoNCiAiVGhlIGdhdGhlcmlu ZyBwaGFzZSBhbmQgdGhlIGNvbm5lY3Rpdml0eSBjaGVjayBwaGFzZSBhcmUgbWVhbnQgdG8gZ2Vu ZXJhdGUgdHJhZmZpYyBhdCByb3VnaGx5IHRoZSBzYW1lDQogIGJhbmR3aWR0aCBhcyB0aGUgZGF0 YSB0cmFmZmljIGl0c2VsZiB3aWxsIGNvbnN1bWUgb25jZSB0aGUgSUNFIHByb2Nlc3MgY29uY2x1 ZGUuwrINCg0KDQpJIGFsc28gdGhpbmsgdGhlIHNlY29uZCBzZW50ZW5jZSBjb3VsZCBiZSBjbGFy aWZpZWQ6DQoNCiDCs09uY2UgSUNFIGhhcyBjb25jbHVkZWQsIHRoZSBzdWJzZXF1ZW50IElDRSBr ZWVwLWFsaXZlcyB3aWxsIGxhdGVyIGNhdXNlIGEgbWFyZ2luYWwgaW5jcmVhc2UgaW4gdGhlIHRv dGFsIGJhbmR3aWR0aCB1dGlsaXphdGlvbjsNCiAgaG93ZXZlciwgdGhpcyB3aWxsIHR5cGljYWxs eSBiZSBhbiBleHRyZW1lbHkgc21hbGwgaW5jcmVhc2UuIg0KDQoNCi0tLQ0KDQo+My4gU2VjdGlv biAxOS40LjEgc2FpZDoNCj7Csw0KPjE5LjQuMS4gIFNUVU4gQW1wbGlmaWNhdGlvbiBBdHRhY2sN Cj4NCj4gICBoZSBTVFVOIGFtcGxpZmljYXRpb24gYXR0YWNrIGlzIHNpbWlsYXIgdG8gYSAidm9p Y2UgaGFtbWVyIiBhdHRhY2ssIA0KPsKzIHMvaGUgU1RVTiBhbXBsaWZpY2F0aW9uIGF0dGFjay9U aGUgU1RVTiBhbXBsaWZpY2F0aW9uIGF0dGFjaw0KDQoNCldpbGwgZml4IGFzIHN1Z2dlc3RlZC4N Cg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Mon Jan 29 22:57:45 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B79131628; Mon, 29 Jan 2018 22:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBHAZwjSs9YZ; Mon, 29 Jan 2018 22:57:40 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5D021315F5; Mon, 29 Jan 2018 22:57:39 -0800 (PST) X-AuditID: c1b4fb2d-f179c9c000007932-17-5a701761f590 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 61.96.31026.167107A5; Tue, 30 Jan 2018 07:57:37 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Tue, 30 Jan 2018 07:56:48 +0100 From: Christer Holmberg To: Qin Wu , "ops-dir@ietf.org" CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-ice-rfc5245bis-16 Thread-Index: AQHTmNMqK/aCiONLJUGo7wTEPWPJ26OKoFAAgAEISYCAAGi7AA== Date: Tue, 30 Jan 2018 06:56:48 +0000 Message-ID: References: <151721108111.3093.7915132093422888914@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM2J7uG6ieEGUwbIjehaP5y5gtTj+4w+7 xbcLtRbPNs5nsehtWsLswOrRcuQtq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKm9L1lLFhmXHHo xWamBsY/hl2MnBwSAiYSnzo6WbsYuTiEBA4zSjx794kNwlnCKDHhwRamLkYODjYBC4nuf9og DSICbhK3N+0Dq2EWmMko8frnS0aQhLCAi0T7uy5miCJXiV9P5zJC2E4SXza2s4LYLAKqEn2r 74HZvALWEitvfobafIBR4vD8ZcwgyzgFwiQWvWEDqWEUEJP4fmoNE4jNLCAucevJfCaIqwUk luw5zwxhi0q8fPwPbKaogJ7EhhO32SHiShI/NlxiARnJLKApsX6XPsQYa4nXnx+yQdiKElO6 H7JDnCMocXLmE5YJjOKzkGybhdA9C0n3LCTds5B0L2BkXcUoWpxaXJybbmSsl1qUmVxcnJ+n l5dasokRGIkHt/zW3cG4+rXjIUYBDkYlHl5R7oIoIdbEsuLK3EOMEhzMSiK8Iqvzo4R4UxIr q1KL8uOLSnNSiw8xSnOwKInznvTkjRISSE8sSc1OTS1ILYLJMnFwSjUwrvESrhW6mnXa37bE Vy0pcNfu1xkvpKtCG2WO2W/9+zY75kj/cb/OH/tm+fnvsn5vuV9XI5T/WPLcn7d3CnKafDfo kE52lNN7IlQyeXXkmwNHurbeW7589k97plc3z4jEzUjLPS4dvqOtc3VfeEO9n+BFTv00M4Yj e3aXpBzTb3RQ37q54/dPJZbijERDLeai4kQAP28XLcACAAA= Archived-At: Subject: Re: [Ice] Opsdir last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 06:57:43 -0000 VGhhbmsgWW91ISA6KQ0KDQpPbiAzMC8wMS8xOCAwNDo1MywgIlFpbiBXdSIgPGJpbGwud3VAaHVh d2VpLmNvbT4gd3JvdGU6DQoNCj5UaGFua3MgQ2hyaXN0ZXIsIHlvdSBhZGRyZXNzIG15IGNvbW1l bnRzLg0KPg0KPi1RaW4NCj4tLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+5Y+R5Lu25Lq6OiBDaHJp c3RlciBIb2xtYmVyZyBbbWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbV0NCj7l j5HpgIHml7bpl7Q6IDIwMTjlubQx5pyIMjnml6UgMTY6NTYNCj7mlLbku7bkuro6IFFpbiBXdTsg b3BzLWRpckBpZXRmLm9yZw0KPuaKhOmAgTogZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpcy5hbGxA aWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IGljZUBpZXRmLm9yZw0KPuS4u+mimDogUmU6IE9wc2Rp ciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXMtMTYNCj4NCj5I aSBRaW4sDQo+DQo+VGhhbmsgWW91IGZvciB0aGUgcmV2aWV3ISBQbGVhc2Ugc2VlIGlubGluZS4N Cj4NCj4+U3VtbWFyeToNCj4+VGhpcyBkb2N1bWVudCBkZWZpbmVzIElDRSBwcm90b2NvbCBmb3Ig TkFUIHRyYXZlcnNhbCBpbiB0aGUgVURQLWJhc2VkDQo+PmNvbW11bmljYXRpb24uIFRoZSBkcmFm dCBpcyB3ZWxsIHdyaXR0ZW4sIGVzcGVjaWFsbHkgb3BlcmF0aW9uYWwNCj4+Y29uc2lkZXJhdGlv biBzZWN0aW9uIGFuZCBzZWN1cml0eSBzZWN0aW9uLiBJIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9y DQo+PnB1YmxpY2F0aW9uLg0KPj4NCj4+TWFqb3IgaXNzdWU6IE5vbmUNCj4+TWlub3IgaXNzdWU6 IEVkaXRvcmlhbA0KPj4xLlRoaXMgZHJhZnQgZGlzY3VzcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVu IElDRSBhbmQgSUNFIGRpZmZlcmVuY2UgaW4NCj4+bWFueSBwbGFjZXMsIGUuZy4sIMKzIDE3LjMu ICBJQ0UgYW5kIElDRS1saXRlDQo+Pg0KPj4gICBEZXBsb3ltZW50cyB1dGlsaXppbmcgYSBtaXgg b2YgSUNFIGFuZCBJQ0UtbGl0ZSBpbnRlcm9wZXJhdGUNCj4+ICAgcGVyZmVjdGx5LiAgVGhleSBo YXZlIGJlZW4gZXhwbGljaXRseSBkZXNpZ25lZCB0byBkbyBzbywgd2l0aG91dCBsb3NzDQo+PiAg IG9mIGZ1bmN0aW9uLg0KPj7Csw0KPj7Csw0KPj40LiAgVGVybWlub2xvZ3kNCj4+DQo+PiAgIEZ1 bGwgSW1wbGVtZW50YXRpb246ICBBbiBJQ0UgaW1wbGVtZW50YXRpb24gdGhhdCBwZXJmb3JtcyB0 aGUNCj4+ICAgICAgY29tcGxldGUgc2V0IG9mIGZ1bmN0aW9uYWxpdHkgZGVmaW5lZCBieSB0aGlz IHNwZWNpZmljYXRpb24uDQo+Pg0KPj4gICBMaXRlIEltcGxlbWVudGF0aW9uOiAgQW4gSUNFIGlt cGxlbWVudGF0aW9uIHRoYXQgb21pdHMgY2VydGFpbg0KPj4gICAgICBmdW5jdGlvbnMsIGltcGxl bWVudGluZyBvbmx5IGFzIG11Y2ggYXMgaXMgbmVjZXNzYXJ5IGZvciBhIHBlZXINCj4+ICAgICAg aW1wbGVtZW50YXRpb24gdGhhdCBpcyBmdWxsIHRvIGdhaW4gdGhlIGJlbmVmaXRzIG9mIElDRS4g IExpdGUNCj4+ICAgICAgaW1wbGVtZW50YXRpb25zIGRvIG5vdCBtYWludGFpbiBhbnkgb2YgdGhl IHN0YXRlIG1hY2hpbmVzIGFuZCBkbw0KPj4gICAgICBub3QgZ2VuZXJhdGUgY29ubmVjdGl2aXR5 IGNoZWNrcy4NCj4+wrMNCj4+wrMNCj4+QXBwZW5kaXggQS4gIExpdGUgYW5kIEZ1bGwgSW1wbGVt ZW50YXRpb25zDQo+Pg0KPj4gICBJQ0UgYWxsb3dzIGZvciB0d28gdHlwZXMgb2YgaW1wbGVtZW50 YXRpb25zLiAgQSBmdWxsIGltcGxlbWVudGF0aW9uDQo+PiAgIHN1cHBvcnRzIHRoZSBjb250cm9s bGluZyBhbmQgY29udHJvbGxlZCByb2xlcyBpbiBhIHNlc3Npb24sIGFuZCBjYW4NCj4+ICAgYWxz byBwZXJmb3JtIGFkZHJlc3MgZ2F0aGVyaW5nLiAgSW4gY29udHJhc3QsIGEgbGl0ZSBpbXBsZW1l bnRhdGlvbg0KPj4gICBpcyBhIG1pbmltYWxpc3QgaW1wbGVtZW50YXRpb24gdGhhdCBkb2VzIGxp dHRsZSBidXQgcmVzcG9uZCB0byBTVFVODQo+PiAgIGNoZWNrcy4NCj4+wrMNCj4+SSB3b3VsZCBz dWdnZXN0IHRvIG1ha2UgdGhlbSBjb25zaXN0ZW50LCBlLmcuLCBpbiBzZWN0aW9uIDE3LjMsIGl0 DQo+Pm1lbnRpb25zIHRoYXQgZGVwbG95aW5nIGNvbWJpbmF0aW9uIG9mIElDRSBhbmQgSUNFLUxp dGUgY2FuIGJlIGRlc2lnbmVkDQo+PnRvIGludGVyb3BlcmF0ZSBwZXJmZWN0IHdpdGhvdXQgbG9z cyBvZiBmdW5jdGlvbiwgaG93ZXZlciBJQ0UtTGl0ZSBpbg0KPj5zZWN0aW9uIDQgaXMgZGVmaW5l cyBhcyBvbmUgaW1wbGVtZW50YXRpb24gdGhhdCBjb3VsZCBvbWl0IHNvbWUgb2YNCj4+ZnVuY3Rp b24uDQo+DQo+SSB0aGluayB0aGUgwrN3aXRob3V0IGxvc3Mgb2YgZnVuY3Rpb27CsiBwYXJ0IGlz IGEgbGl0dGxlIG1pc2xlYWRpbmcsIGFzDQo+dGhlIGxpdGUgaW1wbGVtZW50YXRpb24gd2lsbCBu b3QgcGVyZm9ybSBjZXJ0YWluIHRhc2tzLg0KPg0KPkkgc3VnZ2VzdCB0byBzaW1wbHkgc2F5Og0K Pg0KPiAiRGVwbG95bWVudHMgdXRpbGl6aW5nIGEgbWl4IG9mIElDRSBhbmQgSUNFLWxpdGUgaW50 ZXJvcGVyYXRlDQo+ICBwZXJmZWN0bHkuICBUaGV5IGhhdmUgYmVlbiBleHBsaWNpdGx5IGRlc2ln bmVkIHRvIGRvIHNvLiINCj4NCj4NCj4+QWxzbyBJIHdhbnQgdG8ga25vdyB3aGV0aGVyIGxpdGUg aW1wbGVtZW50YXRpb24gc3VwcG9ydHMgdGhlDQo+PmNvbnRyb2xsaW5nIGFuZCBjb250cm9sbGVk IHJvbGVzIGluIEFwcGVuZGl4IEEuDQo+DQo+SSBzdWdnZXN0IHRvIG1vZGlmeSB0aGUgZm9sbG93 aW5nIHNlbnRlbmNlOg0KPg0KPk9MRDoNCj4NCj4gICAiSW4gY29udHJhc3QsIGEgbGl0ZSBpbXBs ZW1lbnRhdGlvbiBpcyBhIG1pbmltYWxpc3QgaW1wbGVtZW50YXRpb24NCj50aGF0IGRvZXMgbGl0 dGxlIGJ1dCByZXNwb25kIHRvIFNUVU4NCj4gICAgY2hlY2tzLsKyDQo+DQo+DQo+TkVXOg0KPg0K PiAgICJJbiBjb250cmFzdCwgYSBsaXRlIGltcGxlbWVudGF0aW9uIG9ubHkgaXMgYSBtaW5pbWFs aXN0DQo+aW1wbGVtZW50YXRpb24gdGhhdCBkb2VzIGxpdHRsZSBidXQgcmVzcG9uZCB0byBTVFVO DQo+ICAgIENoZWNrcywgYW5kIG9ubHkgc3VwcG9ydHMgdGhlIGNvbnRyb2xsZWQgcm9sZSBpbiBh IHNlc3Npb24uwrINCj4NCj4NCj4tLS0NCj4NCj4NCj4+Mi4gU2VjdGlvbiAxNy4yLjIgc2FpZDoN Cj4+Ig0KPj5UaGUgZ2F0aGVyaW5nIHBoYXNlIGFuZCB0aGUgY29ubmVjdGl2aXR5DQo+PiAgIGNo ZWNrIHBoYXNlIGFyZSBtZWFudCB0byBnZW5lcmF0ZSB0cmFmZmljIGF0IHJvdWdobHkgdGhlIHNh bWUNCj4+ICAgYmFuZHdpZHRoIGFzIHRoZSBkYXRhIHRyYWZmaWMgaXRzZWxmLg0KPj4iDQo+PiIN Cj4+ICAgT2YgY291cnNlLCB0aGUgSUNFDQo+PiAgIGNoZWNrcyB3aWxsIGNhdXNlIGEgbWFyZ2lu YWwgaW5jcmVhc2UgaW4gdGhlIHRvdGFsIHV0aWxpemF0aW9uOw0KPj4gICBob3dldmVyLCB0aGlz IHdpbGwgdHlwaWNhbGx5IGJlIGFuIGV4dHJlbWVseSBzbWFsbCBpbmNyZWFzZS4NCj4+Ig0KPj5J IGFtIHdvbmRlcmluZyB3aGV0aGVyIGdlbmVyYXRlZCB0cmFmZmljIGluIHRoZSBmaXJzdCBzZW50 ZW5jZSBpcw0KPj5yZWZlcnJlZCB0byBjb25uZWN0aXZpdHkgY2hlY2sgc2lnbmFsaW5nIHRyYWZm aWMrIGdhdGhlcmluZyBzaWduYWxpbmcNCj4+dHJhZmZpYysgdXNlciBkYXRhIHRyYWZmaWMsIGlu IG90aGVyIHdvcmRzLCB3aGV0aGVyIGNvbm5lY3Rpdml0eSBjaGVjaw0KPj5zaWduYWxpbmcgdHJh ZmZpYysgZ2F0aGVyaW5nIHNpZ25hbGluZyB0cmFmZmljIGNhbiBiZSBpZ25vcmVkIGNvbXBhcmlu Zw0KPj53aXRoIHRoZSB0b3RhbCB2b2x1bWUgb2YgZGF0YSB0cmFmZmljPw0KPg0KPg0KPlRoZSBp bnRlbnNpb24gaXMgdG8gc2F5IHRoYXQgdGhlIElDRSBwcm9jZXNzIChnYXRoZXJpbmcgYW5kIGNv bm5lY3Rpdml0eQ0KPmNoZWNrKSB3aWxsIG5vdCBjb25zdW1lIG1vcmUgYmFuZHdpZHRoIHRoYW4s IG9uY2UgSUNFIGhhcyBjb25jbHVkZWQsIHRoZQ0KPmRhdGEgaXRzZWxmLg0KPg0KPldvdWxkIHRo ZSBmb2xsb3dpbmcgbW9kaWZpZWQgc2VudGVuY2UgYmUgbW9yZSBjbGVhcj8NCj4NCj4gIlRoZSBn YXRoZXJpbmcgcGhhc2UgYW5kIHRoZSBjb25uZWN0aXZpdHkgY2hlY2sgcGhhc2UgYXJlIG1lYW50 IHRvDQo+Z2VuZXJhdGUgdHJhZmZpYyBhdCByb3VnaGx5IHRoZSBzYW1lDQo+ICBiYW5kd2lkdGgg YXMgdGhlIGRhdGEgdHJhZmZpYyBpdHNlbGYgd2lsbCBjb25zdW1lIG9uY2UgdGhlIElDRSBwcm9j ZXNzDQo+Y29uY2x1ZGUuwrINCj4NCj4NCj5JIGFsc28gdGhpbmsgdGhlIHNlY29uZCBzZW50ZW5j ZSBjb3VsZCBiZSBjbGFyaWZpZWQ6DQo+DQo+IMKzT25jZSBJQ0UgaGFzIGNvbmNsdWRlZCwgdGhl IHN1YnNlcXVlbnQgSUNFIGtlZXAtYWxpdmVzIHdpbGwgbGF0ZXIgY2F1c2UNCj5hIG1hcmdpbmFs IGluY3JlYXNlIGluIHRoZSB0b3RhbCBiYW5kd2lkdGggdXRpbGl6YXRpb247DQo+ICBob3dldmVy LCB0aGlzIHdpbGwgdHlwaWNhbGx5IGJlIGFuIGV4dHJlbWVseSBzbWFsbCBpbmNyZWFzZS4iDQo+ DQo+DQo+LS0tDQo+DQo+PjMuIFNlY3Rpb24gMTkuNC4xIHNhaWQ6DQo+PsKzDQo+PjE5LjQuMS4g IFNUVU4gQW1wbGlmaWNhdGlvbiBBdHRhY2sNCj4+DQo+PiAgIGhlIFNUVU4gYW1wbGlmaWNhdGlv biBhdHRhY2sgaXMgc2ltaWxhciB0byBhICJ2b2ljZSBoYW1tZXIiIGF0dGFjaywNCj4+wrMgcy9o ZSBTVFVOIGFtcGxpZmljYXRpb24gYXR0YWNrL1RoZSBTVFVOIGFtcGxpZmljYXRpb24gYXR0YWNr DQo+DQo+DQo+V2lsbCBmaXggYXMgc3VnZ2VzdGVkLg0KPg0KPlJlZ2FyZHMsDQo+DQo+Q2hyaXN0 ZXINCj4NCg0K From nobody Tue Jan 30 00:40:57 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73ED1316DB; Tue, 30 Jan 2018 00:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToVT7Vhfj2SI; Tue, 30 Jan 2018 00:40:47 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B5E1316D9; Tue, 30 Jan 2018 00:40:38 -0800 (PST) X-AuditID: c1b4fb30-d31ff70000006bc7-5e-5a702f847381 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BF.2E.27591.48F207A5; Tue, 30 Jan 2018 09:40:36 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Tue, 30 Jan 2018 09:40:36 +0100 From: Christer Holmberg To: Magnus Westerlund , "ice@ietf.org" , "tsv-art@ietf.org" , "draft-ietf-ice-rfc5245bis.all@ietf.org" Thread-Topic: TSV-ART Review of draft-ietf-ice-rfc5245bis-16 (Not complete yet) Thread-Index: AQHTmRcySSD6+4mrU0S3x0N9BOZ2U6OMLcoA Date: Tue, 30 Jan 2018 08:40:35 +0000 Message-ID: References: <05d4e10e-e326-32b9-a324-db833a2e57f9@ericsson.com> In-Reply-To: <05d4e10e-e326-32b9-a324-db833a2e57f9@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.19] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3600154327_42252147" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7hG6LfkGUwdweJYvjP/6wW3y7UGsx a88iFgdmjyVLfjIFMEZx2aSk5mSWpRbp2yVwZWw8f5694PtyxorWm8INjP39jF2MnBwSAiYS r7/uZO5i5OIQEjjMKLH74nMmCGcJo8SVr3+BMhwcbAIWEt3/tEHiIgJXGSV29t1gBIkLCwRI 7J3oBTJIRCBQYubdEywQtpHEhlkvwRawCKhKtJzcDRbnFbCWmL3+FyuILSRgL9Fzuwcszing ING0aAFYnFFATOL7qTVMIDazgLjErSfzmSAOFZF4ePE0G4QtKvHy8T+welEBPYkNJ26zQ8QV JdqfNoCdxixQKTFtpz7EWkGJkzOfsExgFJmFZOoshKpZSKogSgwk/iw+xQpha0s8eXcByraW mPHrIBuErSgxpfshO4RtKvH66EfGBYwcqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjECY+3g lt8GOxhfPnc8xCjAwajEw1ulUBAlxJpYVlyZe4hRBWjOow2rLzBKseTl56UqifCKrM6PEuJN SaysSi3Kjy8qzUktPsQozcGiJM570pM3SkggPbEkNTs1tSC1CCbLxMEp1cC47MCh/9O0PpfV eTP3Orw53W3jubnb+mDakaPPDbwfLJW/qH7uad5Ll5y/D/a+P37uUOvHX293t07YafRpgjGT 9fyJrAUfFMpX83ikflf//G4BZxprvterM9qxM066fjvENv//tMDH65jerr2sp9698Yn91BWM Swyd448yqojq3eF7pD1N6sdiPSWW4oxEQy3mouJEADYdJDS9AgAA Archived-At: Subject: Re: [Ice] TSV-ART Review of draft-ietf-ice-rfc5245bis-16 (Not complete yet) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 08:40:51 -0000 --B_3600154327_42252147 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Magnus, Thank you for the review! Please see inline. >I've reviewed this document as part of the transport area directorate's >ongoing effort to review key IETF documents. These comments were written >primarily for the transport area directors, but are copied to the >document's authors for their information and to allow them to address >any issues raised. When done at the time of IETF Last Call, the authors >should consider this review together with any other last-call comments >they receive. Please always CC tsv-dir@=8A if you reply to or forward this >review. > >Unfortunately there was an error in the datatracker that resulted in >that review requests was not timely sent. Thus, I got this request the >day before the deadline. Therefore I am late with the review. Also, I >have not yet completed it. I have only reviewed the document to end of >section 7. So I send this out now for heads up, and intended to update >it the next few days. > >I know that this is an update to an published RFC. But, I have reviewed >it on a general level without considering what is changed or not. > >This draft is on the right track but has open issues, described in the >review. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Significant Issues: >A. Section 5.2: > > Lite implementations only utilize host candidates. A lite > implementation MUST, for each component of each data stream, allocate > zero or one IPv4 candidates. It MAY allocate zero or more IPv6 > candidates, but no more than one per each IPv6 address utilized by > the host. Since there can be no more than one IPv4 candidate per > component of each data stream, if an ICE agent has multiple IPv4 > addresses, it MUST choose one for allocating the candidate. If a > host is dual-stack, it is RECOMMENDED that it allocate one IPv4 > candidate and one global IPv6 address. With the lite implementation, > ICE cannot be used to dynamically choose amongst candidates. > Therefore, including more than one candidate from a particular scope > is NOT RECOMMENDED, since only a connectivity check can truly > determine whether to use one address or the other. > >I find it quite strange that the above text says there can only be >single IPv4 based candidate, while for IPv6 a LITE implementation may >have one candidate per IPv6 address. Isn't the LITE implication of >having multiple candidates for the same address family similar? Yes, >IPv6 kind of forces the need for dealing with multiple IPv6 addresses on >any host. However, I can see that certain servers will actually be >multi-homed in IPv4 and thus can in a sensible way actually have >multiple IPv4 candidates, and let the clients select which interface has >the best reachability. > >Can you please be explicit on what in ICE prevents things to work for >IPv4 but the same case works for IPv6? This is text from RFC 5245. I agree it is confusing, and unfortunately I don=B9t have a good answer. I guess my approach would be to suggest that we simply remove the restriction. There is generic text about dual-stack etc elsewhere, and I don=B9t see anything ICE lite specific. OLD: "Lite implementations only utilize host candidates. A lite implementation MUST, for each component of each data stream, allocate zero or one IPv4 candidates. It MAY allocate zero or more IPv6 candidates, but no more than one per each IPv6 address utilized by the host. Since there can be no more than one IPv4 candidate per component of each data stream, if an ICE agent has multiple IPv4 addresses, it MUST choose one for allocating the candidate. If a host is dual-stack, it is RECOMMENDED that it allocate one IPv4 candidate and one global IPv6 address. With the lite implementation, ICE cannot be used to dynamically choose amongst candidates. Therefore, including more than one candidate from a particular scope is NOT RECOMMENDED, since only a connectivity check can truly determine whether to use one address or the other." NEW: "Lite implementations only utilize host candidates. With the lite implementation, ICE cannot be used to dynamically choose amongst candidates. Therefore, including more than one candidate from a particular IP address family is NOT RECOMMENDED, since only a connectivity check can Truly determine whether to use one address or the other.=B2 --- >B. Section 6.1.1: > > An agent MUST be prepared that the peer might re-determine the roles > as part of any ICE restart, even if the criteria for doing so are not > fulfilled. This can happen if the peer is compliant with an older > version of this specification. > >What does it mean to be prepared for a peer that re-determine the roles? >What is it one MUST do? If the peer changes its role upon an ICE >restart, isn't that going to result in a role mismatch? Thus causing yet >another ICE restart, where also this peer will re-evalute? Isn't that >good enough? Or is it something else it can do? The roles are re-negotiated during the ICE restart: it may, or may not, result in a role mismatch. =B3Prepared=B2 means that the peer might change its role even though it does not fulfil the 5245bis criteria for being allowed to do so. --- >C. Section 6.1.3: > > The ICE agent has a state determined by the state of the check lists. > The state is Completed if all check lists are Completed, Failed if > all check lists are Failed, and Running otherwise. > >Does failed really require all the checklists to fail, or simply any to >fail if the others are completed? If there are one or more completed, the session can still continue. As described in section 8.1.2: "If at least one of the check lists for other data streams is Completed, the controlling agent SHOULD remove the failed data stream from the session while sending updated candidate list to its peer." --- >D. Section 6.1.4.2: > >I don't know if I misunderstand the algorithm here in the bullet list. >To me it appears that it will terminate prior to have initiated all >possible tests, as it appears that it will not unfreeze some of the >candidate pairs. If one have tests running for a foundation, but all >other candidate checks have been started, then the steps are aborted. Is >the bullet list rechecked every Ta? No. Whenever Ta fires, one check list in Running state is checked. When all check lists have been checked, it will start over from the top of the list. Or, did I misunderstand your issue? --- >E. Section 7.2.5.2.2. ICMP Error > > An ICE agent MAY support processing of ICMP errors for connectivity > checks. If the agent supports processing of ICMP errors, and if a > Binging request generates an ICMP error, the agent SHOULD set the > state of the candidate pair to Failed. > >I am a bit worried by this blanket statement on ICMP errors. I think it >should be clarified which ICMP message types that are relevant to >consider as errors? I assume Type 3 (Destination Unreachable) but maybe >not all responde codes as Codes 4, 11,12 may be addressable in other >ways, and likely Type 11 (Time exceeded) with response code 0, response >code 1 is not a clear indication of a non working path. This is from RFC 5245. I don=B9t think the ICE WG should go through all different codes and combinations, and determine what should be considered an error, and what not. If you can provide something (table, guidance etc), we are happy to include it. Otherwise I=B9d like to keep it as it is, and let implementations deal with it. --- >F. Section 7.2.5.2.3. Timeout > > If the Binding request times out, the ICE agent MUST set the > candidate pair state to Failed. > >Isn't this erroneous? Timeout for the connectivity check is happening >when all the (re-)transmissions have timed out, isn't it? or as simple >as missing the word "transaction"? Correct. I will change to =B3Binding request transaction=B2 =3D=3D=3D=3D=3D=3D=3D=3D Minor/Editorial Issues: >1. Section 5.1.2: > >This section doesn't make it clear that higher priority values are more >prioritized over lower values. That really should be defined here. Now >that information only becomes evident implicitly in section 5.1.2.1. I suggest the following: "This priority will be used by ICE to determine the order of the connectivity checks and the relative preference for candidates. Higher priority values give more priority over lower values." --- >2. Section 2.1. > > > In order to execute ICE, an ICE agent has to identify all of its > address candidates. > >I think this sentence is raising a too high requirement. An ICE agent >has attempt to identify as many of the address candidates as possible. >The better coverage of the potential candidates the more likely it is to >function. I would also argue that there are multiple cases where you >will not figure out that there are candidates that you don't know about. >An obvious example is in cases of two NATs between the local address >realm and the STUN server, the agent can't figure out that there was an >address given to the flow in the middle address realm between the two >NATs. That can be only learn if the agent has a STUN server in that >address realm. Secondly, there are cases where policy may be applied to >exclude certain interfaces and their related candidates. I suggest to replace with first sentence and simply say: "In order to execute ICE, an ICE agent identifies and gathers one or more address candidates." >I also noted that this first paragraph and the second has a strange >relation. The first part of first paragraph is general, then there is >the part of the host candidate. Then the second part starts with STUN >and TURN derived candidates. Maybe the first paragraph should be split >between the general and the host part, or some other bridging is needed. I suggest to split the first paragraph into two paragraphs, where the second paragraph begins with the "At least one viable candidate=8A=B2 sentence.=20 --- >3. Section 2.3: > >If the transactions above succeed, the agents will set > the nominated flag for the pairs, and will cancel any future checks > for that component of the data stream. > >Although what is stated is normal, it is not guaranteed to happen, I >know this is intended as a simplified overview, but ignoring that there >can occur some shuffling back and forth if high priority checks complete >after low priority ones should at least be hinted or at least allowed by >the use of words. One of the tasks have been to simplify section 2, because it was too detailed for people who just wanted to get an overview of ICE. For example, we removed the text about role conflicts. So, I would prefer to not cover your case in section 2. I don=B9t think it is essential for people who want to get an overview. Implementers obviously will need to read the whole spec. --- >4. Section 3. > >As RFC 7825 do describe a significant enough different usage of ICE from >SIP, I think it would be good to actually included an informational >reference to this usage. I can do that. However, note that RFC 7825 references RFC 5245. It even references specific sections, which may not be the same in 5245bis. In addition, RFC 7825 uses =B3aggressive nomination=B2 terminology, which has been removed from 5245bis. What about: "RFC 7825 defines an ICE usage for the Real-Time Streaming Protocol (RTSP). Note, however, that the ICE usage is based on RFC 5245." --- >5. Section 5.1.1.4: > >An ICE agent SHOULD > monitor the interfaces it uses, invalidate candidates whose base has > gone away, and acquire new candidates as appropriate when new > interfaces appear. > >I am missing discussion of new addresses here. If the base disappears, >it might be that there is a new IP address that one should use. That >doesn't necessary imply a new interface. What about: "Host candidates do not time out, but the candidate addresses may change or disappear for a number of reasons. An ICE agent SHOULD monitor the interfaces it uses, invalidate candidates whose base has gone away, and acquire new candidates as appropriate when new IP addresses (on new or currently used interfaces) appear." --- >6. Section 7.2.5.1: > > If the Binding request generates a 487 (Role Conflict) error > response, and if the ICE agent included an ICE-CONTROLLED attribute > in the request, the agent MUST switch to the controlling role. If > the agent included an ICE-CONTROLLING attribute in the request, the > agent MUST switch to the controlled role. > >I think the first sentence should have a forward reference to Section >7.3.1.1 where the rest of the solution is described. I will add a reference. --- >7. Section 7.3: > >If the agent is using Diffserv Codepoint markings [RFC2475] in its > data packets, it SHOULD apply the same markings to Binding responses. > >I find this sentence a bit unclear. Is it intended to say: > >If the agent receiving the binding request, intended to use DSCP >markings !=3D0 for the data, it SHOULD set, the same marking to binding >responses. > >or > >If the agent receives a binding request with DSCP markings, then it >should apply to corresponding code point when forming the binding >response? It means that it will use the same markings in Binding responses that it uses in data packets (audio, video, etc). >There are unclarity of which agent is referenced and whom "it" is in the >sentence. It is the STUN server. Would the following be more clear? "If the agent is using Diffserv Codepoint markings [RFC2475] in data packets that it sends, the agent SHOULD apply the same markings to Binding responses." Regards, Christer --B_3600154327_42252147 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOQYJKoZIhvcNAQcCoIIUKjCCFCYCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIMMIIGBjCCA+6gAwIBAgIQN4YipkcuAr1/ZKbsw+1eMTANBgkqhkiG9w0BAQsFADBH MQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTAzMDgwODMyWhcNMjAxMTAzMDgwODMxWjBvMREw DwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRQ2hyaXN0ZXIgSG9sbWJlcmcxLTArBgkqhkiG 9w0BCQEWHmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTEPMA0GA1UEBRMGTE1GQ0hI MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy0z3dlyw+ybHo7PhlkBY00QOJB5T NOXcMdxiQ0nL5uM1C/0xQ7/T3uuHJRjD8nvqTqnlmfJ2VCZRKD3W8LJAUXGFd8JqwLJmGGZt cS3Jp+2WBAxBR6TjtcMwDGQNYD85YCKIuqcsarOxVhzXhwISp750JC1UmR4xxX1gbSkVb8S8 DsPsBioQ/Enkiad/rP0huQFb56Ocxu2Fy2aEW06ezyxU9My4Jh/vMDh+0DBb8EfN8ovAFmMH Qj3SxVUDwnTYbPdA1v3RipF/HH0NBsNOUS8RFct6OxHG1JDbMrkY9ErEKkrHmu3JyNM1hxmy 8rJl/yDID2n6vyxkh5QFcsvOdwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0 cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCB ggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEu Y29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNz c29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEeY2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEW LGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUESOe8HpdLQz1aZdNgbOPnJlysTIw HwYDVR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqG SIb3DQEBCwUAA4ICAQBdN30YKQsw+ow1tjR6gBDuNpQagWRw7DSkYXg4ZE5k76jyXPOTa9VE 8x3MbNIbsyuVLYiVIN/lePTPi4qyt1CNBGPn4roUOuGeGQ7/dABYWNGmT0nKjjeXmqs9bt5z CrxPfVS4xeEU7D64OJtD47f069jsG5E6qENdPmrjaKmTrllfM1S9HvWeco8PwBQC5ixpiXUq t3Dyq3K0GmCgs1P7dJqup+Dt6UNF+DwgSZZeBjo3l+BtAv7StrvWdUQCqJpjUttIwzmtqsx2 NUWa1oSoqvUJ6XnJUZdT/UF390/6Uo4rnTeOWao9dkKQCaE3KvtCHBNZRv1MW0Ot3KSKnE+4 iZeUZgg1KAVQ5dhjjtXmjYoZMYoN4lE4OB2ae8LRbOrj0PE7Wvbuhs5eOyei7e6lYDHPzpLn cfcLpQmOoHal11JqympoeJQENtQl2i1p2j5KmsfUQiqD1HQaGcpH9OKXEclLCOpQ/6zafNW3 nSYFBwADNpHMNiQXxcXKxiPCfiZa2UK5RRWohIz9kY8HXvX/1E2pvtOZoymiXJviR3g2BFvM 21+LIVu3dtoEWWxtD7MyDtOe1dEZTfxLUPMpQa66znWbEQ736mmv5n/z+Aaq7OidNuOIFfO2 HbE+LBHIWhKAy9Ttqa+RqpPONMkvz3kth+G4IOBaTYEPWWHLrqXe2zCCBsIwggSqoAMCAQIC EFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25l cmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4IC DwAwggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs 0zfSTm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9 ZVbXILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvS xlfpVdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eN o4v2PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWq g5t2H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4 TlG4rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1 MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYv SBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaG K5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoG CCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25l cmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVy YS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNV HSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRv cnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8v Y3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMS MA0GCSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gV LtDUJQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyo EBHGvw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50Zk BqYnnl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEO rPwfixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1Ur RIQ85AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKX e4HdDc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNO xdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaH KWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyE G/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDCCBTgwggMg oAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEy MDA1MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMM FlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQDCvusn8CGj82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1 gouuSLasANxldewqTV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/te uuSPl2e+S46NZAdXOFVpNDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv41 4e1Qe6kwjRnTCY5oZ12/PJcYU7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1s OTlzgBbIUrAjzeA+3N08R6C7NYrimGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1v gPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdf Y2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCDLrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2 WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt6 0H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKSL2LUP2lDfA3W/Fh1AYidWBZL3rqQ /0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8wPTAPBgNVHRMBAf8EBTADAQH/ MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA389ZoG5XcUkeudQXuZ KoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyywqODAQDc19oRc XOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr7cQZ5qtM ETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65XI0G SK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI 6wzWJoi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2H dqkXlrfPDZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/ xFZT+mNl0PMcDhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjU kL8Ws9nprFlhVMgcusrByuG5IEyPOpOJpaDMv9P2daR1lm1WMYIB8TCCAe0CAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMCEDeGIqZHLgK9f2Sm7MPtXjEwDQYJYIZIAWUDBAIBBQCgaTAvBgkq hkiG9w0BCQQxIgQg0wOS+IUx6J5o9+mP3vNFeEphVP8nSk/9UXnk/eN2WH8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwMTMwMDg1MjA2WjANBgkqhkiG 9w0BAQEFAASCAQBrPbR2m/qxCvx9ELfn4oy/h1UKe8AFomLtWLDb/eGI9qOBHloukZYG93hv i4ebvhc/V86Mmn316mBT96JG2v57M05Q6kYUScYxzFmozun6IuJYpt2xUHKfVOV2QLifWViZ se7wk29AzPT2WP3rzOkpg04K/bqrXNL+KscLWUvHDpXpLSMihS1vAI6dBYffcO5Hxj2F/fRx zQ00WaqdYZ6/5fRDj7Kp6P3Btgqf0i1x0SsZICBFqrOsb5WIc3s+V8YHG7TseSCsO2HEKV2W FHVK+RSLDlrfcIUYpbWnJ9+LSqCtKD4p8vnnrPn8iEd3fUIoewCUrzn/NZb5VixfhT3R --B_3600154327_42252147-- From nobody Tue Jan 30 03:20:51 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0E6131B0E; Tue, 30 Jan 2018 03:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KH0FxLat31ZZ; Tue, 30 Jan 2018 03:20:42 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 281CE13179D; Tue, 30 Jan 2018 03:18:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 21415BE56; Tue, 30 Jan 2018 11:18:13 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7stoCDx7eIF; Tue, 30 Jan 2018 11:18:12 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C7E24BDF9; Tue, 30 Jan 2018 11:18:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1517311092; bh=bV/RJXemE5iTzhf6HDSxUHkk9UvyUWXQyb60QVVlXVQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=zG00OHwIYXn9srgHkFddOHvFp5yDApHmiAcoAE/ReQepoY4AVQH4QcksawykS3F1r /Ffq8DfzRFqroP7pvyaUHg6qy/UlkCBwM0d5CLah0Cj87ejovWTB89Ejm6yTxzYvX0 +QlZ55yk8wd+mS4T0Z14q156gLY/1BqbWLdQ1fxc= To: Christer Holmberg , "secdir@ietf.org" Cc: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" References: <151698534014.492.17944720668568287169@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C143E76@ESESSMB109.ericsson.se> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: Date: Tue, 30 Jan 2018 11:18:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C143E76@ESESSMB109.ericsson.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZbqazTyWcpZvcqsfpx3erplxS9izLcC5b" Archived-At: Subject: Re: [Ice] Secdir last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 11:20:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ZbqazTyWcpZvcqsfpx3erplxS9izLcC5b Content-Type: multipart/mixed; boundary="YTrqgvD2chIL0rRga9MPRa2TrVNsMa1hn"; protected-headers="v1" From: Stephen Farrell To: Christer Holmberg , "secdir@ietf.org" Cc: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" Message-ID: Subject: Re: Secdir last call review of draft-ietf-ice-rfc5245bis-16 References: <151698534014.492.17944720668568287169@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C143E76@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C143E76@ESESSMB109.ericsson.se> --YTrqgvD2chIL0rRga9MPRa2TrVNsMa1hn Content-Type: multipart/mixed; boundary="------------FB8F40EBBA5D0F52B3AC56EA" Content-Language: en-GB This is a multi-part message in MIME format. --------------FB8F40EBBA5D0F52B3AC56EA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Sorry for the slowish response, more inline... On 28/01/18 12:57, Christer Holmberg wrote: > Hi Stephen, >=20 > Thank You for your review! Please see inline. >=20 >> Reviewer: Stephen Farrell Review result: Has Issues >>=20 >> (1) I think a bit more work on the security and privacy issues >> around ICE would improve >the document, and hopefully, ICE >> implementations. >>=20 >> - There has been (IMO somewhat justified) concern [1] about >> exposing all possible >addresses, for example where one is from a >> VPN intended to preserve privacy, say if a >user is aiming to >> circumvent local censorship or surveillance. 5.1.1.1 has a SHOULD >> that, >as I read it, says to always include such addresses. >>=20 >> [1] https://www.w3.org/wiki/Privacy/IPAddresses >>=20 >> (Note: I'm not claiming [1] is authoritative, it's just a page I >> found that describes the issue reasonably well.) >>=20 >> There is a bit of text about this (1st para in section 19), but IMO >> it's a bit weak. >>=20 >> - Did the WG consider REQUIRING or RECOMMENDING agent >> implementations provide some local interface that allows the host >> or an application to say "Don't use interface to generate >> any candidates until I tell you otherwise"? That might be better >> than having VPN operators recommending to turn off WebRTC entirely >> for example. (Note: this is my main comment, the rest are mostly >> suggested things to think about, if you've not already.) >>=20 >> - Even if the text isn't changed, a reference to [2] would I think >> be useful. (Assuming [2] is still being worked on in rtcweb, though >> mind you, I don't like how [2] refers to "consent" as I doubt a >> random person can really provide meaningful consent for things like >> this.) >>=20 >> [2] https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-04 >=20 > I would not want to REQUIRE implementing a local interface for > controlling the candidates, as ICE is also used by different types of > network entities (gateways etc). But, I am ok to RECOMMEND. Fair enough. >=20 > What about: >=20 > OLD: >=20 > "Individual implementations may also have implementation-specific > rules for controlling which addresses are revealed." >=20 > NEW: >=20 > "Individual implementations may also have implementation-specific > rules for controlling which addresses are revealed. It is RECOMMENDED > that applications interacting with human users provide a user > interfaces that allows the users to control which interfaces are used > to generate candidates, or when to use candidates generated for the > interfaces. >=20 > [REF-to- draft-ietf-rtcweb-ip-handling] provide additional > information and Requirements regarding the handing of IP addresses > for WebRTC applications." That's a fine improvement from my POV, esp if folks will really provide such interfaces. I'm not sure "interacting with humans" is quite right though, maybe it'd be better to add a reference to the problem (via [1] or [rtcweb-ip]) and to then say "Implementations where such issues can arise are RECOMMENDED to..." I'd also suggest maybe s/user interface/interface/ there, as e.g. a VPN client might want to use an API provided by an ICE implementation so the UI might be part of the VPN client and not the ICE implementation. So, overall I'd suggest something like this: "Individual implementations may also have implementation-specific rules for controlling which addresses are revealed. For example, [REF-to- draft-ietf-rtcweb-ip-handling] provides additional information about the privacy aspects of revealing IP addresses via ICE for WebRTC applications. ICE implementations where such issues can arise are RECOMMENDED to provide a programmatic or user interface that provides control over which network interfaces are used to generate candidates." >=20 >> - Separately [1] also describes another potential privacy issue >> with STUN urls. I think it'd be worthwhile noting such issues that >> have been found with deployments of ICE here, as any protocol using >> ICE and accepting non locally configured STUN/TURN URLs may have=20 >> issues like that. For example, a recent paper [3] also describes >> some attacks (in section 4.2 mostly) that could (I guess) be >> mounted against any ICE agent and not only WebRTC clients. That'd >> be worth a reference and maybe thinking about which attacks are >> generic ICE issues and don't only affect WebRTC. >>=20 >> [3] https://doi.org/10.1145/3019612.3019844 >=20 > I am struggling to figure out exactly what to do here... I really > hope we don't have to perfom a study on [3], and see what is general, > and what is WebRTC-specific. Are we even allowed to reference [3], as > it's not freely available? Sure, we can reference academic papers behind paywalls, and there's often another version available that's not. (Not sure in this case.) >=20 > Some help and guidance would be appreciated :) I guess about as much as can be done with this -bis effort is to note where any leakages have been found. There's been some recent traffic on the W3C WebRTC list about that I think, (in the thread about CSP iirc) so maybe a trawl of that thread will suggest some text? >=20 > --- >=20 >> - I also wondered if I can fingerprint a host based on how it does >> ICE? I suspect that might work, but haven't tried to figure out >> details. >>=20 >> - Could I probe an internal network based on feeding it candidates >> to check? E.g. checking timing of reactions. If I could that seems >> noteworthy. >=20 > Something like? >=20 > "Based on the types of candidates provided by the peer, and the > results of the connectivity tests performed Against those candidates, > an agent might be able to determine characteristics of the peer > network." Maybe: "Based on the types of candidates provided by the peer, and the results of the connectivity tests performed against those candidates, the peer might be able to determine characteristics of the local network, e.g. if different timings are apparent to the peer. In the limit the peer might be able to probe the local network." That said - I'm not claiming this is possible for-sure, I just bet it would be:-) >=20 > --- >=20 >> (2) 5.3: "...MUST contain ... bits of randomness" Don't you >> need to say when these values MUST be different and when they're ok >> to be re-used? I forget if STUN/TURN do that. >=20 > Section 7.2.2 says: >=20 > "A connectivity check Binding request MUST utilize the STUN > short-term credential mechanism." >=20 > RFC 5389 (STUN) says: >=20 > "Short-Term Credential: A temporary username and associated > password that represent a shared secret between client and server. > Short- term credentials are obtained through some kind of protocol=20 > mechanism between the client and server, preceding the STUN exchange. > A short-term credential has an explicit temporal scope, which may be > based on a specific amount of time (such as 5 minutes) or on an event > (such as termination of a SIP dialog). The specific scope of a > short-term credential is defined by the application usage." >=20 > If anything extra is needed, I think that should be done as an update > to STUN. Not sure I agree - maybe I wasn't clear in my comment though, so let me try rephrase it. STUN doesn't define the duration for which short-term creds are OK to be used. ICE does define a session concept therefore ICE ought to say if short term STUN creds MUST/MUST-NOT/MAY (or whatever) be re-used in different ICE sessions. Even within an ICE session I guess in theory one could require different short-term STUN credentials every single time, or not. So I do think there's something to be said here. >=20 >> (Also - the phrasing isn't that great - how do I "contain" >> randomness? But that's just a nit.) >=20 > Do you have a suggestion for a better word? I think what you want is to say "unguessable, with at least 128 bits of random number generator output used to generate each" or something like that? It's a hard one to get right, but even what you have isn't that bad (I did say this was a nit:-) The rest below are all fine, Thanks, S. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=20 > Nits: >=20 >> I took a look at the diff [4] between this and 5245, but that >> wasn't really that useful, so this review is based on a read of the >> draft without comparing it to 5245. Apologies if that causes me to >> comment on text that's unchanged - in such cases, I think it's fine >> to not heed those particular comments. >>=20 >> [4] >> https://tools.ietf.org/rfcdiff?url1=3Drfc5245&url2=3Ddraft-ietf-ice-rf= c5245bis-16.txt >> >> >>=20 - 2.1: Why "only UDP specified here"? Does that include QUIC which is >> UDP-based, but not UDP? I assume so. >=20 > There is a separate specification, RFC 6544, for TCP based > candidates. >=20 > Regarding QUIC, I don't know. QUIC wasn't discussed during the work, > but how/if the procedures also apply to QUIC without any > modifications etc I don't know. >=20 >> - 2.3: how the controlling/controlled stuff works isn't clear from=20 >> this, nor even (as I was reading it) in section 7.3.1.1 - I wasn't >> clear how the tie-breaker value is initialised until I got to >> 16.1. In any case I think a bit more explanatory text in 2.3 might >> be good. (But if implementers haven't had a problem with this, >> maybe it's just me.) >=20 > In general, one of the tasks of the bis work was to *simplify* > section 2, because the previous version was too detailed for > non-implementers who just want to figure out what ICE is all about > (in order to actually implement ICE, reading section 2 is obviously > not enough). For that reason, my opinion was that section 2 doesn't > really need to talk about role conflicts and tie-breaker values, as > it's not essential for a high-level description of ICE. >=20 > --- >=20 >> - 5.2: "The procedures in this section is common across the >> initiating and responding agents." s/is/are/ I guess? >=20 > Yes. I will fix as suggested. >=20 > --- >=20 >> - 6.1.1: What is "3PCC"? That note could maybe also do with a=20 >> reference, as I at least don't get what you're trying to tell me. >> Ah - it's 3rd party call control (mentioned in 7.3.1.1). >=20 > I can use "3PCC (3rd Party Call Control)" in section 6.1.1. >=20 > As the spec is protocol independent, I don't think there are any > references that can be added. >=20 > --- >=20 >> - 16.1: For a given ICE session, are the random numbers in the=20 >> ICE-CONTROLLED and ICE-CONTROLLING attributes sent by the same >> agent supposed to have the same value? I wasn't clear. If they are >> the same, I understand how tie-breaking happens. If they can >> differ, I'm not sure. (But I didn't go back and re-read 7.3.1.1, so >> it may be ok either way:-) >=20 > It is covered in the 2nd paragraph of section 7.2.5.1, which says > that the agent MAY change the value when it switches role. >=20 >> In any case saying "referred to as the tie-breaker value" twice >> seems odd. >=20 > I'll remove it from the ICE-CONTROLLING definition. >=20 > --- >=20 >> - 16.1: (mega-mega-nit:-) the fact that tie-breaker is split over >> a line-breaker here is why I didn't find this when I was reading=20 >> 2.3/7.3.1.1 - maybe tweak the words so a grep will find it?) >=20 > Good catch. I'll fix it. >=20 > It would be really cool if search functions could discard line-breaks > when searching for strings. >=20 > --- >=20 >> - 17: "looking to deploy ICE" is a bit confusing - do you mean=20 >> "looking to be nice to ICE"? My assumption is that endpoints deploy >> ICE agents but network operators don't, though they might deploy >> STUN/TURN servers I guess. But maybe I'm thinking too much about >> WebRTC there. >=20 > Perhaps something like: >=20 > "This section discusses issues relevant to operators operating > networks where ICE will be used by endpoints." >=20 > --- >=20 >> - 18: I wondered if this is still needed, given that 5245 already >> said it (I didn't check if the text has been updated). Saying this >> once would seem sufficient to me anyway. I guess leaving it in is >> the easier path. >=20 > I'll leave it :) >=20 > --- >=20 >> - 19: s/DNS-SEC/DNSSEC/ would be more common >=20 > I will fix as suggested. >=20 > --- >=20 >> - 19.4.1: 1st sentence if missing a "T" - s/he/The/ >=20 > I will fix as suggested. >=20 > --- >=20 > Regards, >=20 > Christer >=20 --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------FB8F40EBBA5D0F52B3AC56EA Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------FB8F40EBBA5D0F52B3AC56EA-- --YTrqgvD2chIL0rRga9MPRa2TrVNsMa1hn-- --ZbqazTyWcpZvcqsfpx3erplxS9izLcC5b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJacFRzAAoJEFqy+vF7FyvqkZgP/02RywEIyZ0Wde78RS30PH0J TeRfU6KmUv3VXID5hgZ5U5/LYl1hX/7WWLKrszLJpv/1xF6HJFzYBtBT+vXIzLJG h6rqPQK3U8/EJM45FhqPzGRQrm5zKV7n4z11/GDA7c72dWJ2dD4KdPSxr6FvZPJl jI3lgby0Qqb+GPGsOJNvD2g9RMwCjzMImTavHVZ+a/9tuMr6ZVw4UT5zILsuYhPG CTYl3Wj+WCto5RuIyCh//u6lNhBSsxCO9ojGjS6wBcrdDr5rwJm8RGHJ0w/YoOII 1/WN7exIXaUt0O+USGG95vfrItvvxfDcMbFk7FgU7VGC12tyLzNg8ygfknSWmL1T OWYBshCgKqZGvILbc5Vq1J3hr7wbPoLTzMR/HFzgrwQ/vTpktuHpkjIhSbBGl/ZF XvbraO0nhiOjE/RTUQPJhECf7FMfqzfsxXe7dgoN0TSod9ENjONa5cnzWEWfhBgY pvPzuFwLYBSLl1nDpkSPSNaePfg0a7T67xH+3zSWwCUEo38oshqVxr3iXqpE2mEB TyZ/wCoP23YlQDfhHq4TdWEv7q9EStJjB0ImAo/u79MW49ncJ6NESbiNyyo10Udv 2m7ImXKrwn+umiaNSzXToJjeue69VKqtP9DSUCXb+OS6GddbWj6OmtzvlY0BMDSP feU5cnpCnF+3VTziIZFZ =bnFc -----END PGP SIGNATURE----- --ZbqazTyWcpZvcqsfpx3erplxS9izLcC5b-- From nobody Tue Jan 30 05:21:29 2018 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6381317CE; Tue, 30 Jan 2018 05:21:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Magnus Westerlund To: Cc: draft-ietf-ice-rfc5245bis.all@ietf.org, ietf@ietf.org, ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151731848710.27439.7061415423323921488@ietfa.amsl.com> Date: Tue, 30 Jan 2018 05:21:27 -0800 Archived-At: Subject: [Ice] Tsvart last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 13:21:27 -0000 Reviewer: Magnus Westerlund Review result: Ready with Issues I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@… if you reply to or forward this review. Unfortunately there was an error in the datatracker that resulted in that review requests was not timely sent. Thus, I got this request the day before the deadline. Therefore I am late with the review. I know that this is an update to an published RFC. But, I have reviewed it on a general level without considering what is changed or not. This draft is on the right track but has open issues, described in the review. Significant Issues: A. Section 5.2: Lite implementations only utilize host candidates. A lite implementation MUST, for each component of each data stream, allocate zero or one IPv4 candidates. It MAY allocate zero or more IPv6 candidates, but no more than one per each IPv6 address utilized by the host. Since there can be no more than one IPv4 candidate per component of each data stream, if an ICE agent has multiple IPv4 addresses, it MUST choose one for allocating the candidate. If a host is dual-stack, it is RECOMMENDED that it allocate one IPv4 candidate and one global IPv6 address. With the lite implementation, ICE cannot be used to dynamically choose amongst candidates. Therefore, including more than one candidate from a particular scope is NOT RECOMMENDED, since only a connectivity check can truly determine whether to use one address or the other. I find it quite strange that the above text says there can only be single IPv4 based candidate, while for IPv6 a LITE implementation may have one candidate per IPv6 address. Isn't the LITE implication of having multiple candidates for the same address family similar? Yes, IPv6 kind of forces the need for dealing with multiple IPv6 addresses on any host. However, I can see that certain servers will actually be multi-homed in IPv4 and thus can in a sensible way actually have multiple IPv4 candidates, and let the clients select which interface has the best reachability. Can you please be explicit on what in ICE prevents things to work for IPv4 but the same case works for IPv6? B. Section 6.1.1: An agent MUST be prepared that the peer might re-determine the roles as part of any ICE restart, even if the criteria for doing so are not fulfilled. This can happen if the peer is compliant with an older version of this specification. What does it mean to be prepared for a peer that re-determine the roles? What is it one MUST do? If the peer changes its role upon an ICE restart, isn't that going to result in a role mismatch? Thus causing yet another ICE restart, where also this peer will re-evalute? Isn't that good enough? Or is it something else it can do? C. Section 6.1.3: The ICE agent has a state determined by the state of the check lists. The state is Completed if all check lists are Completed, Failed if all check lists are Failed, and Running otherwise. Does failed really require all the checklists to fail, or simply any to fail if the others are completed? D. Section 6.1.4.2: I don't know if I misunderstand the algorithm here in the bullet list. To me it appears that it will terminate prior to have initiated all possible tests, as it appears that it will not unfreeze some of the candidate pairs. If one have tests running for a foundation, but all other candidate checks have been started, then the steps are aborted. Is the bullet list rechecked every Ta? E. Section 7.2.5.2.2. ICMP Error An ICE agent MAY support processing of ICMP errors for connectivity checks. If the agent supports processing of ICMP errors, and if a Binging request generates an ICMP error, the agent SHOULD set the state of the candidate pair to Failed. I am a bit worried by this blanket statement on ICMP errors. I think it should be clarified which ICMP message types that are relevant to consider as errors? I assume Type 3 (Destination Unreachable) but maybe not all responde codes as Codes 4, 11,12 may be addressable in other ways, and likely Type 11 (Time exceeded) with response code 0, response code 1 is not a clear indication of a non working path. F. Section 7.2.5.2.3. Timeout If the Binding request times out, the ICE agent MUST set the candidate pair state to Failed. Isn't this erroneous? Timeout for the connectivity check is happening when all the (re-)transmissions have timed out, isn't it? or as simple as missing the word "transaction"? G. Section 14.3: Num-Of-Pairs: the number of pairs of candidates with STUN or TURN servers. I don't understand this definition. What does "with STUN or TURN servers" mean? Candidate pairs where the local side is server-reflexive or relay? H. Section 14.3: Num-Waiting: the number of checks in the check list in the Waiting state. Num-In-Progress: the number of checks in the In-Progress state. Is "the number of checks" only per single checklist or across all the check lists? I. Section 17.2.3: When VAD is being used, keepalives will be sent during silence periods. I would claim that this is only true for when VAD without any comfort noise is used. A lot of codecs with VAD operations still generates comfort noise on a frequency of a couple packets a second, way more often then the minimal for ICE keep-alives. Minor/Editorial Issues: 1. Section 5.1.2: This section doesn't make it clear that higher priority values are more prioritized over lower values. That really should be defined here. Now that information only becomes evident implicitly in section 5.1.2.1. 2. Section 2.1. In order to execute ICE, an ICE agent has to identify all of its address candidates. I think this sentence is raising a too high requirement. An ICE agent has attempt to identify as many of the address candidates as possible. The better coverage of the potential candidates the more likely it is to function. I would also argue that there are multiple cases where you will not figure out that there are candidates that you don't know about. An obvious example is in cases of two NATs between the local address realm and the STUN server, the agent can't figure out that there was an address given to the flow in the middle address realm between the two NATs. That can be only learn if the agent has a STUN server in that address realm. Secondly, there are cases where policy may be applied to exclude certain interfaces and their related candidates. I also noted that this first paragraph and the second has a strange relation. The first part of first paragraph is general, then there is the part of the host candidate. Then the second part starts with STUN and TURN derived candidates. Maybe the first paragraph should be split between the general and the host part, or some other bridging is needed. 3. Section 2.3: If the transactions above succeed, the agents will set the nominated flag for the pairs, and will cancel any future checks for that component of the data stream. Although what is stated is normal, it is not guaranteed to happen, I know this is intended as a simplified overview, but ignoring that there can occur some shuffling back and forth if high priority checks complete after low priority ones should at least be hinted or at least allowed by the use of words. 4. Section 3. As RFC 7825 do describe a significant enough different usage of ICE from SIP, I think it would be good to actually included an informational reference to this usage. 5. Section 5.1.1.4: An ICE agent SHOULD monitor the interfaces it uses, invalidate candidates whose base has gone away, and acquire new candidates as appropriate when new interfaces appear. I am missing discussion of new addresses here. If the base disappears, it might be that there is a new IP address that one should use. That doesn't necessary imply a new interface. 6. Section 7.2.5.1: If the Binding request generates a 487 (Role Conflict) error response, and if the ICE agent included an ICE-CONTROLLED attribute in the request, the agent MUST switch to the controlling role. If the agent included an ICE-CONTROLLING attribute in the request, the agent MUST switch to the controlled role. I think the first sentence should have a forward reference to Section 7.3.1.1 where the rest of the solution is described. 7. Section 7.3: If the agent is using Diffserv Codepoint markings [RFC2475] in its data packets, it SHOULD apply the same markings to Binding responses. I find this sentence a bit unclear. Is it intended to say: If the agent receiving the binding request, intended to use DSCP markings !=0 for the data, it SHOULD set, the same marking to binding responses. or If the agent receives a binding request with DSCP markings, then it should apply to corresponding code point when forming the binding response? There are unclarity of which agent is referenced and whom "it" is in the sentence. 8. Section 8.3.1: The procedures in Section 8 require that an ICE agent continue to listen for STUN requests and continue to generate triggered checks for a data stream, even once processing for that stream completes. That reference to Section 8, should that in fact be to Section 8.1 specifically? It looks strange with a self reference, which in some aspect a reference to section 8 means. 9. Section 15: 4.57566E+18 (note that an implementation would represent this as a 64-bit integer so as not to lose precision). Why the floating point representation? Priorities are integer numbers and thus should be presented as such in this example. 10. Section 17.2.1: First and foremost, ICE makes use of TURN and STUN servers, which would typically be located in the network operator's data centers. Is really network operator's data centers the right entity here? I would claim it is the service operators data centers, they may contract STUN services from network operators, but if the service operator isn't providing any STUN service for its own service, then ICE is unlikely to work. 11. Section 18.2: Local IPv6 addresses can be preferred. I think this sentence needs to clarify that it means local to host, rather than any form of relayed or translated address, rather than a local scope only IPv6 address. 12. Section 18.5: A number of NAT boxes are now being deployed into the market that try to provide "generic" ALG functionality. These generic ALGs hunt for IP addresses, either in text or binary form within a packet, and rewrite them if they match a binding. Are actually these generic ALG functionality relevant today? They proved to be a very bad idea very quickly. A note that this was a consideration at the time RFC 5245 was published. Cheers Magnus Westerlund From nobody Tue Jan 30 05:29:03 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051D112EAAB; Tue, 30 Jan 2018 05:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZdVBnjuZDDi; Tue, 30 Jan 2018 05:28:58 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F3F12DA02; Tue, 30 Jan 2018 05:28:57 -0800 (PST) X-AuditID: c1b4fb25-48bff7000000341b-77-5a707317ffbd Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 7C.7C.13339.713707A5; Tue, 30 Jan 2018 14:28:55 +0100 (CET) Received: from [100.94.44.194] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 30 Jan 2018 14:28:54 +0100 To: Christer Holmberg , "ice@ietf.org" , "tsv-art@ietf.org" , "draft-ietf-ice-rfc5245bis.all@ietf.org" References: <05d4e10e-e326-32b9-a324-db833a2e57f9@ericsson.com> From: Magnus Westerlund Message-ID: <6f70132d-033d-6a6e-809c-6ab80cbb0fae@ericsson.com> Date: Tue, 30 Jan 2018 14:28:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070205090903060204060108" X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM2K7tK54cUGUwfJFMhbHf/xht/h2odZi 1p5FLA7MHkuW/GQKYIzisklJzcksSy3St0vgyjh95xVjwf+VjBUz7jxgbWDc3svYxcjJISFg IvHg8BfmLkYuDiGBw4wSn48tYoVwNjFK/Ll6jgWkSljAT+LAtY8sIAkRgauMEsefzAaq4gCq KpTYsVMVpIZNwELi5o9GNhCbV8Be4sepdrANLAKqErv6l7KC2KICMRILmg8xQ9QISpyc+YQF ZAyngI3En6MKIOOZBboZJZ69egY2R0hAW6KhqYMV4lIlievzrrNMYOSfhaR9FrIekASzgK3E nbm7mSFsbYllC19D2SISJy/fh7KtJWb8OghVrygxpfshO4RtKvH66EdGCNtI4t2eRvYFjJyr GEWLU4uTctONjPVSizKTi4vz8/TyUks2MQKj4uCW36o7GC+/cTzEKMDBqMTDuyu7IEqINbGs uDL3EKMK0JxHG1ZfYJRiycvPS1US4RVZnR8lxJuSWFmVWpQfX1Sak1p8iFGag0VJnPekJ2+U kEB6YklqdmpqQWoRTJaJg1OqgVGJ4ffNOzHNRcIVultnxJyRi9t4Xo8rUZ/hzMl2VZm+A5tT 7ot+4Uw139S5aLvx92tmt45ZNWXNlTq6cP2GeU9O6xbf+r338PPZC4/VfHhw4nWh0mO78oAF fWyP/Ar/Ltxw5cv+aXel45Y2XXnluYKz8umkG1UXz+dv6VoS8vGWVKVPULn3vM2PlFiKMxIN tZiLihMBF84eNpICAAA= Archived-At: Subject: Re: [Ice] TSV-ART Review of draft-ietf-ice-rfc5245bis-16 (Not complete yet) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 13:29:01 -0000 --------------ms070205090903060204060108 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: sv Hi, As I have now posted the complete review with some additional issues, I=20 would request that you post these comments on that complete review and I = can reply. Cheers Magnus Den 2018-01-30 kl. 09:40, skrev Christer Holmberg: > Hi Magnus, > > Thank you for the review! Please see inline. > >> I've reviewed this document as part of the transport area directorate'= s >> ongoing effort to review key IETF documents. These comments were writt= en >> primarily for the transport area directors, but are copied to the >> document's authors for their information and to allow them to address >> any issues raised. When done at the time of IETF Last Call, the author= s >> should consider this review together with any other last-call comments= >> they receive. Please always CC tsv-dir@=8A if you reply to or forward = this >> review. >> >> Unfortunately there was an error in the datatracker that resulted in >> that review requests was not timely sent. Thus, I got this request the= >> day before the deadline. Therefore I am late with the review. Also, I >> have not yet completed it. I have only reviewed the document to end of= >> section 7. So I send this out now for heads up, and intended to update= >> it the next few days. >> >> I know that this is an update to an published RFC. But, I have reviewe= d >> it on a general level without considering what is changed or not. >> >> This draft is on the right track but has open issues, described in the= >> review. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Significant Issues: > > >> A. Section 5.2: >> >> Lite implementations only utilize host candidates. A lite >> implementation MUST, for each component of each data stream, alloc= ate >> zero or one IPv4 candidates. It MAY allocate zero or more IPv6 >> candidates, but no more than one per each IPv6 address utilized by= >> the host. Since there can be no more than one IPv4 candidate per >> component of each data stream, if an ICE agent has multiple IPv4 >> addresses, it MUST choose one for allocating the candidate. If a >> host is dual-stack, it is RECOMMENDED that it allocate one IPv4 >> candidate and one global IPv6 address. With the lite implementati= on, >> ICE cannot be used to dynamically choose amongst candidates. >> Therefore, including more than one candidate from a particular sco= pe >> is NOT RECOMMENDED, since only a connectivity check can truly >> determine whether to use one address or the other. >> >> I find it quite strange that the above text says there can only be >> single IPv4 based candidate, while for IPv6 a LITE implementation may >> have one candidate per IPv6 address. Isn't the LITE implication of >> having multiple candidates for the same address family similar? Yes, >> IPv6 kind of forces the need for dealing with multiple IPv6 addresses = on >> any host. However, I can see that certain servers will actually be >> multi-homed in IPv4 and thus can in a sensible way actually have >> multiple IPv4 candidates, and let the clients select which interface h= as >> the best reachability. >> >> Can you please be explicit on what in ICE prevents things to work for >> IPv4 but the same case works for IPv6? > This is text from RFC 5245. I agree it is confusing, and unfortunately = I > don=B9t have a good answer. > > I guess my approach would be to suggest that we simply remove the > restriction. There is generic text about dual-stack etc elsewhere, and = I > don=B9t see anything ICE lite specific. > > OLD: > > "Lite implementations only utilize host candidates. A lite > implementation MUST, for each component of each data stream, alloca= te > zero or one IPv4 candidates. It MAY allocate zero or more IPv6 > candidates, but no more than one per each IPv6 address utilized by > the host. Since there can be no more than one IPv4 candidate per > component of each data stream, if an ICE agent has multiple IPv4 > addresses, it MUST choose one for allocating the candidate. If a > host is dual-stack, it is RECOMMENDED that it allocate one IPv4 > candidate and one global IPv6 address. With the lite implementatio= n, > ICE cannot be used to dynamically choose amongst candidates. > Therefore, including more than one candidate from a particular scop= e > is NOT RECOMMENDED, since only a connectivity check can truly > determine whether to use one address or the other." > > > NEW: > > "Lite implementations only utilize host candidates. > With the lite implementation, ICE cannot be used to dynamically choose > amongst candidates. Therefore, including more than one candidate from a= > particular IP address family is NOT RECOMMENDED, since only a connectiv= ity > check can Truly determine whether to use one address or the other.=B2 > > > > --- > >> B. Section 6.1.1: >> >> An agent MUST be prepared that the peer might re-determine the rol= es >> as part of any ICE restart, even if the criteria for doing so are = not >> fulfilled. This can happen if the peer is compliant with an older= >> version of this specification. >> >> What does it mean to be prepared for a peer that re-determine the role= s? >> What is it one MUST do? If the peer changes its role upon an ICE >> restart, isn't that going to result in a role mismatch? Thus causing y= et >> another ICE restart, where also this peer will re-evalute? Isn't that >> good enough? Or is it something else it can do? > The roles are re-negotiated during the ICE restart: it may, or may not,= > result in a role mismatch. > > =B3Prepared=B2 means that the peer might change its role even though it= does > not fulfil the 5245bis criteria for being allowed to do so. > > --- > >> C. Section 6.1.3: >> >> The ICE agent has a state determined by the state of the check lis= ts. >> The state is Completed if all check lists are Completed, Failed if= >> all check lists are Failed, and Running otherwise. >> >> Does failed really require all the checklists to fail, or simply any t= o >> fail if the others are completed? > If there are one or more completed, the session can still continue. As > described in section 8.1.2: > > "If at least one of the check lists for other data streams is > Completed, the controlling agent SHOULD remove the failed data > stream from the session while sending updated candidate list to > its peer." > > > --- > >> D. Section 6.1.4.2: >> >> I don't know if I misunderstand the algorithm here in the bullet list.= >> To me it appears that it will terminate prior to have initiated all >> possible tests, as it appears that it will not unfreeze some of the >> candidate pairs. If one have tests running for a foundation, but all >> other candidate checks have been started, then the steps are aborted. = Is >> the bullet list rechecked every Ta? > No. Whenever Ta fires, one check list in Running state is checked. When= > all check lists have been checked, it will start over from the top of t= he > list. > > Or, did I misunderstand your issue? > > --- > >> E. Section 7.2.5.2.2. ICMP Error >> >> An ICE agent MAY support processing of ICMP errors for connectivit= y >> checks. If the agent supports processing of ICMP errors, and if a= >> Binging request generates an ICMP error, the agent SHOULD set the >> state of the candidate pair to Failed. >> >> I am a bit worried by this blanket statement on ICMP errors. I think i= t >> should be clarified which ICMP message types that are relevant to >> consider as errors? I assume Type 3 (Destination Unreachable) but mayb= e >> not all responde codes as Codes 4, 11,12 may be addressable in other >> ways, and likely Type 11 (Time exceeded) with response code 0, respons= e >> code 1 is not a clear indication of a non working path. > This is from RFC 5245. > > I don=B9t think the ICE WG should go through all different codes and > combinations, and determine what should be considered an error, and wha= t > not. > > If you can provide something (table, guidance etc), we are happy to > include it. Otherwise I=B9d like to keep it as it is, and let > implementations deal with it. > > --- > >> F. Section 7.2.5.2.3. Timeout >> >> If the Binding request times out, the ICE agent MUST set the >> candidate pair state to Failed. >> >> Isn't this erroneous? Timeout for the connectivity check is happening >> when all the (re-)transmissions have timed out, isn't it? or as simple= >> as missing the word "transaction"? > Correct. I will change to =B3Binding request transaction=B2 > > =3D=3D=3D=3D=3D=3D=3D=3D > > Minor/Editorial Issues: > > >> 1. Section 5.1.2: >> >> This section doesn't make it clear that higher priority values are mor= e >> prioritized over lower values. That really should be defined here. Now= >> that information only becomes evident implicitly in section 5.1.2.1. > I suggest the following: > > "This priority will be used by ICE to determine the order of the > connectivity checks and the relative preference for candidates. > Higher priority values give more priority over lower values." > > --- > > >> 2. Section 2.1. >> >> >> In order to execute ICE, an ICE agent has to identify all of its >> address candidates. >> >> I think this sentence is raising a too high requirement. An ICE agent >> has attempt to identify as many of the address candidates as possible.= >> The better coverage of the potential candidates the more likely it is = to >> function. I would also argue that there are multiple cases where you >> will not figure out that there are candidates that you don't know abou= t. >> An obvious example is in cases of two NATs between the local address >> realm and the STUN server, the agent can't figure out that there was a= n >> address given to the flow in the middle address realm between the two >> NATs. That can be only learn if the agent has a STUN server in that >> address realm. Secondly, there are cases where policy may be applied t= o >> exclude certain interfaces and their related candidates. > I suggest to replace with first sentence and simply say: > > "In order to execute ICE, an ICE agent identifies and gathers one or mo= re > address candidates." > >> I also noted that this first paragraph and the second has a strange >> relation. The first part of first paragraph is general, then there is >> the part of the host candidate. Then the second part starts with STUN >> and TURN derived candidates. Maybe the first paragraph should be split= >> between the general and the host part, or some other bridging is neede= d. > I suggest to split the first paragraph into two paragraphs, where the > second paragraph begins with the "At least one viable candidate=8A=B2 > sentence. > > --- > >> 3. Section 2.3: >> >> If the transactions above succeed, the agents will set >> the nominated flag for the pairs, and will cancel any future check= s >> for that component of the data stream. >> >> Although what is stated is normal, it is not guaranteed to happen, I >> know this is intended as a simplified overview, but ignoring that ther= e >> can occur some shuffling back and forth if high priority checks comple= te >> after low priority ones should at least be hinted or at least allowed = by >> the use of words. > One of the tasks have been to simplify section 2, because it was too > detailed for people who just wanted to get an overview of ICE. For > example, we removed the text about role conflicts. > > So, I would prefer to not cover your case in section 2. I don=B9t think= it > is essential for people who want to get an overview. Implementers > obviously will need to read the whole spec. > > --- > >> 4. Section 3. >> >> As RFC 7825 do describe a significant enough different usage of ICE fr= om >> SIP, I think it would be good to actually included an informational >> reference to this usage. > I can do that. However, note that RFC 7825 references RFC 5245. It even= > references specific sections, which may not be the same in 5245bis. > > In addition, RFC 7825 uses =B3aggressive nomination=B2 terminology, whi= ch has > been removed from 5245bis. > > What about: > > "RFC 7825 defines an ICE usage for the Real-Time Streaming Protocol > (RTSP). Note, however, that the ICE usage is based on RFC 5245." > > --- > >> 5. Section 5.1.1.4: >> >> An ICE agent SHOULD >> monitor the interfaces it uses, invalidate candidates whose base h= as >> gone away, and acquire new candidates as appropriate when new >> interfaces appear. >> >> I am missing discussion of new addresses here. If the base disappears,= >> it might be that there is a new IP address that one should use. That >> doesn't necessary imply a new interface. > What about: > > "Host candidates do not time out, but the candidate addresses may > change or disappear for a number of reasons. An ICE agent SHOULD > monitor the interfaces it uses, invalidate candidates whose base has > gone away, and acquire new candidates as appropriate when new > IP addresses (on new or currently used interfaces) appear." > > --- > > >> 6. Section 7.2.5.1: >> >> If the Binding request generates a 487 (Role Conflict) error >> response, and if the ICE agent included an ICE-CONTROLLED attribut= e >> in the request, the agent MUST switch to the controlling role. If >> the agent included an ICE-CONTROLLING attribute in the request, th= e >> agent MUST switch to the controlled role. >> >> I think the first sentence should have a forward reference to Section >> 7.3.1.1 where the rest of the solution is described. > I will add a reference. > > --- > >> 7. Section 7.3: >> >> If the agent is using Diffserv Codepoint markings [RFC2475] in its >> data packets, it SHOULD apply the same markings to Binding respons= es. >> >> I find this sentence a bit unclear. Is it intended to say: >> >> If the agent receiving the binding request, intended to use DSCP >> markings !=3D0 for the data, it SHOULD set, the same marking to bindin= g >> responses. >> >> or >> >> If the agent receives a binding request with DSCP markings, then it >> should apply to corresponding code point when forming the binding >> response? > It means that it will use the same markings in Binding responses that i= t > uses in data packets (audio, video, etc). > >> There are unclarity of which agent is referenced and whom "it" is in t= he >> sentence. > It is the STUN server. > > Would the following be more clear? > > "If the agent is using Diffserv Codepoint markings [RFC2475] in data > packets that it sends, the agent SHOULD apply the same markings to Bind= ing > responses." > > > Regards, > > Christer --=20 Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------ms070205090903060204060108 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME-kryptografisk signatur MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DNEwggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNV BAoMCEVyaWNzc29uMRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJ ARYebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+ laqg5eXTqonqnzT9ykEGL2dx9mBT+2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJ HGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iV IiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpigGFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36o gzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkrbdmdnjKGrYSnJigmxw14pJugxL/Vb2Ee VcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDov L2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCBggYI KwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29t MEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29u bmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJp Y3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0 dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQG CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3 DQEBCwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4Q ihhoQR3cvhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXD yF9mhWYbSAkJyx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6 H3zO3nsq++KBmsOiSKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvE lup5n7l864FqxnC2friDo4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl 60rmc8SJlt6QXKw0wXEOE1MubauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwD ig3SZi1qP7D/Ds4V+JLIjjUJc25l9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8K v7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLCQaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3 UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Zla71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzY VBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd//n4YbY2QhDCCBsIwggSqoAMCAQICEFO4 foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUx MDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw ggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfS Tm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbX ILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfp VdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2 PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2 H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4 rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX 1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjv Zibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FN VSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoGCCsG AQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEu Y29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5j b20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAE TjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnku dHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3Js LTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7 GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDU JQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHG vw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYn nl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwf ixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ8 5AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4Hd Dc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOE EHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd 3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/du jp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDGCAzswggM3AgEB MFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMA0GCWCGSAFlAwQCAQUA oIIBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAxMzAx MzI4NTFaMC8GCSqGSIb3DQEJBDEiBCBJM4UdlWAMRkVRSJBKxOAtvKvitET0LcCttVWn3yTv JDBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBlrrZreXF5 7TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMGwGCyqGSIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nz b24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62 a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAHRL2pGQUTAbHECG5BJj9K2MmNDWfm6FRn5GZzFE8 W92LtAF/g5Odm0SfffzESCsR5R3/8I6ClkYbRdWDncivbbGUf1eaFDgcp5ZeWVnaftw+tM5y /nkpn9u6IlYdzzsxMdBL59uHTlQp50KS0kKGR8jqSUevWB8ZwaAroEBsuggdTVwyrCI5ykUn i44U5HIadxW5rciDb2tsGnx28EdMh92FomHsq0EgLl4AKa6Be3ms26xGST+46EATdRAflIro PCRavb9dQKPI+rBCd+CIzK55tgd2ebx1djq82cdtLdJuFKYt8TK+unrPwD70rdulqaj0mGgP iWm0bKhN/5/EnQAAAAAAAA== --------------ms070205090903060204060108-- From nobody Tue Jan 30 05:54:31 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D19012EB5D; Tue, 30 Jan 2018 05:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zS6nw8ievF5; Tue, 30 Jan 2018 05:54:26 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFDCF13182F; Tue, 30 Jan 2018 05:53:50 -0800 (PST) X-AuditID: c1b4fb2d-b35ff70000007932-f8-5a7078ec9e76 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7D.BD.31026.CE8707A5; Tue, 30 Jan 2018 14:53:49 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Tue, 30 Jan 2018 14:53:48 +0100 From: Christer Holmberg To: Stephen Farrell , "secdir@ietf.org" CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-ice-rfc5245bis-16 Thread-Index: AQHTlsWSdlXqvNmVDEWzQ6CHG1vNgKOG2QlggAVgroCAAFA6gA== Date: Tue, 30 Jan 2018 13:53:47 +0000 Message-ID: References: <151698534014.492.17944720668568287169@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C143E76@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <87D58AC9560843479E1B9C991A846F46@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM2K7je7bioIogyP3mS2O//jDbvHtQq3F s43zWSw+LHzIYjF97zV2B1aPtd1X2TyWLPnJFMAUxWWTkpqTWZZapG+XwJXRtOECe8Gegoo3 E5YyNzDOiOpi5OSQEDCRmPm8mQnEFhI4zChx5XpoFyMXkL2EUWL7xk+sXYwcHGwCFhLd/7RB akQEwiTuvz/EClLDLDCTUeL1z5eMIAlhAReJV4//MEEUuUqs3PSDCaRXRMBJ4ssCH5Awi4Cq xPL139hBbF4Ba4m7vXsZIXbtZJTYObGBEaSeU8BW4uovI5AaRgExie+n1oCNZBYQl7j1ZD4T xM0CEkv2nGeGsEUlXj7+xwpiiwroSWw4cZsdZIyEgKLE8n45iFY9iRtTp7BB2NYS11fuZIGw tSWWLXzNDHGOoMTJmU9YJjCKz0KybRaS9llI2mchaZ+FpH0BI+sqRtHi1OLi3HQjY73Uoszk 4uL8PL281JJNjMA4PLjlt+4OxtWvHQ8xCnAwKvHwXswuiBJiTSwrrsw9xCjBwawkwiuyOj9K iDclsbIqtSg/vqg0J7X4EKM0B4uSOO9JT94oIYH0xJLU7NTUgtQimCwTB6dUA6PWRLPb9hs4 0svbS5eXGB2eudNdmFE1eaUtb9+ml8bHWev5nsTwHti/azvDNt9ZjHK2Nw1lfuQm7o1hFmN3 uCU0/cij3JzHsp5B+ou2Je85/uqbhyj7kdj1DbJv3VP2BSZc5FpqZLrJQmfXvaiKvMkvW9VE F2y4Fiac2lMRalK882wTr7y4uhJLcUaioRZzUXEiANOUv/6/AgAA Archived-At: Subject: Re: [Ice] Secdir last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 13:54:29 -0000 Hi, >>>Reviewer: Stephen Farrell Review result: Has Issues >>>=20 >>> (1) I think a bit more work on the security and privacy issues >>> around ICE would improve >the document, and hopefully, ICE >>> implementations. >>>=20 >>> - There has been (IMO somewhat justified) concern [1] about >>> exposing all possible >addresses, for example where one is from a >>> VPN intended to preserve privacy, say if a >user is aiming to >>> circumvent local censorship or surveillance. 5.1.1.1 has a SHOULD >>> that, >as I read it, says to always include such addresses. >>>=20 >>> [1] https://www.w3.org/wiki/Privacy/IPAddresses >>>=20 >>> (Note: I'm not claiming [1] is authoritative, it's just a page I >>> found that describes the issue reasonably well.) >>>=20 >>> There is a bit of text about this (1st para in section 19), but IMO >>> it's a bit weak. >>>=20 >>> - Did the WG consider REQUIRING or RECOMMENDING agent >>> implementations provide some local interface that allows the host >>> or an application to say "Don't use interface to generate >>> any candidates until I tell you otherwise"? That might be better >>> than having VPN operators recommending to turn off WebRTC entirely >>> for example. (Note: this is my main comment, the rest are mostly >>> suggested things to think about, if you've not already.) >>>=20 >>> - Even if the text isn't changed, a reference to [2] would I think >>> be useful. (Assuming [2] is still being worked on in rtcweb, though >>> mind you, I don't like how [2] refers to "consent" as I doubt a >>> random person can really provide meaningful consent for things like >>> this.) >>>=20 >>> [2] https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-04 >>=20 >> I would not want to REQUIRE implementing a local interface for >> controlling the candidates, as ICE is also used by different types of >> network entities (gateways etc). But, I am ok to RECOMMEND. > >Fair enough. > >>=20 >> What about: >>=20 >> OLD: >>=20 >> "Individual implementations may also have implementation-specific >> rules for controlling which addresses are revealed." >>=20 >> NEW: >>=20 >> "Individual implementations may also have implementation-specific >> rules for controlling which addresses are revealed. It is RECOMMENDED >> that applications interacting with human users provide a user >> interfaces that allows the users to control which interfaces are used >> to generate candidates, or when to use candidates generated for the >> interfaces. >>=20 >> [REF-to- draft-ietf-rtcweb-ip-handling] provide additional >> information and Requirements regarding the handing of IP addresses >> for WebRTC applications." > >That's a fine improvement from my POV, esp if folks will >really provide such interfaces. I'm not sure "interacting >with humans" is quite right though, maybe it'd be better >to add a reference to the problem (via [1] or [rtcweb-ip]) >and to then say "Implementations where such issues can >arise are RECOMMENDED to..." I'd also suggest maybe >s/user interface/interface/ there, as e.g. a VPN client >might want to use an API provided by an ICE implementation >so the UI might be part of the VPN client and not the ICE >implementation. So, overall I'd suggest something like >this: > >"Individual implementations may also have implementation-specific >rules for controlling which addresses are revealed. For example, >[REF-to- draft-ietf-rtcweb-ip-handling] provides additional >information about the privacy aspects of revealing IP addresses >via ICE for WebRTC applications. ICE implementations where such >issues can arise are RECOMMENDED to provide a programmatic or >user interface that provides control over which network interfaces >are used to generate candidates." Looks good :) --- >>=20 >>> - Separately [1] also describes another potential privacy issue >>> with STUN urls. I think it'd be worthwhile noting such issues that >>> have been found with deployments of ICE here, as any protocol using >>> ICE and accepting non locally configured STUN/TURN URLs may have >>> issues like that. For example, a recent paper [3] also describes >>> some attacks (in section 4.2 mostly) that could (I guess) be >>> mounted against any ICE agent and not only WebRTC clients. That'd >>> be worth a reference and maybe thinking about which attacks are >>> generic ICE issues and don't only affect WebRTC. >>>=20 >>> [3] https://doi.org/10.1145/3019612.3019844 >>=20 >> I am struggling to figure out exactly what to do here... I really >> hope we don't have to perfom a study on [3], and see what is general, >> and what is WebRTC-specific. Are we even allowed to reference [3], as >> it's not freely available? > >Sure, we can reference academic papers behind paywalls, and >there's often another version available that's not. (Not sure >in this case.) > >>=20 >> Some help and guidance would be appreciated :) > >I guess about as much as can be done with this -bis effort is >to note where any leakages have been found. There's been some >recent traffic on the W3C WebRTC list about that I think, (in >the thread about CSP iirc) so maybe a trawl of that thread >will suggest some text? I did follow that discussion. I will take a second look. --- >>>- I also wondered if I can fingerprint a host based on how it does >>> ICE? I suspect that might work, but haven't tried to figure out >>> details. >>>=20 >>> - Could I probe an internal network based on feeding it candidates >>> to check? E.g. checking timing of reactions. If I could that seems >>> noteworthy. >>=20 >> Something like? >>=20 >> "Based on the types of candidates provided by the peer, and the >> results of the connectivity tests performed Against those candidates, >> an agent might be able to determine characteristics of the peer >> network." > >Maybe: > >"Based on the types of candidates provided by the peer, and the >results of the connectivity tests performed against those candidates, >the peer might be able to determine characteristics of the local >network, e.g. if different timings are apparent to the peer. In >the limit the peer might be able to probe the local network." > >That said - I'm not claiming this is possible for-sure, I just >bet it would be:-) The text looks good. --- >>>(2) 5.3: "...MUST contain ... bits of randomness" Don't you >>> need to say when these values MUST be different and when they're ok >>> to be re-used? I forget if STUN/TURN do that. >>=20 >> Section 7.2.2 says: >>=20 >> "A connectivity check Binding request MUST utilize the STUN >> short-term credential mechanism." >>=20 >> RFC 5389 (STUN) says: >>=20 >> "Short-Term Credential: A temporary username and associated >> password that represent a shared secret between client and server. >> Short- term credentials are obtained through some kind of protocol >> mechanism between the client and server, preceding the STUN exchange. >> A short-term credential has an explicit temporal scope, which may be >> based on a specific amount of time (such as 5 minutes) or on an event >> (such as termination of a SIP dialog). The specific scope of a >> short-term credential is defined by the application usage." >>=20 >> If anything extra is needed, I think that should be done as an update >> to STUN. > >Not sure I agree - maybe I wasn't clear in my comment though, >so let me try rephrase it. > >STUN doesn't define the duration for which short-term creds >are OK to be used. ICE does define a session concept therefore >ICE ought to say if short term STUN creds MUST/MUST-NOT/MAY >(or whatever) be re-used in different ICE sessions. Even >within an ICE session I guess in theory one could require >different short-term STUN credentials every single time, or >not. So I do think there's something to be said here. Section 9 says that an agent must create a new username fragment and password for every new ICE session: "To restart ICE, an agent MUST change both the password and the username fragment for the data stream(s) being restarted.=B2 Since I also uses the username to identity the ICE session, the values cannot be changed within a session. There is no text on when a value can be re-used - apart from the fact that they cannot be re-used when an ICE restart takes place. My assumption has been that the randomness criteria are assumed to ensure that two agents don=B9t choose the same values for the same session, and that values are unlikely to be re-used within a short period of time. We could say that agents shall verify that the same value is not re-used as long as packets from a previous ICE session may still be present in the network. But, that is not really security related, but more to make sure ICE works. --- >>=20 >>> (Also - the phrasing isn't that great - how do I "contain" >>> randomness? But that's just a nit.) >>=20 >> Do you have a suggestion for a better word? > >I think what you want is to say "unguessable, with at >least 128 bits of random number generator output used >to generate each" or something like that? It's a hard >one to get right, but even what you have isn't that >bad (I did say this was a nit:-) What about? "Username Fragment and Password: Values used to perform connectivity checks. The values MUST be unguessable, with at least 128 bits of random=20 number generator output used to generate the password, and at least 24=20 bits output to generate the username fragment." Thanks! :) Regards, Christer >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Nits: >>=20 >>> I took a look at the diff [4] between this and 5245, but that >>> wasn't really that useful, so this review is based on a read of the >>> draft without comparing it to 5245. Apologies if that causes me to >>> comment on text that's unchanged - in such cases, I think it's fine >>> to not heed those particular comments. >>>=20 >>> [4] >>>=20 >>>https://tools.ietf.org/rfcdiff?url1=3Drfc5245&url2=3Ddraft-ietf-ice-rfc5= 245b >>>is-16.txt >>> >>> >>>=20 >- 2.1: Why "only UDP specified here"? Does that include QUIC which is >>> UDP-based, but not UDP? I assume so. >>=20 >> There is a separate specification, RFC 6544, for TCP based >> candidates. >>=20 >> Regarding QUIC, I don't know. QUIC wasn't discussed during the work, >> but how/if the procedures also apply to QUIC without any >> modifications etc I don't know. >>=20 >>> - 2.3: how the controlling/controlled stuff works isn't clear from >>> this, nor even (as I was reading it) in section 7.3.1.1 - I wasn't >>> clear how the tie-breaker value is initialised until I got to >>> 16.1. In any case I think a bit more explanatory text in 2.3 might >>> be good. (But if implementers haven't had a problem with this, >>> maybe it's just me.) >>=20 >> In general, one of the tasks of the bis work was to *simplify* >> section 2, because the previous version was too detailed for >> non-implementers who just want to figure out what ICE is all about >> (in order to actually implement ICE, reading section 2 is obviously >> not enough). For that reason, my opinion was that section 2 doesn't >> really need to talk about role conflicts and tie-breaker values, as >> it's not essential for a high-level description of ICE. >>=20 >> --- >>=20 >>> - 5.2: "The procedures in this section is common across the >>> initiating and responding agents." s/is/are/ I guess? >>=20 >> Yes. I will fix as suggested. >>=20 >> --- >>=20 >>> - 6.1.1: What is "3PCC"? That note could maybe also do with a >>> reference, as I at least don't get what you're trying to tell me. >>> Ah - it's 3rd party call control (mentioned in 7.3.1.1). >>=20 >> I can use "3PCC (3rd Party Call Control)" in section 6.1.1. >>=20 >> As the spec is protocol independent, I don't think there are any >> references that can be added. >>=20 >> --- >>=20 >>> - 16.1: For a given ICE session, are the random numbers in the >>> ICE-CONTROLLED and ICE-CONTROLLING attributes sent by the same >>> agent supposed to have the same value? I wasn't clear. If they are >>> the same, I understand how tie-breaking happens. If they can >>> differ, I'm not sure. (But I didn't go back and re-read 7.3.1.1, so >>> it may be ok either way:-) >>=20 >> It is covered in the 2nd paragraph of section 7.2.5.1, which says >> that the agent MAY change the value when it switches role. >>=20 >>> In any case saying "referred to as the tie-breaker value" twice >>> seems odd. >>=20 >> I'll remove it from the ICE-CONTROLLING definition. >>=20 >> --- >>=20 >>> - 16.1: (mega-mega-nit:-) the fact that tie-breaker is split over >>> a line-breaker here is why I didn't find this when I was reading >>> 2.3/7.3.1.1 - maybe tweak the words so a grep will find it?) >>=20 >> Good catch. I'll fix it. >>=20 >> It would be really cool if search functions could discard line-breaks >> when searching for strings. >>=20 >> --- >>=20 >>> - 17: "looking to deploy ICE" is a bit confusing - do you mean >>> "looking to be nice to ICE"? My assumption is that endpoints deploy >>> ICE agents but network operators don't, though they might deploy >>> STUN/TURN servers I guess. But maybe I'm thinking too much about >>> WebRTC there. >>=20 >> Perhaps something like: >>=20 >> "This section discusses issues relevant to operators operating >> networks where ICE will be used by endpoints." >>=20 >> --- >>=20 >>> - 18: I wondered if this is still needed, given that 5245 already >>> said it (I didn't check if the text has been updated). Saying this >>> once would seem sufficient to me anyway. I guess leaving it in is >>> the easier path. >>=20 >> I'll leave it :) >>=20 >> --- >>=20 >>> - 19: s/DNS-SEC/DNSSEC/ would be more common >>=20 >> I will fix as suggested. >>=20 >> --- >>=20 >>> - 19.4.1: 1st sentence if missing a "T" - s/he/The/ >>=20 >> I will fix as suggested. >>=20 >> --- >>=20 >> Regards, >>=20 >> Christer >>=20 > >--=20 >PGP key change time for me. >New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. >NewWithOld sigs in keyservers. >Sorry if that mucks something up;-) From nobody Tue Jan 30 06:36:02 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C6112EB44; Tue, 30 Jan 2018 06:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIviab6gemY2; Tue, 30 Jan 2018 06:35:34 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B271319FD; Tue, 30 Jan 2018 06:32:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D379CBE73; Tue, 30 Jan 2018 14:32:30 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tT82PKJiB-ZJ; Tue, 30 Jan 2018 14:32:30 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 90F15BE6F; Tue, 30 Jan 2018 14:32:30 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1517322750; bh=j4kt6ZBz6ItCQrD5uukl5BDZKBFRepcC0nHbydLKN5o=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=SN6TMmmeIyzeaSbytXL2oKhQA+uFLqFHnay59X1/xLIQ3QZ3bkENgkUW2C3Rk/j/U qD1FL/H4dUvK3Vx4tAoHq9zikEUQL8l+E2Evs7wLU+a7acbzI+I3w7ld8OblD73aEt 83H3bqV8UfpzsPIjkWSd1PoCq+PIR3Tv4K9wGVds= To: Christer Holmberg , "secdir@ietf.org" Cc: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" References: <151698534014.492.17944720668568287169@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C143E76@ESESSMB109.ericsson.se> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: Date: Tue, 30 Jan 2018 14:32:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2yGQSXqGz4gH2bxKFLs0nYL2G7TYBYpw8" Archived-At: Subject: Re: [Ice] Secdir last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 14:35:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2yGQSXqGz4gH2bxKFLs0nYL2G7TYBYpw8 Content-Type: multipart/mixed; boundary="z4EfMfxgBGtJ1H2NIPrsYnaxmy6uooEGe"; protected-headers="v1" From: Stephen Farrell To: Christer Holmberg , "secdir@ietf.org" Cc: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" Message-ID: Subject: Re: Secdir last call review of draft-ietf-ice-rfc5245bis-16 References: <151698534014.492.17944720668568287169@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C143E76@ESESSMB109.ericsson.se> In-Reply-To: --z4EfMfxgBGtJ1H2NIPrsYnaxmy6uooEGe Content-Type: multipart/mixed; boundary="------------335A015E9235FE76353BBBAB" Content-Language: en-GB This is a multi-part message in MIME format. --------------335A015E9235FE76353BBBAB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Those look close-enough or fine to me. For the recent WebRTC thread, if you find something, that'll be a good thing. If not, and nobody suggests some text, then I guess at least we did try:-) And FWIW I'm fine with that, as I'm not up to speed on non-WebRTC uses of ICE, so don't know if the same leakage issues can arise in reality, outside of WebRTC. Thanks, S. On 30/01/18 13:53, Christer Holmberg wrote: > Hi, >=20 >>>> Reviewer: Stephen Farrell Review result: Has Issues >>>> >>>> (1) I think a bit more work on the security and privacy issues >>>> around ICE would improve >the document, and hopefully, ICE >>>> implementations. >>>> >>>> - There has been (IMO somewhat justified) concern [1] about >>>> exposing all possible >addresses, for example where one is from a >>>> VPN intended to preserve privacy, say if a >user is aiming to >>>> circumvent local censorship or surveillance. 5.1.1.1 has a SHOULD >>>> that, >as I read it, says to always include such addresses. >>>> >>>> [1] https://www.w3.org/wiki/Privacy/IPAddresses >>>> >>>> (Note: I'm not claiming [1] is authoritative, it's just a page I >>>> found that describes the issue reasonably well.) >>>> >>>> There is a bit of text about this (1st para in section 19), but IMO >>>> it's a bit weak. >>>> >>>> - Did the WG consider REQUIRING or RECOMMENDING agent >>>> implementations provide some local interface that allows the host >>>> or an application to say "Don't use interface to generate >>>> any candidates until I tell you otherwise"? That might be better >>>> than having VPN operators recommending to turn off WebRTC entirely >>>> for example. (Note: this is my main comment, the rest are mostly >>>> suggested things to think about, if you've not already.) >>>> >>>> - Even if the text isn't changed, a reference to [2] would I think >>>> be useful. (Assuming [2] is still being worked on in rtcweb, though >>>> mind you, I don't like how [2] refers to "consent" as I doubt a >>>> random person can really provide meaningful consent for things like >>>> this.) >>>> >>>> [2] https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-04 >>> >>> I would not want to REQUIRE implementing a local interface for >>> controlling the candidates, as ICE is also used by different types of= >>> network entities (gateways etc). But, I am ok to RECOMMEND. >> >> Fair enough. >> >>> >>> What about: >>> >>> OLD: >>> >>> "Individual implementations may also have implementation-specific >>> rules for controlling which addresses are revealed." >>> >>> NEW: >>> >>> "Individual implementations may also have implementation-specific >>> rules for controlling which addresses are revealed. It is RECOMMENDED= >>> that applications interacting with human users provide a user >>> interfaces that allows the users to control which interfaces are used= >>> to generate candidates, or when to use candidates generated for the >>> interfaces. >>> >>> [REF-to- draft-ietf-rtcweb-ip-handling] provide additional >>> information and Requirements regarding the handing of IP addresses >>> for WebRTC applications." >> >> That's a fine improvement from my POV, esp if folks will >> really provide such interfaces. I'm not sure "interacting >> with humans" is quite right though, maybe it'd be better >> to add a reference to the problem (via [1] or [rtcweb-ip]) >> and to then say "Implementations where such issues can >> arise are RECOMMENDED to..." I'd also suggest maybe >> s/user interface/interface/ there, as e.g. a VPN client >> might want to use an API provided by an ICE implementation >> so the UI might be part of the VPN client and not the ICE >> implementation. So, overall I'd suggest something like >> this: >> >> "Individual implementations may also have implementation-specific >> rules for controlling which addresses are revealed. For example, >> [REF-to- draft-ietf-rtcweb-ip-handling] provides additional >> information about the privacy aspects of revealing IP addresses >> via ICE for WebRTC applications. ICE implementations where such >> issues can arise are RECOMMENDED to provide a programmatic or >> user interface that provides control over which network interfaces >> are used to generate candidates." >=20 > Looks good :) >=20 > --- >=20 >>> >>>> - Separately [1] also describes another potential privacy issue >>>> with STUN urls. I think it'd be worthwhile noting such issues that >>>> have been found with deployments of ICE here, as any protocol using >>>> ICE and accepting non locally configured STUN/TURN URLs may have >>>> issues like that. For example, a recent paper [3] also describes >>>> some attacks (in section 4.2 mostly) that could (I guess) be >>>> mounted against any ICE agent and not only WebRTC clients. That'd >>>> be worth a reference and maybe thinking about which attacks are >>>> generic ICE issues and don't only affect WebRTC. >>>> >>>> [3] https://doi.org/10.1145/3019612.3019844 >>> >>> I am struggling to figure out exactly what to do here... I really >>> hope we don't have to perfom a study on [3], and see what is general,= >>> and what is WebRTC-specific. Are we even allowed to reference [3], as= >>> it's not freely available? >> >> Sure, we can reference academic papers behind paywalls, and >> there's often another version available that's not. (Not sure >> in this case.) >> >>> >>> Some help and guidance would be appreciated :) >> >> I guess about as much as can be done with this -bis effort is >> to note where any leakages have been found. There's been some >> recent traffic on the W3C WebRTC list about that I think, (in >> the thread about CSP iirc) so maybe a trawl of that thread >> will suggest some text? >=20 > I did follow that discussion. I will take a second look. >=20 > --- >=20 >>>> - I also wondered if I can fingerprint a host based on how it does >>>> ICE? I suspect that might work, but haven't tried to figure out >>>> details. >>>> >>>> - Could I probe an internal network based on feeding it candidates >>>> to check? E.g. checking timing of reactions. If I could that seems >>>> noteworthy. >>> >>> Something like? >>> >>> "Based on the types of candidates provided by the peer, and the >>> results of the connectivity tests performed Against those candidates,= >>> an agent might be able to determine characteristics of the peer >>> network." >> >> Maybe: >> >> "Based on the types of candidates provided by the peer, and the >> results of the connectivity tests performed against those candidates, >> the peer might be able to determine characteristics of the local >> network, e.g. if different timings are apparent to the peer. In >> the limit the peer might be able to probe the local network." >> >> That said - I'm not claiming this is possible for-sure, I just >> bet it would be:-) >=20 > The text looks good. >=20 > --- >=20 >>>> (2) 5.3: "...MUST contain ... bits of randomness" Don't you >>>> need to say when these values MUST be different and when they're ok >>>> to be re-used? I forget if STUN/TURN do that. >>> >>> Section 7.2.2 says: >>> >>> "A connectivity check Binding request MUST utilize the STUN >>> short-term credential mechanism." >>> >>> RFC 5389 (STUN) says: >>> >>> "Short-Term Credential: A temporary username and associated >>> password that represent a shared secret between client and server. >>> Short- term credentials are obtained through some kind of protocol >>> mechanism between the client and server, preceding the STUN exchange.= >>> A short-term credential has an explicit temporal scope, which may be >>> based on a specific amount of time (such as 5 minutes) or on an event= >>> (such as termination of a SIP dialog). The specific scope of a >>> short-term credential is defined by the application usage." >>> >>> If anything extra is needed, I think that should be done as an update= >>> to STUN. >> >> Not sure I agree - maybe I wasn't clear in my comment though, >> so let me try rephrase it. >> >> STUN doesn't define the duration for which short-term creds >> are OK to be used. ICE does define a session concept therefore >> ICE ought to say if short term STUN creds MUST/MUST-NOT/MAY >> (or whatever) be re-used in different ICE sessions. Even >> within an ICE session I guess in theory one could require >> different short-term STUN credentials every single time, or >> not. So I do think there's something to be said here. >=20 > Section 9 says that an agent must create a new username fragment and > password for every new ICE session: >=20 > "To restart ICE, an agent MUST change both the password and the > username fragment for the data stream(s) being restarted.=C2=B2 >=20 >=20 > Since I also uses the username to identity the ICE session, the values > cannot be changed within a session. >=20 > There is no text on when a value can be re-used - apart from the fact t= hat > they cannot be re-used when an ICE restart takes place. >=20 > My assumption has been that the randomness criteria are assumed to ensu= re > that two agents don=C2=B9t choose the same values for the same session,= and > that values are unlikely to be re-used within a short period of time. >=20 > We could say that agents shall verify that the same value is not re-use= d > as long as packets from a previous ICE session may still be present in = the > network. But, that is not really security related, but more to make sur= e > ICE works. >=20 > --- >=20 >>> >>>> (Also - the phrasing isn't that great - how do I "contain" >>>> randomness? But that's just a nit.) >>> >>> Do you have a suggestion for a better word? >> >> I think what you want is to say "unguessable, with at >> least 128 bits of random number generator output used >> to generate each" or something like that? It's a hard >> one to get right, but even what you have isn't that >> bad (I did say this was a nit:-) >=20 > What about? >=20 > "Username Fragment and Password: Values used to perform connectiv= ity > checks. The values MUST be unguessable, with at least 128 bits of= > random=20 > number generator output used to generate the password, and at lea= st > 24=20 > bits output to generate the username fragment." >=20 >=20 > Thanks! :) >=20 > Regards, >=20 > Christer >=20 >=20 >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >>> >>> Nits: >>> >>>> I took a look at the diff [4] between this and 5245, but that >>>> wasn't really that useful, so this review is based on a read of the >>>> draft without comparing it to 5245. Apologies if that causes me to >>>> comment on text that's unchanged - in such cases, I think it's fine >>>> to not heed those particular comments. >>>> >>>> [4] >>>> >>>> https://tools.ietf.org/rfcdiff?url1=3Drfc5245&url2=3Ddraft-ietf-ice-= rfc5245b >>>> is-16.txt >>>> >>>> >>>> >> - 2.1: Why "only UDP specified here"? Does that include QUIC which is >>>> UDP-based, but not UDP? I assume so. >>> >>> There is a separate specification, RFC 6544, for TCP based >>> candidates. >>> >>> Regarding QUIC, I don't know. QUIC wasn't discussed during the work, >>> but how/if the procedures also apply to QUIC without any >>> modifications etc I don't know. >>> >>>> - 2.3: how the controlling/controlled stuff works isn't clear from >>>> this, nor even (as I was reading it) in section 7.3.1.1 - I wasn't >>>> clear how the tie-breaker value is initialised until I got to >>>> 16.1. In any case I think a bit more explanatory text in 2.3 might >>>> be good. (But if implementers haven't had a problem with this, >>>> maybe it's just me.) >>> >>> In general, one of the tasks of the bis work was to *simplify* >>> section 2, because the previous version was too detailed for >>> non-implementers who just want to figure out what ICE is all about >>> (in order to actually implement ICE, reading section 2 is obviously >>> not enough). For that reason, my opinion was that section 2 doesn't >>> really need to talk about role conflicts and tie-breaker values, as >>> it's not essential for a high-level description of ICE. >>> >>> --- >>> >>>> - 5.2: "The procedures in this section is common across the >>>> initiating and responding agents." s/is/are/ I guess? >>> >>> Yes. I will fix as suggested. >>> >>> --- >>> >>>> - 6.1.1: What is "3PCC"? That note could maybe also do with a >>>> reference, as I at least don't get what you're trying to tell me. >>>> Ah - it's 3rd party call control (mentioned in 7.3.1.1). >>> >>> I can use "3PCC (3rd Party Call Control)" in section 6.1.1. >>> >>> As the spec is protocol independent, I don't think there are any >>> references that can be added. >>> >>> --- >>> >>>> - 16.1: For a given ICE session, are the random numbers in the >>>> ICE-CONTROLLED and ICE-CONTROLLING attributes sent by the same >>>> agent supposed to have the same value? I wasn't clear. If they are >>>> the same, I understand how tie-breaking happens. If they can >>>> differ, I'm not sure. (But I didn't go back and re-read 7.3.1.1, so >>>> it may be ok either way:-) >>> >>> It is covered in the 2nd paragraph of section 7.2.5.1, which says >>> that the agent MAY change the value when it switches role. >>> >>>> In any case saying "referred to as the tie-breaker value" twice >>>> seems odd. >>> >>> I'll remove it from the ICE-CONTROLLING definition. >>> >>> --- >>> >>>> - 16.1: (mega-mega-nit:-) the fact that tie-breaker is split over >>>> a line-breaker here is why I didn't find this when I was reading >>>> 2.3/7.3.1.1 - maybe tweak the words so a grep will find it?) >>> >>> Good catch. I'll fix it. >>> >>> It would be really cool if search functions could discard line-breaks= >>> when searching for strings. >>> >>> --- >>> >>>> - 17: "looking to deploy ICE" is a bit confusing - do you mean >>>> "looking to be nice to ICE"? My assumption is that endpoints deploy >>>> ICE agents but network operators don't, though they might deploy >>>> STUN/TURN servers I guess. But maybe I'm thinking too much about >>>> WebRTC there. >>> >>> Perhaps something like: >>> >>> "This section discusses issues relevant to operators operating >>> networks where ICE will be used by endpoints." >>> >>> --- >>> >>>> - 18: I wondered if this is still needed, given that 5245 already >>>> said it (I didn't check if the text has been updated). Saying this >>>> once would seem sufficient to me anyway. I guess leaving it in is >>>> the easier path. >>> >>> I'll leave it :) >>> >>> --- >>> >>>> - 19: s/DNS-SEC/DNSSEC/ would be more common >>> >>> I will fix as suggested. >>> >>> --- >>> >>>> - 19.4.1: 1st sentence if missing a "T" - s/he/The/ >>> >>> I will fix as suggested. >>> >>> --- >>> >>> Regards, >>> >>> Christer >>> >> >> --=20 >> PGP key change time for me. >> New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. >> NewWithOld sigs in keyservers. >> Sorry if that mucks something up;-) >=20 >=20 --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------335A015E9235FE76353BBBAB Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------335A015E9235FE76353BBBAB-- --z4EfMfxgBGtJ1H2NIPrsYnaxmy6uooEGe-- --2yGQSXqGz4gH2bxKFLs0nYL2G7TYBYpw8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJacIH9AAoJEFqy+vF7FyvqxDoQAITOSo7KhUzzjAFq0gQPjTT2 Q3H1VM1PItppMW1xXv8lFRDTj8t3JUnkEy3KS/TQ0uQ9f8qexk/EWIC4PJeAPHhk 8YwnoEPDMggmVZlTDaNfFHIBTD2JFD0uc6hSfeXs5ZeptbnQapIZjYt06xOIBDRa 13pM1BKM0jM2vq9FqA7g5QNOXVWaR2/lf5CXn7/LIC8icuyW0Pf6zanFgnKB7EtQ 8kkTldCh8+69RzL9IYQqsAP62UF7RNoGxsTof0O/ObIE/R9jfZWYQt5hXhQYpOU2 uabWuE/yOfKh8knQs1sFdYKcBjma2jiavDjYwhCP30ZiCgn9tD7ErZNjz6vrk5Wz VRYGAWTrFd7FwjK5DTG3OvayLFKoR8b5JZK7hOY5xt7wh+abR8EtDzYMG5WZJeOI WrBWP1v65Jps+Z3Wx36GiCfi6yi0j4IaFNsJ4vodQJkEzqW+7spuDQVb0fvPMvh6 t1bX+e3zEjxerFOXRZl3RznfVtTM5CluX136IRvOJO+pXvLKsgBPFvWwLoBZsVCq cbT+wqx/2uYkxiUSTVwhL0XEeeoKlA65MTE/q8Wl/zFZA/CMnlpeQ0cMDfGk7Iyk jkvw8UxnLADaoyxq9rHER05mJYvABEFzWJIAKExpodXfKi3MiBKFNzxPJzz2Vrrp rk27TPLFrLrscdkxh7iq =lgd9 -----END PGP SIGNATURE----- --2yGQSXqGz4gH2bxKFLs0nYL2G7TYBYpw8-- From nobody Tue Jan 30 06:39:57 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0081131BB6; Tue, 30 Jan 2018 06:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VI8QVc_xevkL; Tue, 30 Jan 2018 06:39:41 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5986131B48; Tue, 30 Jan 2018 06:34:49 -0800 (PST) X-AuditID: c1b4fb30-d49ff70000006bc7-28-5a708287a34b Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B8.82.27591.782807A5; Tue, 30 Jan 2018 15:34:48 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Tue, 30 Jan 2018 15:34:47 +0100 From: Christer Holmberg To: Magnus Westerlund , "tsv-art@ietf.org" CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" Thread-Topic: Tsvart last call review of draft-ietf-ice-rfc5245bis-16 Thread-Index: AQHTmc09cSMwjiuCL0KSsp8F+FSKLqOMj1UA Date: Tue, 30 Jan 2018 14:34:46 +0000 Message-ID: References: <151731848710.27439.7061415423323921488@ietfa.amsl.com> In-Reply-To: <151731848710.27439.7061415423323921488@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2K7om5HU0GUQf93VovjP/6wW3y7UGvx bON8FotZexaxOLB4LFnykymAMYrLJiU1J7MstUjfLoEr49jL6oIPGxkrvvwvbGBcsZaxi5GT Q0LARGLy6uPsXYxcHEIChxklHpyZywLhLGGUaL52CKiKg4NNwEKi+582SIOIQLxE19Z3bCA1 zAIzGSVe/3wJNklYwEWi6/xvdogiV4nrr9qYIWwjicWrO8FqWARUJU6ubmIFsXkFrCWWND0H iwsJOEvsWn8VzOYEmrPk1TuwGkYBMYnvp9YwgdjMAuISt57MZ4K4WkBiyZ7zzBC2qMTLx//A 6kUF9CQ2nLjNDhFXlNh5tp0ZoldL4suPfWwQtrXEpckQNcxANVO6H7JD3CMocXLmE5YJjOKz kKybhaR9FpL2WUjaZyFpX8DIuopRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMPIObvltsIPx 5XPHQ4wCHIxKPLzXsguihFgTy4orcw8xSnAwK4nwiqzOjxLiTUmsrEotyo8vKs1JLT7EKM3B oiTOe9KTN0pIID2xJDU7NbUgtQgmy8TBKdXAuLJIYOmSlVEyna7JSSW1d1dt7FbL+BsVFWpQ ctVZtHHdVbWU6NwfLDXTyyJ/arFkCuzQcJEw+nfs/nbrRD2Ji28mngv9rRrGrbvgBP89tVkq h+rDvtzfVyGymvdctE3pRjHvIIPtGtM+3ryW0SzI+6Rbr8b+8BZTTQ+zNx/0tOp/JeavCdVW YinOSDTUYi4qTgQA2CgdhbgCAAA= Archived-At: Subject: Re: [Ice] Tsvart last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 14:39:44 -0000 SGksDQoNClBsZWFzZSBzZWUgaW5saW5lLiBBcyByZXF1ZXN0ZWQsIEkgaW5jbHVkZSBteSByZXBs aWVzIHRvIHRoZSBjb21tZW50cyB5b3UNCmFscmVhZHkgcHJvdmlkZWQgZWFybGllci4NCg0KPlNp Z25pZmljYW50IElzc3VlczoNCj4NCj5BLiBTZWN0aW9uIDUuMjoNCj4NCj4gICAgTGl0ZSBpbXBs ZW1lbnRhdGlvbnMgb25seSB1dGlsaXplIGhvc3QgY2FuZGlkYXRlcy4gIEEgbGl0ZQ0KPiAgICBp bXBsZW1lbnRhdGlvbiBNVVNULCBmb3IgZWFjaCBjb21wb25lbnQgb2YgZWFjaCBkYXRhIHN0cmVh bSwgYWxsb2NhdGUNCj4gICAgemVybyBvciBvbmUgSVB2NCBjYW5kaWRhdGVzLiAgSXQgTUFZIGFs bG9jYXRlIHplcm8gb3IgbW9yZSBJUHY2DQo+ICAgIGNhbmRpZGF0ZXMsIGJ1dCBubyBtb3JlIHRo YW4gb25lIHBlciBlYWNoIElQdjYgYWRkcmVzcyB1dGlsaXplZCBieQ0KPiAgICB0aGUgaG9zdC4g IFNpbmNlIHRoZXJlIGNhbiBiZSBubyBtb3JlIHRoYW4gb25lIElQdjQgY2FuZGlkYXRlIHBlcg0K PiAgICBjb21wb25lbnQgb2YgZWFjaCBkYXRhIHN0cmVhbSwgaWYgYW4gSUNFIGFnZW50IGhhcyBt dWx0aXBsZSBJUHY0DQo+ICAgIGFkZHJlc3NlcywgaXQgTVVTVCBjaG9vc2Ugb25lIGZvciBhbGxv Y2F0aW5nIHRoZSBjYW5kaWRhdGUuICBJZiBhDQo+ICAgIGhvc3QgaXMgZHVhbC1zdGFjaywgaXQg aXMgUkVDT01NRU5ERUQgdGhhdCBpdCBhbGxvY2F0ZSBvbmUgSVB2NA0KPiAgICBjYW5kaWRhdGUg YW5kIG9uZSBnbG9iYWwgSVB2NiBhZGRyZXNzLiAgV2l0aCB0aGUgbGl0ZSBpbXBsZW1lbnRhdGlv biwNCj4gICAgSUNFIGNhbm5vdCBiZSB1c2VkIHRvIGR5bmFtaWNhbGx5IGNob29zZSBhbW9uZ3N0 IGNhbmRpZGF0ZXMuDQo+ICAgIFRoZXJlZm9yZSwgaW5jbHVkaW5nIG1vcmUgdGhhbiBvbmUgY2Fu ZGlkYXRlIGZyb20gYSBwYXJ0aWN1bGFyIHNjb3BlDQo+ICAgIGlzIE5PVCBSRUNPTU1FTkRFRCwg c2luY2Ugb25seSBhIGNvbm5lY3Rpdml0eSBjaGVjayBjYW4gdHJ1bHkNCj4gICAgZGV0ZXJtaW5l IHdoZXRoZXIgdG8gdXNlIG9uZSBhZGRyZXNzIG9yIHRoZSBvdGhlci4NCj4NCj5JIGZpbmQgaXQg cXVpdGUgc3RyYW5nZSB0aGF0IHRoZSBhYm92ZSB0ZXh0IHNheXMgdGhlcmUgY2FuIG9ubHkgYmUg c2luZ2xlDQo+SVB2NA0KPmJhc2VkIGNhbmRpZGF0ZSwgd2hpbGUgZm9yIElQdjYgYSBMSVRFIGlt cGxlbWVudGF0aW9uIG1heSBoYXZlIG9uZQ0KPmNhbmRpZGF0ZQ0KPnBlciBJUHY2IGFkZHJlc3Mu IElzbid0IHRoZSBMSVRFIGltcGxpY2F0aW9uIG9mIGhhdmluZyBtdWx0aXBsZQ0KPmNhbmRpZGF0 ZXMgZm9yDQo+dGhlIHNhbWUgYWRkcmVzcyBmYW1pbHkgc2ltaWxhcj8gWWVzLCBJUHY2IGtpbmQg b2YgZm9yY2VzIHRoZSBuZWVkIGZvcg0KPmRlYWxpbmcNCj53aXRoIG11bHRpcGxlIElQdjYgYWRk cmVzc2VzIG9uIGFueSBob3N0LiBIb3dldmVyLCBJIGNhbiBzZWUgdGhhdCBjZXJ0YWluDQo+c2Vy dmVycyB3aWxsIGFjdHVhbGx5IGJlIG11bHRpLWhvbWVkIGluIElQdjQgYW5kIHRodXMgY2FuIGlu IGEgc2Vuc2libGUNCj53YXkNCj5hY3R1YWxseSBoYXZlIG11bHRpcGxlIElQdjQgY2FuZGlkYXRl cywgYW5kIGxldCB0aGUgY2xpZW50cyBzZWxlY3Qgd2hpY2gNCj5pbnRlcmZhY2UgaGFzIHRoZSBi ZXN0IHJlYWNoYWJpbGl0eS4NCj4NCj5DYW4geW91IHBsZWFzZSBiZSBleHBsaWNpdCBvbiB3aGF0 IGluIElDRSBwcmV2ZW50cyB0aGluZ3MgdG8gd29yayBmb3INCj5JUHY0IGJ1dA0KPnRoZSBzYW1l IGNhc2Ugd29ya3MgZm9yIElQdjY/DQoNClRoaXMgaXMgdGV4dCBmcm9tIFJGQyA1MjQ1LiBJIGFn cmVlIGl0IGlzIGNvbmZ1c2luZywgYW5kIHVuZm9ydHVuYXRlbHkgSQ0KZG9uoa90IGhhdmUgYSBn b29kIGFuc3dlci4NCg0KSSBndWVzcyBteSBhcHByb2FjaCB3b3VsZCBiZSB0byBzdWdnZXN0IHRo YXQgd2Ugc2ltcGx5IHJlbW92ZSB0aGUNCnJlc3RyaWN0aW9uLiBJbiBhZGRpdGlvbiwgdGhlcmUg aXMgZ2VuZXJpYyB0ZXh0IGFib3V0IGR1YWwtc3RhY2sgZXRjDQplbHNld2hlcmUsIA0KYW5kIEkg ZG9uoa90IHNlZSBhbnl0aGluZyBJQ0UgbGl0ZSBzcGVjaWZpYy4NCg0KT0xEOg0KDQoiTGl0ZSBp bXBsZW1lbnRhdGlvbnMgb25seSB1dGlsaXplIGhvc3QgY2FuZGlkYXRlcy4gIEEgbGl0ZQ0KICAg aW1wbGVtZW50YXRpb24gTVVTVCwgZm9yIGVhY2ggY29tcG9uZW50IG9mIGVhY2ggZGF0YSBzdHJl YW0sIGFsbG9jYXRlDQogICB6ZXJvIG9yIG9uZSBJUHY0IGNhbmRpZGF0ZXMuICBJdCBNQVkgYWxs b2NhdGUgemVybyBvciBtb3JlIElQdjYNCmNhbmRpZGF0ZXMsIGJ1dCBubyBtb3JlIHRoYW4gb25l IHBlciBlYWNoIElQdjYgYWRkcmVzcyB1dGlsaXplZCBieQ0KICAgdGhlIGhvc3QuICBTaW5jZSB0 aGVyZSBjYW4gYmUgbm8gbW9yZSB0aGFuIG9uZSBJUHY0IGNhbmRpZGF0ZSBwZXINCiAgIGNvbXBv bmVudCBvZiBlYWNoIGRhdGEgc3RyZWFtLCBpZiBhbiBJQ0UgYWdlbnQgaGFzIG11bHRpcGxlIElQ djQNCiAgIGFkZHJlc3NlcywgaXQgTVVTVCBjaG9vc2Ugb25lIGZvciBhbGxvY2F0aW5nIHRoZSBj YW5kaWRhdGUuICBJZiBhDQogICBob3N0IGlzIGR1YWwtc3RhY2ssIGl0IGlzIFJFQ09NTUVOREVE IHRoYXQgaXQgYWxsb2NhdGUgb25lIElQdjQNCiAgIGNhbmRpZGF0ZSBhbmQgb25lIGdsb2JhbCBJ UHY2IGFkZHJlc3MuICBXaXRoIHRoZSBsaXRlIGltcGxlbWVudGF0aW9uLA0KICAgSUNFIGNhbm5v dCBiZSB1c2VkIHRvIGR5bmFtaWNhbGx5IGNob29zZSBhbW9uZ3N0IGNhbmRpZGF0ZXMuDQogICBU aGVyZWZvcmUsIGluY2x1ZGluZyBtb3JlIHRoYW4gb25lIGNhbmRpZGF0ZSBmcm9tIGEgcGFydGlj dWxhciBzY29wZQ0KICAgaXMgTk9UIFJFQ09NTUVOREVELCBzaW5jZSBvbmx5IGEgY29ubmVjdGl2 aXR5IGNoZWNrIGNhbiB0cnVseQ0KICAgZGV0ZXJtaW5lIHdoZXRoZXIgdG8gdXNlIG9uZSBhZGRy ZXNzIG9yIHRoZSBvdGhlci4iDQoNCg0KTkVXOg0KDQoiTGl0ZSBpbXBsZW1lbnRhdGlvbnMgb25s eSB1dGlsaXplIGhvc3QgY2FuZGlkYXRlcy4NCldpdGggdGhlIGxpdGUgaW1wbGVtZW50YXRpb24s IElDRSBjYW5ub3QgYmUgdXNlZCB0byBkeW5hbWljYWxseSBjaG9vc2UNCmFtb25nc3QgY2FuZGlk YXRlcy4gVGhlcmVmb3JlLCBpbmNsdWRpbmcgbW9yZSB0aGFuIG9uZSBjYW5kaWRhdGUgZnJvbSBh DQpwYXJ0aWN1bGFyIElQIGFkZHJlc3MgZmFtaWx5IGlzIE5PVCBSRUNPTU1FTkRFRCwgc2luY2Ug b25seSBhIGNvbm5lY3Rpdml0eQ0KY2hlY2sgY2FuIFRydWx5IGRldGVybWluZSB3aGV0aGVyIHRv IHVzZSBvbmUgYWRkcmVzcyBvciB0aGUgb3RoZXIuIg0KDQotLS0NCg0KDQo+Qi4gU2VjdGlvbiA2 LjEuMToNCj4NCj4gICAgQW4gYWdlbnQgTVVTVCBiZSBwcmVwYXJlZCB0aGF0IHRoZSBwZWVyIG1p Z2h0IHJlLWRldGVybWluZSB0aGUgcm9sZXMNCj4gICAgYXMgcGFydCBvZiBhbnkgSUNFIHJlc3Rh cnQsIGV2ZW4gaWYgdGhlIGNyaXRlcmlhIGZvciBkb2luZyBzbyBhcmUgbm90DQo+ICAgIGZ1bGZp bGxlZC4gIFRoaXMgY2FuIGhhcHBlbiBpZiB0aGUgcGVlciBpcyBjb21wbGlhbnQgd2l0aCBhbiBv bGRlcg0KPiAgICB2ZXJzaW9uIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4NCj4NCj5XaGF0IGRvZXMg aXQgbWVhbiB0byBiZSBwcmVwYXJlZCBmb3IgYSBwZWVyIHRoYXQgcmUtZGV0ZXJtaW5lIHRoZSBy b2xlcz8NCj5XaGF0DQo+aXMgaXQgb25lIE1VU1QgZG8/IElmIHRoZSBwZWVyIGNoYW5nZXMgaXRz IHJvbGUgdXBvbiBhbiBJQ0UgcmVzdGFydCwNCj5pc24ndCB0aGF0DQo+Z29pbmcgdG8gcmVzdWx0 IGluIGEgcm9sZSBtaXNtYXRjaD8gVGh1cyBjYXVzaW5nIHlldCBhbm90aGVyIElDRSByZXN0YXJ0 LA0KPndoZXJlDQo+YWxzbyB0aGlzIHBlZXIgd2lsbCByZS1ldmFsdXRlPyBJc24ndCB0aGF0IGdv b2QgZW5vdWdoPyBPciBpcyBpdA0KPnNvbWV0aGluZyBlbHNlDQo+aXQgY2FuIGRvPw0KDQpUaGUg cm9sZXMgYXJlIHJlLW5lZ290aWF0ZWQgZHVyaW5nIHRoZSBJQ0UgcmVzdGFydDogaXQgbWF5LCBv ciBtYXkgbm90LA0KcmVzdWx0IGluIGEgcm9sZSBtaXNtYXRjaC4NCg0KIlByZXBhcmVkIiBtZWFu cyB0aGF0IHRoZSBwZWVyIG1pZ2h0IGNoYW5nZSBpdHMgcm9sZSBldmVuIHRob3VnaCBpdCBkb2Vz DQpub3QgZnVsZmlsIHRoZSA1MjQ1YmlzIGNyaXRlcmlhIGZvciBiZWluZyBhbGxvd2VkIHRvIGRv IHNvLg0KDQoNCi0tLQ0KDQo+Qy4gU2VjdGlvbiA2LjEuMzoNCj4NCj4gICAgVGhlIElDRSBhZ2Vu dCBoYXMgYSBzdGF0ZSBkZXRlcm1pbmVkIGJ5IHRoZSBzdGF0ZSBvZiB0aGUgY2hlY2sgbGlzdHMu DQo+ICAgIFRoZSBzdGF0ZSBpcyBDb21wbGV0ZWQgaWYgYWxsIGNoZWNrIGxpc3RzIGFyZSBDb21w bGV0ZWQsIEZhaWxlZCBpZg0KPiAgICBhbGwgY2hlY2sgbGlzdHMgYXJlIEZhaWxlZCwgYW5kIFJ1 bm5pbmcgb3RoZXJ3aXNlLg0KPg0KPkRvZXMgZmFpbGVkIHJlYWxseSByZXF1aXJlIGFsbCB0aGUg Y2hlY2tsaXN0cyB0byBmYWlsLCBvciBzaW1wbHkgYW55IHRvDQo+ZmFpbCBpZg0KPnRoZSBvdGhl cnMgYXJlIGNvbXBsZXRlZD8NCg0KSWYgdGhlcmUgYXJlIG9uZSBvciBtb3JlIGNvbXBsZXRlZCwg dGhlIHNlc3Npb24gY2FuIHN0aWxsIGNvbnRpbnVlLiBBcw0KZGVzY3JpYmVkIGluIHNlY3Rpb24g OC4xLjI6DQoNCiJJZiBhdCBsZWFzdCBvbmUgb2YgdGhlIGNoZWNrIGxpc3RzIGZvciBvdGhlciBk YXRhIHN0cmVhbXMgaXMNCiAgICBDb21wbGV0ZWQsIHRoZSBjb250cm9sbGluZyBhZ2VudCBTSE9V TEQgcmVtb3ZlIHRoZSBmYWlsZWQgZGF0YQ0KICAgIHN0cmVhbSBmcm9tIHRoZSBzZXNzaW9uIHdo aWxlIHNlbmRpbmcgdXBkYXRlZCBjYW5kaWRhdGUgbGlzdCB0bw0KICAgIGl0cyBwZWVyLiINCg0K LS0tDQoNCg0KPkQuIFNlY3Rpb24gNi4xLjQuMjoNCj4NCj5JIGRvbid0IGtub3cgaWYgSSBtaXN1 bmRlcnN0YW5kIHRoZSBhbGdvcml0aG0gaGVyZSBpbiB0aGUgYnVsbGV0IGxpc3QuIFRvDQo+bWUg aXQNCj5hcHBlYXJzIHRoYXQgaXQgd2lsbCB0ZXJtaW5hdGUgcHJpb3IgdG8gaGF2ZSBpbml0aWF0 ZWQgYWxsIHBvc3NpYmxlDQo+dGVzdHMsIGFzDQo+aXQgYXBwZWFycyB0aGF0IGl0IHdpbGwgbm90 IHVuZnJlZXplIHNvbWUgb2YgdGhlIGNhbmRpZGF0ZSBwYWlycy4gSWYgb25lDQo+aGF2ZQ0KPnRl c3RzIHJ1bm5pbmcgZm9yIGEgZm91bmRhdGlvbiwgYnV0IGFsbCBvdGhlciBjYW5kaWRhdGUgY2hl Y2tzIGhhdmUgYmVlbg0KPnN0YXJ0ZWQsIHRoZW4gdGhlIHN0ZXBzIGFyZSBhYm9ydGVkLiBJcyB0 aGUgYnVsbGV0IGxpc3QgcmVjaGVja2VkIGV2ZXJ5DQo+VGE/DQoNCk5vLiBXaGVuZXZlciBUYSBm aXJlcywgb25lIGNoZWNrIGxpc3QgaW4gUnVubmluZyBzdGF0ZSBpcyBjaGVja2VkLiBXaGVuDQph bGwgY2hlY2sgbGlzdHMgaGF2ZSBiZWVuIGNoZWNrZWQsIGl0IHdpbGwgc3RhcnQgb3ZlciBmcm9t IHRoZSB0b3Agb2YgdGhlDQpsaXN0Lg0KDQpPciwgZGlkIEkgbWlzdW5kZXJzdGFuZCB5b3VyIGlz c3VlPw0KDQotLS0NCg0KDQo+RS4gU2VjdGlvbiA3LjIuNS4yLjIuICBJQ01QIEVycm9yDQo+DQo+ ICAgIEFuIElDRSBhZ2VudCBNQVkgc3VwcG9ydCBwcm9jZXNzaW5nIG9mIElDTVAgZXJyb3JzIGZv ciBjb25uZWN0aXZpdHkNCj4gICAgY2hlY2tzLiAgSWYgdGhlIGFnZW50IHN1cHBvcnRzIHByb2Nl c3Npbmcgb2YgSUNNUCBlcnJvcnMsIGFuZCBpZiBhDQo+ICAgIEJpbmdpbmcgcmVxdWVzdCBnZW5l cmF0ZXMgYW4gSUNNUCBlcnJvciwgdGhlIGFnZW50IFNIT1VMRCBzZXQgdGhlDQo+ICAgIHN0YXRl IG9mIHRoZSBjYW5kaWRhdGUgcGFpciB0byBGYWlsZWQuDQo+DQo+SSBhbSBhIGJpdCB3b3JyaWVk IGJ5IHRoaXMgYmxhbmtldCBzdGF0ZW1lbnQgb24gSUNNUCBlcnJvcnMuIEkgdGhpbmsgaXQNCj5z aG91bGQNCj5iZSBjbGFyaWZpZWQgd2hpY2ggSUNNUCBtZXNzYWdlIHR5cGVzIHRoYXQgYXJlIHJl bGV2YW50IHRvIGNvbnNpZGVyIGFzDQo+ZXJyb3JzPw0KPkkgYXNzdW1lIFR5cGUgMyAoRGVzdGlu YXRpb24gVW5yZWFjaGFibGUpIGJ1dCBtYXliZSBub3QgYWxsIHJlc3BvbmRlDQo+Y29kZXMgYXMN Cj5Db2RlcyA0LCAxMSwxMiBtYXkgYmUgYWRkcmVzc2FibGUgaW4gb3RoZXIgd2F5cywgYW5kIGxp a2VseSBUeXBlIDExIChUaW1lDQo+ZXhjZWVkZWQpIHdpdGggcmVzcG9uc2UgY29kZSAwLCByZXNw b25zZSBjb2RlIDEgaXMgbm90IGEgY2xlYXIgaW5kaWNhdGlvbg0KPm9mIGENCj5ub24gd29ya2lu ZyBwYXRoLg0KDQpUaGlzIGlzIGZyb20gUkZDIDUyNDUuDQoNCkkgZG9uoa90IHRoaW5rIHRoZSBJ Q0UgV0cgc2hvdWxkIGdvIHRocm91Z2ggYWxsIGRpZmZlcmVudCBjb2RlcyBhbmQNCmNvbWJpbmF0 aW9ucywgYW5kIGRldGVybWluZSB3aGF0IHNob3VsZCBiZSBjb25zaWRlcmVkIGFuIGVycm9yLCBh bmQgd2hhdA0Kbm90Lg0KDQpJZiB5b3UgY2FuIHByb3ZpZGUgc29tZXRoaW5nICh0YWJsZSwgZ3Vp ZGFuY2UgZXRjKSwgd2UgYXJlIGhhcHB5IHRvDQppbmNsdWRlIGl0LiBPdGhlcndpc2UgSaGvZCBs aWtlIHRvIGtlZXAgaXQgYXMgaXQgaXMsIGFuZCBsZXQNCmltcGxlbWVudGF0aW9ucyBkZWFsIHdp dGggaXQsIGFzIGF0IGxlYXN0IEkgYW0gbm90IGF3YXJlIHRoYXQgdGhpcyB3b3VsZA0KSGF2ZSBj YXVzZWQgaXNzdWVzIGluIElDRSBkZXBsb3ltZW50cy4NCg0KLS0tDQoNCg0KPkYuIFNlY3Rpb24g Ny4yLjUuMi4zLiAgVGltZW91dA0KPg0KPiAgICBJZiB0aGUgQmluZGluZyByZXF1ZXN0IHRpbWVz IG91dCwgdGhlIElDRSBhZ2VudCBNVVNUIHNldCB0aGUNCj4gICAgY2FuZGlkYXRlIHBhaXIgc3Rh dGUgdG8gRmFpbGVkLg0KPg0KPklzbid0IHRoaXMgZXJyb25lb3VzPyBUaW1lb3V0IGZvciB0aGUg Y29ubmVjdGl2aXR5IGNoZWNrIGlzIGhhcHBlbmluZw0KPndoZW4gYWxsDQo+dGhlIChyZS0pdHJh bnNtaXNzaW9ucyBoYXZlIHRpbWVkIG91dCwgaXNuJ3QgaXQ/IG9yIGFzIHNpbXBsZSBhcyBtaXNz aW5nDQo+dGhlDQo+d29yZCAidHJhbnNhY3Rpb24iPw0KDQpDb3JyZWN0LiBJIHdpbGwgY2hhbmdl IHRvICJCaW5kaW5nIHJlcXVlc3QgdHJhbnNhY3Rpb24iDQoNCi0tLQ0KDQoNCj5HLiBTZWN0aW9u IDE0LjM6DQo+DQo+ICAgICBOdW0tT2YtUGFpcnM6IHRoZSBudW1iZXIgb2YgcGFpcnMgb2YgY2Fu ZGlkYXRlcw0KPiAgICAgd2l0aCBTVFVOIG9yIFRVUk4gc2VydmVycy4NCj4NCj5JIGRvbid0IHVu ZGVyc3RhbmQgdGhpcyBkZWZpbml0aW9uLiBXaGF0IGRvZXMgIndpdGggU1RVTiBvciBUVVJOIHNl cnZlcnMiDQo+bWVhbj8NCj5DYW5kaWRhdGUgcGFpcnMgd2hlcmUgdGhlIGxvY2FsIHNpZGUgaXMg c2VydmVyLXJlZmxleGl2ZSBvciByZWxheT8NCg0KVGhlIHRleHQgY29tZXMgZnJvbSBSRkMgNTI0 NSwgYnV0IEkgdGhpbmsgaXShr3Mgd3JvbmcuIFRoZXJlIGFyZSBubyBwYWlycw0KZHVyaW5nIHRo ZSBnYXRoZXJpbmcgcGhhc2UuDQoNCk15IHN1Z2dlc3Rpb24gaXMgdG8gY2hhbmdlIE51bS1PZi1Q YWlycyB0byBOdW0tT2YtQ2FuZHMsIGFuZCBzYXk6DQoNCiJOdW0tT2YtQ2FuZHM6IHRoZSBudW1i ZXIgb2Ygc2VydmVyLXJlZmxleGl2ZSBhbmQgcmVsYXkgY2FuZGlkYXRlcyINCg0KDQotLS0NCg0K PkguIFNlY3Rpb24gMTQuMzoNCj4NCj4gICAgIE51bS1XYWl0aW5nOiB0aGUgbnVtYmVyIG9mIGNo ZWNrcyBpbiB0aGUgY2hlY2sgbGlzdCBpbiB0aGUNCj4gICAgIFdhaXRpbmcgc3RhdGUuDQo+DQo+ ICAgICBOdW0tSW4tUHJvZ3Jlc3M6IHRoZSBudW1iZXIgb2YgY2hlY2tzIGluIHRoZSBJbi1Qcm9n cmVzcyBzdGF0ZS4NCj4NCj5JcyAidGhlIG51bWJlciBvZiBjaGVja3MiIG9ubHkgcGVyIHNpbmds ZSBjaGVja2xpc3Qgb3IgYWNyb3NzIGFsbCB0aGUNCj5jaGVjaw0KPmxpc3RzPw0KDQpQZXIgc2lu Z2xlIGNoZWNrIGxpc3QuDQoNCi0tLQ0KDQo+SS4gU2VjdGlvbiAxNy4yLjM6DQo+DQo+V2hlbiBW QUQgaXMgYmVpbmcNCj4gICB1c2VkLCBrZWVwYWxpdmVzIHdpbGwgYmUgc2VudCBkdXJpbmcgc2ls ZW5jZSBwZXJpb2RzLg0KPg0KPkkgd291bGQgY2xhaW0gdGhhdCB0aGlzIGlzIG9ubHkgdHJ1ZSBm b3Igd2hlbiBWQUQgd2l0aG91dCBhbnkgY29tZm9ydA0KPm5vaXNlIGlzDQo+dXNlZC4gQSBsb3Qg b2YgY29kZWNzIHdpdGggVkFEIG9wZXJhdGlvbnMgc3RpbGwgZ2VuZXJhdGVzIGNvbWZvcnQgbm9p c2UNCj5vbiBhDQo+ZnJlcXVlbmN5IG9mIGEgY291cGxlIHBhY2tldHMgYSBzZWNvbmQsIHdheSBt b3JlIG9mdGVuIHRoZW4gdGhlIG1pbmltYWwNCj5mb3IgSUNFDQo+a2VlcC1hbGl2ZXMuDQoNCldo YXQgYWJvdXQ6DQoNCiJJbiBkZXBsb3ltZW50cyB0aGF0IGFyZSBub3QgdXRpbGl6aW5nIFZvaWNl IEFjdGl2aXR5IERldGVjdGlvbiAoVkFEKSwNCndpdGhvdXQgYW55IGNvbWZvcnQgbm9pc2UsDQp0 aGUga2VlcGFsaXZlcyBhcmUgbmV2ZXIuLi4iDQoNCg0KPT09PT09PQ0KDQo+TWlub3IvRWRpdG9y aWFsIElzc3VlczoNCj4NCj4xLiAgU2VjdGlvbiA1LjEuMjoNCj4NCj5UaGlzIHNlY3Rpb24gZG9l c24ndCBtYWtlIGl0IGNsZWFyIHRoYXQgaGlnaGVyIHByaW9yaXR5IHZhbHVlcyBhcmUgbW9yZQ0K PnByaW9yaXRpemVkIG92ZXIgbG93ZXIgdmFsdWVzLiBUaGF0IHJlYWxseSBzaG91bGQgYmUgZGVm aW5lZCBoZXJlLiBOb3cNCj50aGF0DQo+aW5mb3JtYXRpb24gb25seSBiZWNvbWVzIGV2aWRlbnQg aW1wbGljaXRseSBpbiBzZWN0aW9uIDUuMS4yLjEuDQoNCg0KSSBzdWdnZXN0IHRoZSBmb2xsb3dp bmc6DQoNCiJUaGlzIHByaW9yaXR5IHdpbGwgYmUgdXNlZCBieSBJQ0UgdG8gZGV0ZXJtaW5lIHRo ZSBvcmRlciBvZiB0aGUNCiAgIGNvbm5lY3Rpdml0eSBjaGVja3MgYW5kIHRoZSByZWxhdGl2ZSBw cmVmZXJlbmNlIGZvciBjYW5kaWRhdGVzLg0KSGlnaGVyIHByaW9yaXR5IHZhbHVlcyBnaXZlIG1v cmUgcHJpb3JpdHkgb3ZlciBsb3dlciB2YWx1ZXMuIg0KDQoNCi0tLQ0KDQo+Mi4gU2VjdGlvbiAy LjEuDQo+DQo+ICAgIEluIG9yZGVyIHRvIGV4ZWN1dGUgSUNFLCBhbiBJQ0UgYWdlbnQgaGFzIHRv IGlkZW50aWZ5IGFsbCBvZiBpdHMNCj4gICAgYWRkcmVzcyBjYW5kaWRhdGVzLg0KPg0KPkkgdGhp bmsgdGhpcyBzZW50ZW5jZSBpcyByYWlzaW5nIGEgdG9vIGhpZ2ggcmVxdWlyZW1lbnQuIEFuIElD RSBhZ2VudCBoYXMNCj5hdHRlbXB0IHRvIGlkZW50aWZ5IGFzIG1hbnkgb2YgdGhlIGFkZHJlc3Mg Y2FuZGlkYXRlcyBhcyBwb3NzaWJsZS4gVGhlDQo+YmV0dGVyDQo+Y292ZXJhZ2Ugb2YgdGhlIHBv dGVudGlhbCBjYW5kaWRhdGVzIHRoZSBtb3JlIGxpa2VseSBpdCBpcyB0byBmdW5jdGlvbi4gSQ0K PndvdWxkDQo+YWxzbyBhcmd1ZSB0aGF0IHRoZXJlIGFyZSBtdWx0aXBsZSBjYXNlcyB3aGVyZSB5 b3Ugd2lsbCBub3QgZmlndXJlIG91dA0KPnRoYXQNCj50aGVyZSBhcmUgY2FuZGlkYXRlcyB0aGF0 IHlvdSBkb24ndCBrbm93IGFib3V0LiBBbiBvYnZpb3VzIGV4YW1wbGUgaXMgaW4NCj5jYXNlcw0K Pm9mIHR3byBOQVRzIGJldHdlZW4gdGhlIGxvY2FsIGFkZHJlc3MgcmVhbG0gYW5kIHRoZSBTVFVO IHNlcnZlciwgdGhlIGFnZW50DQo+Y2FuJ3QgZmlndXJlIG91dCB0aGF0IHRoZXJlIHdhcyBhbiBh ZGRyZXNzIGdpdmVuIHRvIHRoZSBmbG93IGluIHRoZSBtaWRkbGUNCj5hZGRyZXNzIHJlYWxtIGJl dHdlZW4gdGhlIHR3byBOQVRzLiBUaGF0IGNhbiBiZSBvbmx5IGxlYXJuIGlmIHRoZSBhZ2VudA0K PmhhcyBhDQo+U1RVTiBzZXJ2ZXIgaW4gdGhhdCBhZGRyZXNzIHJlYWxtLiBTZWNvbmRseSwgdGhl cmUgYXJlIGNhc2VzIHdoZXJlIHBvbGljeQ0KPm1heQ0KPmJlIGFwcGxpZWQgdG8gZXhjbHVkZSBj ZXJ0YWluIGludGVyZmFjZXMgYW5kIHRoZWlyIHJlbGF0ZWQgY2FuZGlkYXRlcy4NCg0KSSBzdWdn ZXN0IHRvIHJlcGxhY2Ugd2l0aCBmaXJzdCBzZW50ZW5jZSBhbmQgc2ltcGx5IHNheToNCg0KIklu IG9yZGVyIHRvIGV4ZWN1dGUgSUNFLCBhbiBJQ0UgYWdlbnQgaWRlbnRpZmllcyBhbmQgZ2F0aGVy cyBvbmUgb3IgbW9yZQ0KYWRkcmVzcyBjYW5kaWRhdGVzLiINCg0KDQo+SSBhbHNvIG5vdGVkIHRo YXQgdGhpcyBmaXJzdCBwYXJhZ3JhcGggYW5kIHRoZSBzZWNvbmQgaGFzIGEgc3RyYW5nZQ0KPnJl bGF0aW9uLg0KPlRoZSBmaXJzdCBwYXJ0IG9mIGZpcnN0IHBhcmFncmFwaCBpcyBnZW5lcmFsLCB0 aGVuIHRoZXJlIGlzIHRoZSBwYXJ0IG9mDQo+dGhlDQo+aG9zdCBjYW5kaWRhdGUuIFRoZW4gdGhl IHNlY29uZCBwYXJ0IHN0YXJ0cyB3aXRoIFNUVU4gYW5kIFRVUk4gZGVyaXZlZA0KPmNhbmRpZGF0 ZXMuIE1heWJlIHRoZSBmaXJzdCBwYXJhZ3JhcGggc2hvdWxkIGJlIHNwbGl0IGJldHdlZW4gdGhl IGdlbmVyYWwNCj5hbmQNCj50aGUgaG9zdCBwYXJ0LCBvciBzb21lIG90aGVyIGJyaWRnaW5nIGlz IG5lZWRlZC4NCg0KSSBzdWdnZXN0IHRvIHNwbGl0IHRoZSBmaXJzdCBwYXJhZ3JhcGggaW50byB0 d28gcGFyYWdyYXBocywgd2hlcmUgdGhlDQpzZWNvbmQgcGFyYWdyYXBoIGJlZ2lucyB3aXRoIHRo ZSAiQXQgbGVhc3Qgb25lIHZpYWJsZSBjYW5kaWRhdGWKqfcNCnNlbnRlbmNlLiANCg0KLS0tDQoN Cg0KPjMuIFNlY3Rpb24gMi4zOg0KPg0KPklmIHRoZSB0cmFuc2FjdGlvbnMgYWJvdmUgc3VjY2Vl ZCwgdGhlIGFnZW50cyB3aWxsIHNldA0KPiAgICB0aGUgbm9taW5hdGVkIGZsYWcgZm9yIHRoZSBw YWlycywgYW5kIHdpbGwgY2FuY2VsIGFueSBmdXR1cmUgY2hlY2tzDQo+ICAgIGZvciB0aGF0IGNv bXBvbmVudCBvZiB0aGUgZGF0YSBzdHJlYW0uDQo+DQo+QWx0aG91Z2ggd2hhdCBpcyBzdGF0ZWQg aXMgbm9ybWFsLCBpdCBpcyBub3QgZ3VhcmFudGVlZCB0byBoYXBwZW4sIEkga25vdw0KPnRoaXMN Cj5pcyBpbnRlbmRlZCBhcyBhIHNpbXBsaWZpZWQgb3ZlcnZpZXcsIGJ1dCBpZ25vcmluZyB0aGF0 IHRoZXJlIGNhbiBvY2N1cg0KPnNvbWUNCj5zaHVmZmxpbmcgYmFjayBhbmQgZm9ydGggaWYgaGln aCBwcmlvcml0eSBjaGVja3MgY29tcGxldGUgYWZ0ZXIgbG93DQo+cHJpb3JpdHkNCj5vbmVzIHNo b3VsZCBhdCBsZWFzdCBiZSBoaW50ZWQgb3IgYXQgbGVhc3QgYWxsb3dlZCBieSB0aGUgdXNlIG9m IHdvcmRzLg0KDQpPbmUgb2YgdGhlIHRhc2tzIGhhdmUgYmVlbiB0byBzaW1wbGlmeSBzZWN0aW9u IDIsIGJlY2F1c2UgaXQgd2FzIHRvbw0KZGV0YWlsZWQgZm9yIHBlb3BsZSB3aG8ganVzdCB3YW50 ZWQgdG8gZ2V0IGFuIG92ZXJ2aWV3IG9mIElDRS4gRm9yDQpleGFtcGxlLCB3ZSByZW1vdmVkIHRo ZSB0ZXh0IGFib3V0IHJvbGUgY29uZmxpY3RzLg0KDQpTbywgSSB3b3VsZCBwcmVmZXIgdG8gbm90 IGNvdmVyIHlvdXIgY2FzZSBpbiBzZWN0aW9uIDIuIEkgZG9uqfZ0IHRoaW5rIGl0DQppcyBlc3Nl bnRpYWwgZm9yIHBlb3BsZSB3aG8gd2FudCB0byBnZXQgYW4gb3ZlcnZpZXcuIEltcGxlbWVudGVy cw0Kb2J2aW91c2x5IHdpbGwgbmVlZCB0byByZWFkIHRoZSB3aG9sZSBzcGVjLg0KDQotLS0NCg0K DQo+NC4gU2VjdGlvbiAzLg0KPg0KPkFzIFJGQyA3ODI1IGRvIGRlc2NyaWJlIGEgc2lnbmlmaWNh bnQgZW5vdWdoIGRpZmZlcmVudCB1c2FnZSBvZiBJQ0UgZnJvbQ0KPlNJUCwgSQ0KPnRoaW5rIGl0 IHdvdWxkIGJlIGdvb2QgdG8gYWN0dWFsbHkgaW5jbHVkZWQgYW4gaW5mb3JtYXRpb25hbCByZWZl cmVuY2UgdG8NCj50aGlzDQo+dXNhZ2UuDQoNCkkgY2FuIGRvIHRoYXQuIEhvd2V2ZXIsIG5vdGUg dGhhdCBSRkMgNzgyNSByZWZlcmVuY2VzIFJGQyA1MjQ1LiBJdCBldmVuDQpyZWZlcmVuY2VzIHNw ZWNpZmljIHNlY3Rpb25zLCB3aGljaCBtYXkgbm90IGJlIHRoZSBzYW1lIGluIDUyNDViaXMuDQoN CkluIGFkZGl0aW9uLCBSRkMgNzgyNSB1c2VzIKn4YWdncmVzc2l2ZSBub21pbmF0aW9uqfcgdGVy bWlub2xvZ3ksIHdoaWNoIGhhcw0KYmVlbiByZW1vdmVkIGZyb20gNTI0NWJpcy4NCg0KV2hhdCBh Ym91dDoNCg0KIlJGQyA3ODI1IGRlZmluZXMgYW4gSUNFIHVzYWdlIGZvciB0aGUgUmVhbC1UaW1l IFN0cmVhbWluZyBQcm90b2NvbA0KKFJUU1ApLiBOb3RlLCBob3dldmVyLCB0aGF0IHRoZSBJQ0Ug dXNhZ2UgaXMgYmFzZWQgb24gUkZDIDUyNDUuIg0KDQotLS0NCg0KDQo+NS4gU2VjdGlvbiA1LjEu MS40Og0KPg0KPkFuIElDRSBhZ2VudCBTSE9VTEQNCj4gICAgbW9uaXRvciB0aGUgaW50ZXJmYWNl cyBpdCB1c2VzLCBpbnZhbGlkYXRlIGNhbmRpZGF0ZXMgd2hvc2UgYmFzZSBoYXMNCj4gICAgZ29u ZSBhd2F5LCBhbmQgYWNxdWlyZSBuZXcgY2FuZGlkYXRlcyBhcyBhcHByb3ByaWF0ZSB3aGVuIG5l dw0KPiAgICBpbnRlcmZhY2VzIGFwcGVhci4NCj4NCj5JIGFtIG1pc3NpbmcgZGlzY3Vzc2lvbiBv ZiBuZXcgYWRkcmVzc2VzIGhlcmUuIElmIHRoZSBiYXNlIGRpc2FwcGVhcnMsIGl0DQo+bWlnaHQN Cj5iZSB0aGF0IHRoZXJlIGlzIGEgbmV3IElQIGFkZHJlc3MgdGhhdCBvbmUgc2hvdWxkIHVzZS4g VGhhdCBkb2Vzbid0DQo+bmVjZXNzYXJ5DQo+aW1wbHkgYSBuZXcgaW50ZXJmYWNlLg0KDQpXaGF0 IGFib3V0Og0KDQoiSG9zdCBjYW5kaWRhdGVzIGRvIG5vdCB0aW1lIG91dCwgYnV0IHRoZSBjYW5k aWRhdGUgYWRkcmVzc2VzIG1heQ0KY2hhbmdlIG9yIGRpc2FwcGVhciBmb3IgYSBudW1iZXIgb2Yg cmVhc29ucy4gQW4gSUNFIGFnZW50IFNIT1VMRA0KbW9uaXRvciB0aGUgaW50ZXJmYWNlcyBpdCB1 c2VzLCBpbnZhbGlkYXRlIGNhbmRpZGF0ZXMgd2hvc2UgYmFzZSBoYXMNCmdvbmUgYXdheSwgYW5k IGFjcXVpcmUgbmV3IGNhbmRpZGF0ZXMgYXMgYXBwcm9wcmlhdGUgd2hlbiBuZXcNCjxuZXc+SVAg YWRkcmVzc2VzIChvbiBuZXcgb3IgY3VycmVudGx5IHVzZWQgaW50ZXJmYWNlcyk8L25ldz4gYXBw ZWFyLiINCg0KDQotLS0NCg0KPjYuIFNlY3Rpb24gNy4yLjUuMToNCj4NCj4gICAgSWYgdGhlIEJp bmRpbmcgcmVxdWVzdCBnZW5lcmF0ZXMgYSA0ODcgKFJvbGUgQ29uZmxpY3QpIGVycm9yDQo+ICAg IHJlc3BvbnNlLCBhbmQgaWYgdGhlIElDRSBhZ2VudCBpbmNsdWRlZCBhbiBJQ0UtQ09OVFJPTExF RCBhdHRyaWJ1dGUNCj4gICAgaW4gdGhlIHJlcXVlc3QsIHRoZSBhZ2VudCBNVVNUIHN3aXRjaCB0 byB0aGUgY29udHJvbGxpbmcgcm9sZS4gSWYNCj4gICAgdGhlIGFnZW50IGluY2x1ZGVkIGFuIElD RS1DT05UUk9MTElORyBhdHRyaWJ1dGUgaW4gdGhlIHJlcXVlc3QsIHRoZQ0KPiAgICBhZ2VudCBN VVNUIHN3aXRjaCB0byB0aGUgY29udHJvbGxlZCByb2xlLg0KPg0KPkkgdGhpbmsgdGhlIGZpcnN0 IHNlbnRlbmNlIHNob3VsZCBoYXZlIGEgZm9yd2FyZCByZWZlcmVuY2UgdG8gU2VjdGlvbg0KPjcu My4xLjENCj53aGVyZSB0aGUgcmVzdCBvZiB0aGUgc29sdXRpb24gaXMgZGVzY3JpYmVkLg0KDQpJ IHdpbGwgYWRkIGEgcmVmZXJlbmNlLg0KDQotLS0NCg0KPjcuIFNlY3Rpb24gNy4zOg0KPg0KPklm IHRoZSBhZ2VudCBpcyB1c2luZyBEaWZmc2VydiBDb2RlcG9pbnQgbWFya2luZ3MgW1JGQzI0NzVd IGluIGl0cw0KPiAgICBkYXRhIHBhY2tldHMsIGl0IFNIT1VMRCBhcHBseSB0aGUgc2FtZSBtYXJr aW5ncyB0byBCaW5kaW5nIHJlc3BvbnNlcy4NCj4NCj5JIGZpbmQgdGhpcyBzZW50ZW5jZSBhIGJp dCB1bmNsZWFyLiBJcyBpdCBpbnRlbmRlZCB0byBzYXk6DQo+DQo+SWYgdGhlIGFnZW50IHJlY2Vp dmluZyB0aGUgYmluZGluZyByZXF1ZXN0LCBpbnRlbmRlZCB0byB1c2UgRFNDUCBtYXJraW5ncw0K PiE9MA0KPmZvciB0aGUgZGF0YSwgaXQgU0hPVUxEIHNldCwgdGhlIHNhbWUgbWFya2luZyB0byBi aW5kaW5nIHJlc3BvbnNlcy4NCj4NCj5vcg0KPg0KPklmIHRoZSBhZ2VudCByZWNlaXZlcyBhIGJp bmRpbmcgcmVxdWVzdCB3aXRoIERTQ1AgbWFya2luZ3MsIHRoZW4gaXQgc2hvdWxkDQo+YXBwbHkg dG8gY29ycmVzcG9uZGluZyBjb2RlIHBvaW50IHdoZW4gZm9ybWluZyB0aGUgYmluZGluZyByZXNw b25zZT8NCg0KSXQgbWVhbnMgdGhhdCBpdCB3aWxsIHVzZSB0aGUgc2FtZSBtYXJraW5ncyBpbiBC aW5kaW5nIHJlc3BvbnNlcyB0aGF0IGl0DQp1c2VzIGluIGRhdGEgcGFja2V0cyAoYXVkaW8sIHZp ZGVvLCBldGMpLg0KDQoNCj5UaGVyZSBhcmUgdW5jbGFyaXR5IG9mIHdoaWNoIGFnZW50IGlzIHJl ZmVyZW5jZWQgYW5kIHdob20gIml0IiBpcyBpbiB0aGUNCj5zZW50ZW5jZS4NCj4NCj44LiBTZWN0 aW9uIDguMy4xOg0KPg0KPiAgIFRoZSBwcm9jZWR1cmVzIGluIFNlY3Rpb24gOCByZXF1aXJlIHRo YXQgYW4gSUNFIGFnZW50IGNvbnRpbnVlIHRvDQo+ICAgbGlzdGVuIGZvciBTVFVOIHJlcXVlc3Rz IGFuZCBjb250aW51ZSB0byBnZW5lcmF0ZSB0cmlnZ2VyZWQgY2hlY2tzDQo+ICAgZm9yIGEgZGF0 YSBzdHJlYW0sIGV2ZW4gb25jZSBwcm9jZXNzaW5nIGZvciB0aGF0IHN0cmVhbSBjb21wbGV0ZXMu DQo+DQo+VGhhdCByZWZlcmVuY2UgdG8gU2VjdGlvbiA4LCBzaG91bGQgdGhhdCBpbiBmYWN0IGJl IHRvIFNlY3Rpb24gOC4xDQo+c3BlY2lmaWNhbGx5PyBJdCBsb29rcyBzdHJhbmdlIHdpdGggYSBz ZWxmIHJlZmVyZW5jZSwgd2hpY2ggaW4gc29tZQ0KPmFzcGVjdCBhDQo+cmVmZXJlbmNlIHRvIHNl Y3Rpb24gOCBtZWFucy4NCg0KSXQgaXMgdGhlIFNUVU4gc2VydmVyLg0KDQpXb3VsZCB0aGUgZm9s bG93aW5nIGJlIG1vcmUgY2xlYXI/DQoNCiJJZiB0aGUgYWdlbnQgaXMgdXNpbmcgRGlmZnNlcnYg Q29kZXBvaW50IG1hcmtpbmdzIFtSRkMyNDc1XSBpbiBkYXRhDQpwYWNrZXRzIHRoYXQgaXQgc2Vu ZHMsIHRoZSBhZ2VudCBTSE9VTEQgYXBwbHkgdGhlIHNhbWUgbWFya2luZ3MgdG8gQmluZGluZw0K cmVzcG9uc2VzLiINCg0KLS0tDQoNCg0KPjkuIFNlY3Rpb24gMTU6DQo+DQo+NC41NzU2NkUrMTgg KG5vdGUgdGhhdA0KPiAgIGFuIGltcGxlbWVudGF0aW9uIHdvdWxkIHJlcHJlc2VudCB0aGlzIGFz IGEgNjQtYml0IGludGVnZXIgc28gYXMgbm90DQo+ICAgdG8gbG9zZSBwcmVjaXNpb24pLg0KPg0K PldoeSB0aGUgZmxvYXRpbmcgcG9pbnQgcmVwcmVzZW50YXRpb24/IFByaW9yaXRpZXMgYXJlIGlu dGVnZXIgbnVtYmVycyBhbmQNCj50aHVzDQo+c2hvdWxkIGJlIHByZXNlbnRlZCBhcyBzdWNoIGlu IHRoaXMgZXhhbXBsZS4NCg0KVGhpcyBpcyBmcm9tIFJGQyA1MjQ1LCBhbmQgdW5mb3J0dW5hdGVs eSBJIGRvbqGvdCBrbm93Lg0KDQotLS0NCg0KPjEwLiBTZWN0aW9uIDE3LjIuMToNCj4NCj4gICBG aXJzdCBhbmQgZm9yZW1vc3QsIElDRSBtYWtlcyB1c2Ugb2YgVFVSTiBhbmQgU1RVTiBzZXJ2ZXJz LCB3aGljaA0KPiAgIHdvdWxkIHR5cGljYWxseSBiZSBsb2NhdGVkIGluIHRoZSBuZXR3b3JrIG9w ZXJhdG9yJ3MgZGF0YSBjZW50ZXJzLg0KPg0KPklzIHJlYWxseSBuZXR3b3JrIG9wZXJhdG9yJ3Mg ZGF0YSBjZW50ZXJzIHRoZSByaWdodCBlbnRpdHkgaGVyZT8gSSB3b3VsZA0KPmNsYWltDQo+aXQg aXMgdGhlIHNlcnZpY2Ugb3BlcmF0b3JzIGRhdGEgY2VudGVycywgdGhleSBtYXkgY29udHJhY3Qg U1RVTiBzZXJ2aWNlcw0KPmZyb20NCj5uZXR3b3JrIG9wZXJhdG9ycywgYnV0IGlmIHRoZSBzZXJ2 aWNlIG9wZXJhdG9yIGlzbid0IHByb3ZpZGluZyBhbnkgU1RVTg0KPnNlcnZpY2UNCj5mb3IgaXRz IG93biBzZXJ2aWNlLCB0aGVuIElDRSBpcyB1bmxpa2VseSB0byB3b3JrLg0KDQpDb3VsZCB3ZSBz aW1wbHkgc2F5IKGwbG9jYXRlZCBpbiBkYXRhIGNlbnRlcnOhsT8NCg0KLS0tDQoNCj4xMS4gU2Vj dGlvbiAxOC4yOg0KPg0KPkxvY2FsIElQdjYgYWRkcmVzc2VzIGNhbiBiZSBwcmVmZXJyZWQuDQo+ DQo+SSB0aGluayB0aGlzIHNlbnRlbmNlIG5lZWRzIHRvIGNsYXJpZnkgdGhhdCBpdCBtZWFucyBs b2NhbCB0byBob3N0LA0KPnJhdGhlciB0aGFuDQo+YW55IGZvcm0gb2YgcmVsYXllZCBvciB0cmFu c2xhdGVkIGFkZHJlc3MsIHJhdGhlciB0aGFuIGEgbG9jYWwgc2NvcGUgb25seQ0KPklQdjYNCj5h ZGRyZXNzLg0KDQpJIGNvdWxkIHNheToNCg0KIkxvY2FsIElQdjYgaG9zdCBhZGRyZXNzZXMiDQoN Ci0tLQ0KDQo+MTIuIFNlY3Rpb24gMTguNToNCj4NCj4gICBBIG51bWJlciBvZiBOQVQgYm94ZXMg YXJlIG5vdyBiZWluZyBkZXBsb3llZCBpbnRvIHRoZSBtYXJrZXQgdGhhdCB0cnkNCj4gICB0byBw cm92aWRlICJnZW5lcmljIiBBTEcgZnVuY3Rpb25hbGl0eS4gIFRoZXNlIGdlbmVyaWMgQUxHcyBo dW50IGZvcg0KPiAgIElQIGFkZHJlc3NlcywgZWl0aGVyIGluIHRleHQgb3IgYmluYXJ5IGZvcm0g d2l0aGluIGEgcGFja2V0LCBhbmQNCj4gICByZXdyaXRlIHRoZW0gaWYgdGhleSBtYXRjaCBhIGJp bmRpbmcuDQo+DQo+QXJlIGFjdHVhbGx5IHRoZXNlIGdlbmVyaWMgQUxHIGZ1bmN0aW9uYWxpdHkg cmVsZXZhbnQgdG9kYXk/IFRoZXkgcHJvdmVkDQo+dG8gYmUNCj5hIHZlcnkgYmFkIGlkZWEgdmVy eSBxdWlja2x5LiBBIG5vdGUgdGhhdCB0aGlzIHdhcyBhIGNvbnNpZGVyYXRpb24gYXQgdGhlDQo+ dGltZQ0KPlJGQyA1MjQ1IHdhcyBwdWJsaXNoZWQuDQoNCkkgZG9uoa90IGtub3cgd2hldGhlciB0 aGUgZnVuY3Rpb25hbGl0eSBpcyByZWxldmFudC4gQnV0LCBJIGd1ZXNzIGl0DQpkb2VzbqGvdCBo dXJ0IHRvIGhhdmUgdGhlIHRleHQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Tue Jan 30 08:50:10 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960AA12D94A; Tue, 30 Jan 2018 08:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmFwSaR_e2Xk; Tue, 30 Jan 2018 08:49:47 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC50012EC2B; Tue, 30 Jan 2018 08:49:47 -0800 (PST) Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0UGnfr0081152 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 30 Jan 2018 10:49:42 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105] From: Ben Campbell Message-Id: <8154BE03-5B04-4AE0-B936-804820ED907F@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_11805A38-32D9-400B-A214-F4DDAA087D84"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 30 Jan 2018 10:49:40 -0600 In-Reply-To: Cc: Magnus Westerlund , "tsv-art@ietf.org" , "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" To: Christer Holmberg References: <151731848710.27439.7061415423323921488@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ice] Tsvart last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 16:49:58 -0000 --Apple-Mail=_11805A38-32D9-400B-A214-F4DDAA087D84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Commenting on the first issue: > On Jan 30, 2018, at 8:34 AM, Christer Holmberg = wrote: >=20 >> Significant Issues: >>=20 >> A. Section 5.2: >>=20 >> Lite implementations only utilize host candidates. A lite >> implementation MUST, for each component of each data stream, = allocate >> zero or one IPv4 candidates. It MAY allocate zero or more IPv6 >> candidates, but no more than one per each IPv6 address utilized by >> the host. Since there can be no more than one IPv4 candidate per >> component of each data stream, if an ICE agent has multiple IPv4 >> addresses, it MUST choose one for allocating the candidate. If a >> host is dual-stack, it is RECOMMENDED that it allocate one IPv4 >> candidate and one global IPv6 address. With the lite = implementation, >> ICE cannot be used to dynamically choose amongst candidates. >> Therefore, including more than one candidate from a particular = scope >> is NOT RECOMMENDED, since only a connectivity check can truly >> determine whether to use one address or the other. >>=20 >> I find it quite strange that the above text says there can only be = single >> IPv4 >> based candidate, while for IPv6 a LITE implementation may have one >> candidate >> per IPv6 address. Isn't the LITE implication of having multiple >> candidates for >> the same address family similar? Yes, IPv6 kind of forces the need = for >> dealing >> with multiple IPv6 addresses on any host. However, I can see that = certain >> servers will actually be multi-homed in IPv4 and thus can in a = sensible >> way >> actually have multiple IPv4 candidates, and let the clients select = which >> interface has the best reachability. >>=20 >> Can you please be explicit on what in ICE prevents things to work for >> IPv4 but >> the same case works for IPv6? >=20 > This is text from RFC 5245. I agree it is confusing, and unfortunately = I > don=C2=A1=C2=AFt have a good answer. >=20 > I guess my approach would be to suggest that we simply remove the > restriction. In addition, there is generic text about dual-stack etc > elsewhere, > and I don=C2=A1=C2=AFt see anything ICE lite specific. >=20 > OLD: >=20 > "Lite implementations only utilize host candidates. A lite > implementation MUST, for each component of each data stream, = allocate > zero or one IPv4 candidates. It MAY allocate zero or more IPv6 > candidates, but no more than one per each IPv6 address utilized by > the host. Since there can be no more than one IPv4 candidate per > component of each data stream, if an ICE agent has multiple IPv4 > addresses, it MUST choose one for allocating the candidate. If a > host is dual-stack, it is RECOMMENDED that it allocate one IPv4 > candidate and one global IPv6 address. With the lite = implementation, > ICE cannot be used to dynamically choose amongst candidates. > Therefore, including more than one candidate from a particular scope > is NOT RECOMMENDED, since only a connectivity check can truly > determine whether to use one address or the other." >=20 >=20 > NEW: >=20 > "Lite implementations only utilize host candidates. > With the lite implementation, ICE cannot be used to dynamically choose > amongst candidates. Therefore, including more than one candidate from = a > particular IP address family is NOT RECOMMENDED, since only a = connectivity > check can Truly determine whether to use one address or the other.=E2=80= =9D >=20 We should avoid making non-critical changes to text that was unchanged = from 5245 at this point in the process. If people think this is = important to change, it needs working group discussion. This is a hazard = of bis drafts=E2=80=94it=E2=80=99s really hard to tell when you are = done. :-) I am guessing that the original motivation was that, since ICE-lite = cannot select among candidates, you want the minimum number of = candidates necessary per address family. Multiple IPv6 candidates are = allowed because of the nature of IPv6. But I think if you are truly = multi-homed, you probably shouldn=E2=80=99t be using ICE-lite. Ben. --Apple-Mail=_11805A38-32D9-400B-A214-F4DDAA087D84 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpwoiQACgkQgFZKbJXz 1A1Jkg/+IeMc/r4tHyj0YX5kf/C2kkk6rwHXTHqLxAHaRfhYa9tgFNmOghRi8U2f zqY6rpQhhAJQRc8x/+Cmv7n3BJfYpheNIWiAoyCZYheka+wQNodX3Gf0rXSNWERx m//kuAUsJpiSRRZauCCE0nFMqjTvn0/bZTM+bfP8w+maE7M6EzcBp6L9EJtPt0mY v0yD9bvzKXbaFsZJc0Xj7aLKjXUd55v1+rovCUB2HZBKV4XUl60XxRooJ5scupGL gQ/AcFogh1s1FpgMO0HNeDXAnfDqhuvU2fgV5+WWgWEI5toYYzRNEEDUlmVNYK7X AMICCqEyqT2XNUMZUmd+hQs7EclqwPRqvtYY7exJd6KVj1q6kiYJqTqEwvCHH4k+ 92U16rEIT6n5EJCz/VmKhGyYn0Ktykg8pwomqQSYIeqi6VnwX3eTxyypmvl4rUIL J5nWVqmlv0tLk7g+Y79b7qfxt+mXpPqQURazYnOy6ZSCnn6bi+3J32LLsOXE9gyw PYObiSqxB7SCEOdplgZQLlGvvMZauDbiYGYZDSxLnIOCdUqftBihXTXTaJ5CKOW5 DdXWrVASGvODjFymNNlpcpqw2W97LGroBoJD1SQDucSeV63f9X3zzpTGw5yL9O+T JBdparDEVCMMsScUu4XNHxh85YIvChvFsJhVZEskDWPFy4XzOgE= =U9Sh -----END PGP SIGNATURE----- --Apple-Mail=_11805A38-32D9-400B-A214-F4DDAA087D84-- From nobody Wed Jan 31 06:42:51 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E86131B35 for ; Wed, 31 Jan 2018 06:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6BLErajCNsj for ; Wed, 31 Jan 2018 06:42:41 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF366131B91 for ; Wed, 31 Jan 2018 06:39:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517409554; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=MypaGRKItGlda/LgU6E5riFrwV9GkkVawrq5ijuohMQ=; b=G3pDIVFMw5txAMeT4+U+TZZeuVpxyBQVMc2f0Oh02ZpWad5rhGmbqttP6tepAx/r g4+wRxbt/asR1gAQ03pZk8y+qpXLqS5ZKIKk6abwUyKTvuoBGufJgXZ5Mj4Tcgnv UtTXXGvGcJGAUpEIlTfG0kW1bLp8EbyJo+suLlRiJbk=; X-AuditID: c1b4fb30-11d5e9c000006bc7-76-5a71d5124cb4 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D1.14.27591.215D17A5; Wed, 31 Jan 2018 15:39:14 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0352.000; Wed, 31 Jan 2018 15:39:13 +0100 From: Christer Holmberg To: Stephen Farrell , "secdir@ietf.org" CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-ice-rfc5245bis-16 Thread-Index: AQHTlsWSdlXqvNmVDEWzQ6CHG1vNgKOG2QlggAVgroCAAFA6gP//5hCAgAG49wA= Date: Wed, 31 Jan 2018 14:39:12 +0000 Message-ID: References: <151698534014.492.17944720668568287169@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C143E76@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUyM2K7t67Q1cIogwcXxC2O//jDbvHtQq3F s43zWSw+LHzIYjF97zV2B1aPtd1X2TyWLPnJFMAUxWWTkpqTWZZapG+XwJXxovMqc8GD1YwV C/sjGxjXLGfsYuTkkBAwkWh++JsZxBYSOMwosf43dxcjF5C9hFFi7v4FLF2MHBxsAhYS3f+0 QWpEBMIk7r8/xApSwywwk1Hi9c+XYIOEBVwkXj3+wwRR5CqxctMPKNtP4sTqTrAFLAKqEveb /7OD2LwC1hJts09DLZ7HJHH5ujGIzSlgK7Hv3wewOKOAmMT3U2vA5jALiEvcejKfCeJoAYkl e84zQ9iiEi8f/2MFsUUF9CQ2nLjNDnKzhICixPJ+OYhWLYkvP/axQdjWEoc2NLJD2IoSU7of Qp0jKHFy5hOWCYzis5Bsm4WkfRaS9llI2mchaV/AyLqKUbQ4tTgpN93ISC+1KDO5uDg/Ty8v tWQTIzAWD275bbCD8eVzx0OMAhyMSjy8Mw4VRgmxJpYVV+YeYpTgYFYS4d1zESjEm5JYWZVa lB9fVJqTWnyIUZqDRUmc96Qnb5SQQHpiSWp2ampBahFMlomDU6qBcfHLb1d+u/xp27nR/pPG VtFZPn7N7o5H1dd23tHKuZx/ZllJ0pVtX03fP2l81easFOR70tnITtXd71rrcXvu3Vrs86pW 6Oy8veP7RLnuk1KLXsYZn1D0No87w7AtWo3j4CKJF9r8ezg/zf2Q/OdyzQev2pyU4g2iO76f so34VvxojydD27bJz5VYijMSDbWYi4oTAZv9qrXBAgAA Archived-At: Subject: Re: [Ice] Secdir last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 14:42:45 -0000 SGksDQoNCkmhr3ZlIHVwZGF0ZWQgdGhlIHB1bGwgcmVxdWVzdCB3aXRoIGNoYW5nZXMgYmFzZWQg b24gU3RlcGhlbqGvcyBzZWMtZGlyDQpyZXZpZXcuDQoNCkkgYW0gc3RpbGwgbG9va2luZyB3aGV0 aGVyIHRoZXJlIGlzIHNvbWV0aGluZyB0aGF0IGNvdWxkIGJlIGFkZGVkDQpyZWdhcmRpbmcgV2Vi UlRDIElQIGxlYWthZ2UuDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9pY2Utd2cvcmZjNTI0NWJpcy9w dWxsLzU3DQoNCg0KSSBoYXZlIG5vdCB5ZXQgY29tbWl0dGVkIGFueSBjaGFuZ2VzIGJhc2VkIG9u IE1hZ251c6GvIHRydi1kaXIgcmV2aWV3Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0K DQpPbiAzMC8wMS8xOCAxNjozMiwgIlN0ZXBoZW4gRmFycmVsbCIgPHN0ZXBoZW4uZmFycmVsbEBj cy50Y2QuaWU+IHdyb3RlOg0KDQo+DQo+SGl5YSwNCj4NCj5UaG9zZSBsb29rIGNsb3NlLWVub3Vn aCBvciBmaW5lIHRvIG1lLiBGb3IgdGhlDQo+cmVjZW50IFdlYlJUQyB0aHJlYWQsIGlmIHlvdSBm aW5kIHNvbWV0aGluZywgdGhhdCdsbA0KPmJlIGEgZ29vZCB0aGluZy4gSWYgbm90LCBhbmQgbm9i b2R5IHN1Z2dlc3RzIHNvbWUNCj50ZXh0LCB0aGVuIEkgZ3Vlc3MgYXQgbGVhc3Qgd2UgZGlkIHRy eTotKSBBbmQgRldJVyBJJ20NCj5maW5lIHdpdGggdGhhdCwgYXMgSSdtIG5vdCB1cCB0byBzcGVl ZCBvbiBub24tV2ViUlRDDQo+dXNlcyBvZiBJQ0UsIHNvIGRvbid0IGtub3cgaWYgdGhlIHNhbWUg bGVha2FnZSBpc3N1ZXMNCj5jYW4gYXJpc2UgaW4gcmVhbGl0eSwgb3V0c2lkZSBvZiBXZWJSVEMu DQo+DQo+VGhhbmtzLA0KPlMuDQo+DQo+T24gMzAvMDEvMTggMTM6NTMsIENocmlzdGVyIEhvbG1i ZXJnIHdyb3RlOg0KPj4gSGksDQo+PiANCj4+Pj4+IFJldmlld2VyOiBTdGVwaGVuIEZhcnJlbGwg UmV2aWV3IHJlc3VsdDogSGFzIElzc3Vlcw0KPj4+Pj4NCj4+Pj4+ICgxKSBJIHRoaW5rIGEgYml0 IG1vcmUgd29yayBvbiB0aGUgc2VjdXJpdHkgYW5kIHByaXZhY3kgaXNzdWVzDQo+Pj4+PiBhcm91 bmQgSUNFIHdvdWxkIGltcHJvdmUgPnRoZSBkb2N1bWVudCwgYW5kIGhvcGVmdWxseSwgSUNFDQo+ Pj4+PiBpbXBsZW1lbnRhdGlvbnMuDQo+Pj4+Pg0KPj4+Pj4gLSBUaGVyZSBoYXMgYmVlbiAoSU1P IHNvbWV3aGF0IGp1c3RpZmllZCkgY29uY2VybiBbMV0gYWJvdXQNCj4+Pj4+IGV4cG9zaW5nIGFs bCBwb3NzaWJsZSA+YWRkcmVzc2VzLCBmb3IgZXhhbXBsZSB3aGVyZSBvbmUgaXMgZnJvbSBhDQo+ Pj4+PiBWUE4gaW50ZW5kZWQgdG8gcHJlc2VydmUgcHJpdmFjeSwgc2F5IGlmIGEgPnVzZXIgaXMg YWltaW5nIHRvDQo+Pj4+PiBjaXJjdW12ZW50IGxvY2FsIGNlbnNvcnNoaXAgb3Igc3VydmVpbGxh bmNlLiAgNS4xLjEuMSBoYXMgYSBTSE9VTEQNCj4+Pj4+IHRoYXQsID5hcyBJIHJlYWQgaXQsIHNh eXMgdG8gYWx3YXlzIGluY2x1ZGUgc3VjaCBhZGRyZXNzZXMuDQo+Pj4+Pg0KPj4+Pj4gWzFdIGh0 dHBzOi8vd3d3LnczLm9yZy93aWtpL1ByaXZhY3kvSVBBZGRyZXNzZXMNCj4+Pj4+DQo+Pj4+PiAo Tm90ZTogSSdtIG5vdCBjbGFpbWluZyBbMV0gaXMgYXV0aG9yaXRhdGl2ZSwgaXQncyBqdXN0IGEg cGFnZSBJDQo+Pj4+PiBmb3VuZCB0aGF0IGRlc2NyaWJlcyB0aGUgaXNzdWUgcmVhc29uYWJseSB3 ZWxsLikNCj4+Pj4+DQo+Pj4+PiBUaGVyZSBpcyBhIGJpdCBvZiB0ZXh0IGFib3V0IHRoaXMgKDFz dCBwYXJhIGluIHNlY3Rpb24gMTkpLCBidXQgSU1PDQo+Pj4+PiBpdCdzIGEgYml0IHdlYWsuDQo+ Pj4+Pg0KPj4+Pj4gLSBEaWQgdGhlIFdHIGNvbnNpZGVyIFJFUVVJUklORyBvciBSRUNPTU1FTkRJ TkcgYWdlbnQNCj4+Pj4+IGltcGxlbWVudGF0aW9ucyBwcm92aWRlIHNvbWUgbG9jYWwgaW50ZXJm YWNlIHRoYXQgYWxsb3dzIHRoZSBob3N0DQo+Pj4+PiBvciBhbiBhcHBsaWNhdGlvbiB0byBzYXkg IkRvbid0IHVzZSA8dGhpcz4gaW50ZXJmYWNlIHRvIGdlbmVyYXRlDQo+Pj4+PiBhbnkgY2FuZGlk YXRlcyB1bnRpbCBJIHRlbGwgeW91IG90aGVyd2lzZSI/ICBUaGF0IG1pZ2h0IGJlIGJldHRlcg0K Pj4+Pj4gdGhhbiBoYXZpbmcgVlBOIG9wZXJhdG9ycyByZWNvbW1lbmRpbmcgdG8gdHVybiBvZmYg V2ViUlRDIGVudGlyZWx5DQo+Pj4+PiBmb3IgZXhhbXBsZS4gKE5vdGU6IHRoaXMgaXMgbXkgbWFp biBjb21tZW50LCB0aGUgcmVzdCBhcmUgbW9zdGx5DQo+Pj4+PiBzdWdnZXN0ZWQgdGhpbmdzIHRv IHRoaW5rIGFib3V0LCBpZiB5b3UndmUgbm90IGFscmVhZHkuKQ0KPj4+Pj4NCj4+Pj4+IC0gRXZl biBpZiB0aGUgdGV4dCBpc24ndCBjaGFuZ2VkLCBhIHJlZmVyZW5jZSB0byBbMl0gd291bGQgSSB0 aGluaw0KPj4+Pj4gYmUgdXNlZnVsLiAoQXNzdW1pbmcgWzJdIGlzIHN0aWxsIGJlaW5nIHdvcmtl ZCBvbiBpbiBydGN3ZWIsIHRob3VnaA0KPj4+Pj4gbWluZCB5b3UsIEkgZG9uJ3QgbGlrZSBob3cg WzJdIHJlZmVycyB0byAiY29uc2VudCIgYXMgSSBkb3VidCBhDQo+Pj4+PiByYW5kb20gcGVyc29u IGNhbiByZWFsbHkgcHJvdmlkZSBtZWFuaW5nZnVsIGNvbnNlbnQgZm9yIHRoaW5ncyBsaWtlDQo+ Pj4+PiB0aGlzLikNCj4+Pj4+DQo+Pj4+PiBbMl0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtcnRjd2ViLWlwLWhhbmRsaW5nLTA0DQo+Pj4+DQo+Pj4+IEkgd291bGQgbm90 IHdhbnQgdG8gUkVRVUlSRSBpbXBsZW1lbnRpbmcgYSBsb2NhbCBpbnRlcmZhY2UgZm9yDQo+Pj4+ IGNvbnRyb2xsaW5nIHRoZSBjYW5kaWRhdGVzLCBhcyBJQ0UgaXMgYWxzbyB1c2VkIGJ5IGRpZmZl cmVudCB0eXBlcyBvZg0KPj4+PiBuZXR3b3JrIGVudGl0aWVzIChnYXRld2F5cyBldGMpLiBCdXQs IEkgYW0gb2sgdG8gUkVDT01NRU5ELg0KPj4+DQo+Pj4gRmFpciBlbm91Z2guDQo+Pj4NCj4+Pj4N Cj4+Pj4gV2hhdCBhYm91dDoNCj4+Pj4NCj4+Pj4gT0xEOg0KPj4+Pg0KPj4+PiAiSW5kaXZpZHVh bCBpbXBsZW1lbnRhdGlvbnMgbWF5IGFsc28gaGF2ZSBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYw0K Pj4+PiBydWxlcyBmb3IgY29udHJvbGxpbmcgd2hpY2ggYWRkcmVzc2VzIGFyZSByZXZlYWxlZC4i DQo+Pj4+DQo+Pj4+IE5FVzoNCj4+Pj4NCj4+Pj4gIkluZGl2aWR1YWwgaW1wbGVtZW50YXRpb25z IG1heSBhbHNvIGhhdmUgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMNCj4+Pj4gcnVsZXMgZm9yIGNv bnRyb2xsaW5nIHdoaWNoIGFkZHJlc3NlcyBhcmUgcmV2ZWFsZWQuIEl0IGlzIFJFQ09NTUVOREVE DQo+Pj4+IHRoYXQgYXBwbGljYXRpb25zIGludGVyYWN0aW5nIHdpdGggaHVtYW4gdXNlcnMgcHJv dmlkZSBhIHVzZXINCj4+Pj4gaW50ZXJmYWNlcyB0aGF0IGFsbG93cyB0aGUgdXNlcnMgdG8gY29u dHJvbCB3aGljaCBpbnRlcmZhY2VzIGFyZSB1c2VkDQo+Pj4+IHRvIGdlbmVyYXRlIGNhbmRpZGF0 ZXMsIG9yIHdoZW4gdG8gdXNlIGNhbmRpZGF0ZXMgZ2VuZXJhdGVkIGZvciB0aGUNCj4+Pj4gaW50 ZXJmYWNlcy4NCj4+Pj4NCj4+Pj4gW1JFRi10by0gZHJhZnQtaWV0Zi1ydGN3ZWItaXAtaGFuZGxp bmddIHByb3ZpZGUgYWRkaXRpb25hbA0KPj4+PiBpbmZvcm1hdGlvbiBhbmQgUmVxdWlyZW1lbnRz IHJlZ2FyZGluZyB0aGUgaGFuZGluZyBvZiBJUCBhZGRyZXNzZXMNCj4+Pj4gZm9yIFdlYlJUQyBh cHBsaWNhdGlvbnMuIg0KPj4+DQo+Pj4gVGhhdCdzIGEgZmluZSBpbXByb3ZlbWVudCBmcm9tIG15 IFBPViwgZXNwIGlmIGZvbGtzIHdpbGwNCj4+PiByZWFsbHkgcHJvdmlkZSBzdWNoIGludGVyZmFj ZXMuIEknbSBub3Qgc3VyZSAiaW50ZXJhY3RpbmcNCj4+PiB3aXRoIGh1bWFucyIgaXMgcXVpdGUg cmlnaHQgdGhvdWdoLCBtYXliZSBpdCdkIGJlIGJldHRlcg0KPj4+IHRvIGFkZCBhIHJlZmVyZW5j ZSB0byB0aGUgcHJvYmxlbSAodmlhIFsxXSBvciBbcnRjd2ViLWlwXSkNCj4+PiBhbmQgdG8gdGhl biBzYXkgIkltcGxlbWVudGF0aW9ucyB3aGVyZSBzdWNoIGlzc3VlcyBjYW4NCj4+PiBhcmlzZSBh cmUgUkVDT01NRU5ERUQgdG8uLi4iIEknZCBhbHNvIHN1Z2dlc3QgbWF5YmUNCj4+PiBzL3VzZXIg aW50ZXJmYWNlL2ludGVyZmFjZS8gdGhlcmUsIGFzIGUuZy4gYSBWUE4gY2xpZW50DQo+Pj4gbWln aHQgd2FudCB0byB1c2UgYW4gQVBJIHByb3ZpZGVkIGJ5IGFuIElDRSBpbXBsZW1lbnRhdGlvbg0K Pj4+IHNvIHRoZSBVSSBtaWdodCBiZSBwYXJ0IG9mIHRoZSBWUE4gY2xpZW50IGFuZCBub3QgdGhl IElDRQ0KPj4+IGltcGxlbWVudGF0aW9uLiBTbywgb3ZlcmFsbCBJJ2Qgc3VnZ2VzdCBzb21ldGhp bmcgbGlrZQ0KPj4+IHRoaXM6DQo+Pj4NCj4+PiAiSW5kaXZpZHVhbCBpbXBsZW1lbnRhdGlvbnMg bWF5IGFsc28gaGF2ZSBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYw0KPj4+IHJ1bGVzIGZvciBjb250 cm9sbGluZyB3aGljaCBhZGRyZXNzZXMgYXJlIHJldmVhbGVkLiBGb3IgZXhhbXBsZSwNCj4+PiBb UkVGLXRvLSBkcmFmdC1pZXRmLXJ0Y3dlYi1pcC1oYW5kbGluZ10gcHJvdmlkZXMgYWRkaXRpb25h bA0KPj4+IGluZm9ybWF0aW9uIGFib3V0IHRoZSBwcml2YWN5IGFzcGVjdHMgb2YgcmV2ZWFsaW5n IElQIGFkZHJlc3Nlcw0KPj4+IHZpYSBJQ0UgZm9yIFdlYlJUQyBhcHBsaWNhdGlvbnMuIElDRSBp bXBsZW1lbnRhdGlvbnMgd2hlcmUgc3VjaA0KPj4+IGlzc3VlcyBjYW4gYXJpc2UgYXJlIFJFQ09N TUVOREVEIHRvIHByb3ZpZGUgYSBwcm9ncmFtbWF0aWMgb3INCj4+PiB1c2VyIGludGVyZmFjZSB0 aGF0IHByb3ZpZGVzIGNvbnRyb2wgb3ZlciB3aGljaCBuZXR3b3JrIGludGVyZmFjZXMNCj4+PiBh cmUgdXNlZCB0byBnZW5lcmF0ZSBjYW5kaWRhdGVzLiINCj4+IA0KPj4gTG9va3MgZ29vZCA6KQ0K Pj4gDQo+PiAtLS0NCj4+IA0KPj4+Pg0KPj4+Pj4gLSBTZXBhcmF0ZWx5IFsxXSBhbHNvIGRlc2Ny aWJlcyBhbm90aGVyIHBvdGVudGlhbCBwcml2YWN5IGlzc3VlDQo+Pj4+PiB3aXRoIFNUVU4gdXJs cy4gSSB0aGluayBpdCdkIGJlIHdvcnRod2hpbGUgbm90aW5nIHN1Y2ggaXNzdWVzIHRoYXQNCj4+ Pj4+IGhhdmUgYmVlbiBmb3VuZCB3aXRoIGRlcGxveW1lbnRzIG9mIElDRSBoZXJlLCBhcyBhbnkg cHJvdG9jb2wgdXNpbmcNCj4+Pj4+IElDRSBhbmQgYWNjZXB0aW5nIG5vbiBsb2NhbGx5IGNvbmZp Z3VyZWQgU1RVTi9UVVJOIFVSTHMgbWF5IGhhdmUNCj4+Pj4+IGlzc3VlcyBsaWtlIHRoYXQuIEZv ciBleGFtcGxlLCBhIHJlY2VudCBwYXBlciBbM10gYWxzbyBkZXNjcmliZXMNCj4+Pj4+IHNvbWUg YXR0YWNrcyAoaW4gc2VjdGlvbiA0LjIgbW9zdGx5KSB0aGF0IGNvdWxkIChJIGd1ZXNzKSBiZQ0K Pj4+Pj4gbW91bnRlZCBhZ2FpbnN0IGFueSBJQ0UgYWdlbnQgYW5kIG5vdCBvbmx5IFdlYlJUQyBj bGllbnRzLiBUaGF0J2QNCj4+Pj4+IGJlIHdvcnRoIGEgcmVmZXJlbmNlIGFuZCBtYXliZSB0aGlu a2luZyBhYm91dCB3aGljaCBhdHRhY2tzIGFyZQ0KPj4+Pj4gZ2VuZXJpYyBJQ0UgaXNzdWVzIGFu ZCBkb24ndCBvbmx5IGFmZmVjdCBXZWJSVEMuDQo+Pj4+Pg0KPj4+Pj4gWzNdIGh0dHBzOi8vZG9p Lm9yZy8xMC4xMTQ1LzMwMTk2MTIuMzAxOTg0NA0KPj4+Pg0KPj4+PiBJIGFtIHN0cnVnZ2xpbmcg dG8gZmlndXJlIG91dCBleGFjdGx5IHdoYXQgdG8gZG8gaGVyZS4uLiBJIHJlYWxseQ0KPj4+PiBo b3BlIHdlIGRvbid0IGhhdmUgdG8gcGVyZm9tIGEgc3R1ZHkgb24gWzNdLCBhbmQgc2VlIHdoYXQg aXMgZ2VuZXJhbCwNCj4+Pj4gYW5kIHdoYXQgaXMgV2ViUlRDLXNwZWNpZmljLiBBcmUgd2UgZXZl biBhbGxvd2VkIHRvIHJlZmVyZW5jZSBbM10sIGFzDQo+Pj4+IGl0J3Mgbm90IGZyZWVseSBhdmFp bGFibGU/DQo+Pj4NCj4+PiBTdXJlLCB3ZSBjYW4gcmVmZXJlbmNlIGFjYWRlbWljIHBhcGVycyBi ZWhpbmQgcGF5d2FsbHMsIGFuZA0KPj4+IHRoZXJlJ3Mgb2Z0ZW4gYW5vdGhlciB2ZXJzaW9uIGF2 YWlsYWJsZSB0aGF0J3Mgbm90LiAoTm90IHN1cmUNCj4+PiBpbiB0aGlzIGNhc2UuKQ0KPj4+DQo+ Pj4+DQo+Pj4+IFNvbWUgaGVscCBhbmQgZ3VpZGFuY2Ugd291bGQgYmUgYXBwcmVjaWF0ZWQgOikN Cj4+Pg0KPj4+IEkgZ3Vlc3MgYWJvdXQgYXMgbXVjaCBhcyBjYW4gYmUgZG9uZSB3aXRoIHRoaXMg LWJpcyBlZmZvcnQgaXMNCj4+PiB0byBub3RlIHdoZXJlIGFueSBsZWFrYWdlcyBoYXZlIGJlZW4g Zm91bmQuIFRoZXJlJ3MgYmVlbiBzb21lDQo+Pj4gcmVjZW50IHRyYWZmaWMgb24gdGhlIFczQyBX ZWJSVEMgbGlzdCBhYm91dCB0aGF0IEkgdGhpbmssIChpbg0KPj4+IHRoZSB0aHJlYWQgYWJvdXQg Q1NQIGlpcmMpIHNvIG1heWJlIGEgdHJhd2wgb2YgdGhhdCB0aHJlYWQNCj4+PiB3aWxsIHN1Z2dl c3Qgc29tZSB0ZXh0Pw0KPj4gDQo+PiBJIGRpZCBmb2xsb3cgdGhhdCBkaXNjdXNzaW9uLiBJIHdp bGwgdGFrZSBhIHNlY29uZCBsb29rLg0KPj4gDQo+PiAtLS0NCj4+IA0KPj4+Pj4gLSBJIGFsc28g d29uZGVyZWQgaWYgSSBjYW4gZmluZ2VycHJpbnQgYSBob3N0IGJhc2VkIG9uIGhvdyBpdCBkb2Vz DQo+Pj4+PiBJQ0U/IEkgIHN1c3BlY3QgdGhhdCBtaWdodCB3b3JrLCBidXQgaGF2ZW4ndCB0cmll ZCB0byBmaWd1cmUgb3V0DQo+Pj4+PiBkZXRhaWxzLg0KPj4+Pj4NCj4+Pj4+IC0gQ291bGQgSSBw cm9iZSBhbiBpbnRlcm5hbCBuZXR3b3JrIGJhc2VkIG9uIGZlZWRpbmcgaXQgY2FuZGlkYXRlcw0K Pj4+Pj4gdG8gY2hlY2s/IEUuZy4gY2hlY2tpbmcgdGltaW5nIG9mIHJlYWN0aW9ucy4gIElmIEkg Y291bGQgdGhhdCBzZWVtcw0KPj4+Pj4gbm90ZXdvcnRoeS4NCj4+Pj4NCj4+Pj4gU29tZXRoaW5n IGxpa2U/DQo+Pj4+DQo+Pj4+ICJCYXNlZCBvbiB0aGUgdHlwZXMgb2YgY2FuZGlkYXRlcyBwcm92 aWRlZCBieSB0aGUgcGVlciwgYW5kIHRoZQ0KPj4+PiByZXN1bHRzIG9mIHRoZSBjb25uZWN0aXZp dHkgdGVzdHMgcGVyZm9ybWVkIEFnYWluc3QgdGhvc2UgY2FuZGlkYXRlcywNCj4+Pj4gYW4gYWdl bnQgbWlnaHQgYmUgYWJsZSB0byBkZXRlcm1pbmUgY2hhcmFjdGVyaXN0aWNzIG9mIHRoZSBwZWVy DQo+Pj4+IG5ldHdvcmsuIg0KPj4+DQo+Pj4gTWF5YmU6DQo+Pj4NCj4+PiAiQmFzZWQgb24gdGhl IHR5cGVzIG9mIGNhbmRpZGF0ZXMgcHJvdmlkZWQgYnkgdGhlIHBlZXIsIGFuZCB0aGUNCj4+PiBy ZXN1bHRzIG9mIHRoZSBjb25uZWN0aXZpdHkgdGVzdHMgcGVyZm9ybWVkIGFnYWluc3QgdGhvc2Ug Y2FuZGlkYXRlcywNCj4+PiB0aGUgcGVlciBtaWdodCBiZSBhYmxlIHRvIGRldGVybWluZSBjaGFy YWN0ZXJpc3RpY3Mgb2YgdGhlIGxvY2FsDQo+Pj4gbmV0d29yaywgZS5nLiBpZiBkaWZmZXJlbnQg dGltaW5ncyBhcmUgYXBwYXJlbnQgdG8gdGhlIHBlZXIuIEluDQo+Pj4gdGhlIGxpbWl0IHRoZSBw ZWVyIG1pZ2h0IGJlIGFibGUgdG8gcHJvYmUgdGhlIGxvY2FsIG5ldHdvcmsuIg0KPj4+DQo+Pj4g VGhhdCBzYWlkIC0gSSdtIG5vdCBjbGFpbWluZyB0aGlzIGlzIHBvc3NpYmxlIGZvci1zdXJlLCBJ IGp1c3QNCj4+PiBiZXQgaXQgd291bGQgYmU6LSkNCj4+IA0KPj4gVGhlIHRleHQgbG9va3MgZ29v ZC4NCj4+IA0KPj4gLS0tDQo+PiANCj4+Pj4+ICgyKSA1LjM6ICIuLi5NVVNUIGNvbnRhaW4gLi4u IDxmb28+IGJpdHMgb2YgcmFuZG9tbmVzcyIgRG9uJ3QgeW91DQo+Pj4+PiBuZWVkIHRvIHNheSB3 aGVuIHRoZXNlIHZhbHVlcyBNVVNUIGJlIGRpZmZlcmVudCBhbmQgd2hlbiB0aGV5J3JlIG9rDQo+ Pj4+PiB0byBiZSByZS11c2VkPyBJIGZvcmdldCBpZiBTVFVOL1RVUk4gZG8gdGhhdC4NCj4+Pj4N Cj4+Pj4gU2VjdGlvbiA3LjIuMiBzYXlzOg0KPj4+Pg0KPj4+PiAiQSBjb25uZWN0aXZpdHkgY2hl Y2sgQmluZGluZyByZXF1ZXN0IE1VU1QgdXRpbGl6ZSB0aGUgU1RVTg0KPj4+PiBzaG9ydC10ZXJt IGNyZWRlbnRpYWwgbWVjaGFuaXNtLiINCj4+Pj4NCj4+Pj4gUkZDIDUzODkgKFNUVU4pIHNheXM6 DQo+Pj4+DQo+Pj4+ICJTaG9ydC1UZXJtIENyZWRlbnRpYWw6ICBBIHRlbXBvcmFyeSB1c2VybmFt ZSBhbmQgYXNzb2NpYXRlZA0KPj4+PiBwYXNzd29yZCB0aGF0IHJlcHJlc2VudCBhIHNoYXJlZCBz ZWNyZXQgYmV0d2VlbiBjbGllbnQgYW5kIHNlcnZlci4NCj4+Pj4gU2hvcnQtIHRlcm0gY3JlZGVu dGlhbHMgYXJlIG9idGFpbmVkIHRocm91Z2ggc29tZSBraW5kIG9mIHByb3RvY29sDQo+Pj4+IG1l Y2hhbmlzbSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHNlcnZlciwgcHJlY2VkaW5nIHRoZSBTVFVO IGV4Y2hhbmdlLg0KPj4+PiBBIHNob3J0LXRlcm0gY3JlZGVudGlhbCBoYXMgYW4gZXhwbGljaXQg dGVtcG9yYWwgc2NvcGUsIHdoaWNoIG1heSBiZQ0KPj4+PiBiYXNlZCBvbiBhIHNwZWNpZmljIGFt b3VudCBvZiB0aW1lIChzdWNoIGFzIDUgbWludXRlcykgb3Igb24gYW4gZXZlbnQNCj4+Pj4gKHN1 Y2ggYXMgdGVybWluYXRpb24gb2YgYSBTSVAgZGlhbG9nKS4gVGhlIHNwZWNpZmljIHNjb3BlIG9m IGENCj4+Pj4gc2hvcnQtdGVybSBjcmVkZW50aWFsIGlzIGRlZmluZWQgYnkgdGhlIGFwcGxpY2F0 aW9uIHVzYWdlLiINCj4+Pj4NCj4+Pj4gSWYgYW55dGhpbmcgZXh0cmEgaXMgbmVlZGVkLCBJIHRo aW5rIHRoYXQgc2hvdWxkIGJlIGRvbmUgYXMgYW4gdXBkYXRlDQo+Pj4+IHRvIFNUVU4uDQo+Pj4N Cj4+PiBOb3Qgc3VyZSBJIGFncmVlIC0gbWF5YmUgSSB3YXNuJ3QgY2xlYXIgaW4gbXkgY29tbWVu dCB0aG91Z2gsDQo+Pj4gc28gbGV0IG1lIHRyeSByZXBocmFzZSBpdC4NCj4+Pg0KPj4+IFNUVU4g ZG9lc24ndCBkZWZpbmUgdGhlIGR1cmF0aW9uIGZvciB3aGljaCBzaG9ydC10ZXJtIGNyZWRzDQo+ Pj4gYXJlIE9LIHRvIGJlIHVzZWQuIElDRSBkb2VzIGRlZmluZSBhIHNlc3Npb24gY29uY2VwdCB0 aGVyZWZvcmUNCj4+PiBJQ0Ugb3VnaHQgdG8gc2F5IGlmIHNob3J0IHRlcm0gU1RVTiBjcmVkcyBN VVNUL01VU1QtTk9UL01BWQ0KPj4+IChvciB3aGF0ZXZlcikgYmUgcmUtdXNlZCBpbiBkaWZmZXJl bnQgSUNFIHNlc3Npb25zLiBFdmVuDQo+Pj4gd2l0aGluIGFuIElDRSBzZXNzaW9uIEkgZ3Vlc3Mg aW4gdGhlb3J5IG9uZSBjb3VsZCByZXF1aXJlDQo+Pj4gZGlmZmVyZW50IHNob3J0LXRlcm0gU1RV TiBjcmVkZW50aWFscyBldmVyeSBzaW5nbGUgdGltZSwgb3INCj4+PiBub3QuIFNvIEkgZG8gdGhp bmsgdGhlcmUncyBzb21ldGhpbmcgdG8gYmUgc2FpZCBoZXJlLg0KPj4gDQo+PiBTZWN0aW9uIDkg c2F5cyB0aGF0IGFuIGFnZW50IG11c3QgY3JlYXRlIGEgbmV3IHVzZXJuYW1lIGZyYWdtZW50IGFu ZA0KPj4gcGFzc3dvcmQgZm9yIGV2ZXJ5IG5ldyBJQ0Ugc2Vzc2lvbjoNCj4+IA0KPj4gICAgICAi VG8gcmVzdGFydCBJQ0UsIGFuIGFnZW50IE1VU1QgY2hhbmdlIGJvdGggdGhlIHBhc3N3b3JkIGFu ZCB0aGUNCj4+ICAgICAgIHVzZXJuYW1lIGZyYWdtZW50IGZvciB0aGUgZGF0YSBzdHJlYW0ocykg YmVpbmcgcmVzdGFydGVkLqn3DQo+PiANCj4+IA0KPj4gU2luY2UgSSBhbHNvIHVzZXMgdGhlIHVz ZXJuYW1lIHRvIGlkZW50aXR5IHRoZSBJQ0Ugc2Vzc2lvbiwgdGhlIHZhbHVlcw0KPj4gY2Fubm90 IGJlIGNoYW5nZWQgd2l0aGluIGEgc2Vzc2lvbi4NCj4+IA0KPj4gVGhlcmUgaXMgbm8gdGV4dCBv biB3aGVuIGEgdmFsdWUgY2FuIGJlIHJlLXVzZWQgLSBhcGFydCBmcm9tIHRoZSBmYWN0DQo+PnRo YXQNCj4+IHRoZXkgY2Fubm90IGJlIHJlLXVzZWQgd2hlbiBhbiBJQ0UgcmVzdGFydCB0YWtlcyBw bGFjZS4NCj4+IA0KPj4gTXkgYXNzdW1wdGlvbiBoYXMgYmVlbiB0aGF0IHRoZSByYW5kb21uZXNz IGNyaXRlcmlhIGFyZSBhc3N1bWVkIHRvDQo+PmVuc3VyZQ0KPj4gdGhhdCB0d28gYWdlbnRzIGRv bqn2dCBjaG9vc2UgdGhlIHNhbWUgdmFsdWVzIGZvciB0aGUgc2FtZSBzZXNzaW9uLCBhbmQNCj4+ IHRoYXQgdmFsdWVzIGFyZSB1bmxpa2VseSB0byBiZSByZS11c2VkIHdpdGhpbiBhIHNob3J0IHBl cmlvZCBvZiB0aW1lLg0KPj4gDQo+PiBXZSBjb3VsZCBzYXkgdGhhdCBhZ2VudHMgc2hhbGwgdmVy aWZ5IHRoYXQgdGhlIHNhbWUgdmFsdWUgaXMgbm90IHJlLXVzZWQNCj4+IGFzIGxvbmcgYXMgcGFj a2V0cyBmcm9tIGEgcHJldmlvdXMgSUNFIHNlc3Npb24gbWF5IHN0aWxsIGJlIHByZXNlbnQgaW4N Cj4+dGhlDQo+PiBuZXR3b3JrLiBCdXQsIHRoYXQgaXMgbm90IHJlYWxseSBzZWN1cml0eSByZWxh dGVkLCBidXQgbW9yZSB0byBtYWtlIHN1cmUNCj4+IElDRSB3b3Jrcy4NCj4+IA0KPj4gLS0tDQo+ PiANCj4+Pj4NCj4+Pj4+IChBbHNvIC0gdGhlIHBocmFzaW5nIGlzbid0IHRoYXQgZ3JlYXQgLSBo b3cgZG8gSSAiY29udGFpbiINCj4+Pj4+IHJhbmRvbW5lc3M/IEJ1dCB0aGF0J3MganVzdCBhIG5p dC4pDQo+Pj4+DQo+Pj4+IERvIHlvdSBoYXZlIGEgc3VnZ2VzdGlvbiBmb3IgYSBiZXR0ZXIgd29y ZD8NCj4+Pg0KPj4+IEkgdGhpbmsgd2hhdCB5b3Ugd2FudCBpcyB0byBzYXkgInVuZ3Vlc3NhYmxl LCB3aXRoIGF0DQo+Pj4gbGVhc3QgMTI4IGJpdHMgb2YgcmFuZG9tIG51bWJlciBnZW5lcmF0b3Ig b3V0cHV0IHVzZWQNCj4+PiB0byBnZW5lcmF0ZSBlYWNoIiBvciBzb21ldGhpbmcgbGlrZSB0aGF0 PyBJdCdzIGEgaGFyZA0KPj4+IG9uZSB0byBnZXQgcmlnaHQsIGJ1dCBldmVuIHdoYXQgeW91IGhh dmUgaXNuJ3QgdGhhdA0KPj4+IGJhZCAoSSBkaWQgc2F5IHRoaXMgd2FzIGEgbml0Oi0pDQo+PiAN Cj4+IFdoYXQgYWJvdXQ/DQo+PiANCj4+ICAgICAgIlVzZXJuYW1lIEZyYWdtZW50IGFuZCBQYXNz d29yZDogIFZhbHVlcyB1c2VkIHRvIHBlcmZvcm0NCj4+Y29ubmVjdGl2aXR5DQo+PiAgICAgICBj aGVja3MuIFRoZSB2YWx1ZXMgTVVTVCBiZSB1bmd1ZXNzYWJsZSwgd2l0aCBhdCBsZWFzdCAxMjgg Yml0cyBvZg0KPj4gcmFuZG9tIA0KPj4gICAgICAgbnVtYmVyIGdlbmVyYXRvciBvdXRwdXQgdXNl ZCB0byBnZW5lcmF0ZSB0aGUgcGFzc3dvcmQsIGFuZCBhdA0KPj5sZWFzdA0KPj4gMjQgDQo+PiAg ICAgICBiaXRzIG91dHB1dCB0byBnZW5lcmF0ZSB0aGUgdXNlcm5hbWUgZnJhZ21lbnQuIg0KPj4g DQo+PiANCj4+IFRoYW5rcyEgOikNCj4+IA0KPj4gUmVnYXJkcywNCj4+IA0KPj4gQ2hyaXN0ZXIN Cj4+IA0KPj4gDQo+Pj4+DQo+Pj4+ID09PT09PT09PT09PT09PT09PT09PT09PQ0KPj4+Pg0KPj4+ PiBOaXRzOg0KPj4+Pg0KPj4+Pj4gSSB0b29rIGEgbG9vayBhdCB0aGUgZGlmZiBbNF0gYmV0d2Vl biB0aGlzIGFuZCA1MjQ1LCBidXQgdGhhdA0KPj4+Pj4gd2Fzbid0IHJlYWxseSB0aGF0IHVzZWZ1 bCwgc28gdGhpcyByZXZpZXcgaXMgYmFzZWQgb24gYSByZWFkIG9mIHRoZQ0KPj4+Pj4gZHJhZnQg d2l0aG91dCBjb21wYXJpbmcgaXQgdG8gNTI0NS4gQXBvbG9naWVzIGlmIHRoYXQgY2F1c2VzIG1l IHRvDQo+Pj4+PiBjb21tZW50IG9uIHRleHQgdGhhdCdzIHVuY2hhbmdlZCAtIGluIHN1Y2ggY2Fz ZXMsIEkgdGhpbmsgaXQncyBmaW5lDQo+Pj4+PiB0byBub3QgaGVlZCB0aG9zZSBwYXJ0aWN1bGFy IGNvbW1lbnRzLg0KPj4+Pj4NCj4+Pj4+IFs0XQ0KPj4+Pj4NCj4+Pj4+IA0KPj4+Pj5odHRwczov L3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMT1yZmM1MjQ1JnVybDI9ZHJhZnQtaWV0Zi1pY2Ut cmZjNTI0DQo+Pj4+PjViDQo+Pj4+PiBpcy0xNi50eHQNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+ PiAtIDIuMTogV2h5ICJvbmx5IFVEUCBzcGVjaWZpZWQgaGVyZSI/IERvZXMgdGhhdCBpbmNsdWRl IFFVSUMgd2hpY2ggaXMNCj4+Pj4+IFVEUC1iYXNlZCwgYnV0IG5vdCBVRFA/IEkgYXNzdW1lIHNv Lg0KPj4+Pg0KPj4+PiBUaGVyZSBpcyBhIHNlcGFyYXRlIHNwZWNpZmljYXRpb24sIFJGQyA2NTQ0 LCBmb3IgVENQIGJhc2VkDQo+Pj4+IGNhbmRpZGF0ZXMuDQo+Pj4+DQo+Pj4+IFJlZ2FyZGluZyBR VUlDLCBJIGRvbid0IGtub3cuIFFVSUMgd2Fzbid0IGRpc2N1c3NlZCBkdXJpbmcgdGhlIHdvcmss DQo+Pj4+IGJ1dCBob3cvaWYgdGhlIHByb2NlZHVyZXMgYWxzbyBhcHBseSB0byBRVUlDIHdpdGhv dXQgYW55DQo+Pj4+IG1vZGlmaWNhdGlvbnMgZXRjIEkgZG9uJ3Qga25vdy4NCj4+Pj4NCj4+Pj4+ IC0gMi4zOiBob3cgdGhlIGNvbnRyb2xsaW5nL2NvbnRyb2xsZWQgc3R1ZmYgd29ya3MgaXNuJ3Qg Y2xlYXIgZnJvbQ0KPj4+Pj4gdGhpcywgbm9yIGV2ZW4gKGFzIEkgd2FzIHJlYWRpbmcgaXQpIGlu IHNlY3Rpb24gNy4zLjEuMSAtIEkgd2Fzbid0DQo+Pj4+PiBjbGVhciBob3cgdGhlIHRpZS1icmVh a2VyIHZhbHVlIGlzIGluaXRpYWxpc2VkIHVudGlsIEkgZ290IHRvDQo+Pj4+PiAxNi4xLiBJbiBh bnkgY2FzZSBJIHRoaW5rIGEgYml0IG1vcmUgZXhwbGFuYXRvcnkgdGV4dCBpbiAyLjMgbWlnaHQN Cj4+Pj4+IGJlIGdvb2QuIChCdXQgaWYgaW1wbGVtZW50ZXJzIGhhdmVuJ3QgaGFkIGEgcHJvYmxl bSB3aXRoIHRoaXMsDQo+Pj4+PiBtYXliZSBpdCdzIGp1c3QgbWUuKQ0KPj4+Pg0KPj4+PiBJbiBn ZW5lcmFsLCBvbmUgb2YgdGhlIHRhc2tzIG9mIHRoZSBiaXMgd29yayB3YXMgdG8gKnNpbXBsaWZ5 Kg0KPj4+PiBzZWN0aW9uIDIsIGJlY2F1c2UgdGhlIHByZXZpb3VzIHZlcnNpb24gd2FzIHRvbyBk ZXRhaWxlZCBmb3INCj4+Pj4gbm9uLWltcGxlbWVudGVycyB3aG8ganVzdCB3YW50IHRvIGZpZ3Vy ZSBvdXQgd2hhdCBJQ0UgaXMgYWxsIGFib3V0DQo+Pj4+IChpbiBvcmRlciB0byAgYWN0dWFsbHkg aW1wbGVtZW50IElDRSwgcmVhZGluZyBzZWN0aW9uIDIgaXMgb2J2aW91c2x5DQo+Pj4+IG5vdCBl bm91Z2gpLiBGb3IgdGhhdCByZWFzb24sIG15IG9waW5pb24gd2FzIHRoYXQgc2VjdGlvbiAyIGRv ZXNuJ3QNCj4+Pj4gcmVhbGx5IG5lZWQgdG8gdGFsayBhYm91dCByb2xlIGNvbmZsaWN0cyBhbmQg dGllLWJyZWFrZXIgdmFsdWVzLCBhcw0KPj4+PiBpdCdzIG5vdCBlc3NlbnRpYWwgZm9yIGEgaGln aC1sZXZlbCBkZXNjcmlwdGlvbiBvZiBJQ0UuDQo+Pj4+DQo+Pj4+IC0tLQ0KPj4+Pg0KPj4+Pj4g LSA1LjI6ICJUaGUgcHJvY2VkdXJlcyBpbiB0aGlzIHNlY3Rpb24gaXMgY29tbW9uIGFjcm9zcyB0 aGUNCj4+Pj4+IGluaXRpYXRpbmcgYW5kIHJlc3BvbmRpbmcgYWdlbnRzLiIgcy9pcy9hcmUvIEkg Z3Vlc3M/DQo+Pj4+DQo+Pj4+IFllcy4gSSB3aWxsIGZpeCBhcyBzdWdnZXN0ZWQuDQo+Pj4+DQo+ Pj4+IC0tLQ0KPj4+Pg0KPj4+Pj4gLSA2LjEuMTogV2hhdCBpcyAiM1BDQyI/IFRoYXQgbm90ZSBj b3VsZCBtYXliZSBhbHNvIGRvIHdpdGggYQ0KPj4+Pj4gcmVmZXJlbmNlLCBhcyBJIGF0IGxlYXN0 IGRvbid0IGdldCB3aGF0IHlvdSdyZSB0cnlpbmcgdG8gdGVsbCBtZS4NCj4+Pj4+IEFoIC0gaXQn cyAzcmQgcGFydHkgY2FsbCBjb250cm9sIChtZW50aW9uZWQgaW4gNy4zLjEuMSkuDQo+Pj4+DQo+ Pj4+IEkgY2FuIHVzZSAiM1BDQyAoM3JkIFBhcnR5IENhbGwgQ29udHJvbCkiIGluIHNlY3Rpb24g Ni4xLjEuDQo+Pj4+DQo+Pj4+IEFzIHRoZSBzcGVjIGlzIHByb3RvY29sIGluZGVwZW5kZW50LCBJ IGRvbid0IHRoaW5rIHRoZXJlIGFyZSBhbnkNCj4+Pj4gcmVmZXJlbmNlcyB0aGF0IGNhbiBiZSBh ZGRlZC4NCj4+Pj4NCj4+Pj4gLS0tDQo+Pj4+DQo+Pj4+PiAtIDE2LjE6IEZvciBhIGdpdmVuIElD RSBzZXNzaW9uLCBhcmUgdGhlIHJhbmRvbSBudW1iZXJzIGluIHRoZQ0KPj4+Pj4gSUNFLUNPTlRS T0xMRUQgYW5kIElDRS1DT05UUk9MTElORyBhdHRyaWJ1dGVzIHNlbnQgYnkgdGhlIHNhbWUNCj4+ Pj4+IGFnZW50IHN1cHBvc2VkIHRvIGhhdmUgdGhlIHNhbWUgdmFsdWU/IEkgd2Fzbid0IGNsZWFy LiBJZiB0aGV5IGFyZQ0KPj4+Pj4gdGhlIHNhbWUsIEkgdW5kZXJzdGFuZCBob3cgdGllLWJyZWFr aW5nIGhhcHBlbnMuIElmIHRoZXkgY2FuDQo+Pj4+PiBkaWZmZXIsIEknbSBub3Qgc3VyZS4gKEJ1 dCBJIGRpZG4ndCBnbyBiYWNrIGFuZCByZS1yZWFkIDcuMy4xLjEsIHNvDQo+Pj4+PiBpdCBtYXkg YmUgb2sgZWl0aGVyIHdheTotKQ0KPj4+Pg0KPj4+PiBJdCBpcyBjb3ZlcmVkIGluIHRoZSAybmQg cGFyYWdyYXBoIG9mIHNlY3Rpb24gNy4yLjUuMSwgd2hpY2ggc2F5cw0KPj4+PiB0aGF0IHRoZSBh Z2VudCBNQVkgY2hhbmdlIHRoZSB2YWx1ZSB3aGVuIGl0IHN3aXRjaGVzIHJvbGUuDQo+Pj4+DQo+ Pj4+PiBJbiBhbnkgY2FzZSBzYXlpbmcgInJlZmVycmVkIHRvIGFzIHRoZSB0aWUtYnJlYWtlciB2 YWx1ZSIgdHdpY2UNCj4+Pj4+IHNlZW1zIG9kZC4NCj4+Pj4NCj4+Pj4gSSdsbCByZW1vdmUgaXQg ZnJvbSB0aGUgSUNFLUNPTlRST0xMSU5HIGRlZmluaXRpb24uDQo+Pj4+DQo+Pj4+IC0tLQ0KPj4+ Pg0KPj4+Pj4gLSAxNi4xOiAobWVnYS1tZWdhLW5pdDotKSB0aGUgZmFjdCB0aGF0IHRpZS1icmVh a2VyIGlzIHNwbGl0IG92ZXINCj4+Pj4+IGEgbGluZS1icmVha2VyIGhlcmUgaXMgd2h5IEkgZGlk bid0IGZpbmQgdGhpcyB3aGVuIEkgd2FzIHJlYWRpbmcNCj4+Pj4+IDIuMy83LjMuMS4xIC0gbWF5 YmUgdHdlYWsgdGhlIHdvcmRzIHNvIGEgZ3JlcCB3aWxsIGZpbmQgaXQ/KQ0KPj4+Pg0KPj4+PiBH b29kIGNhdGNoLiBJJ2xsIGZpeCBpdC4NCj4+Pj4NCj4+Pj4gSXQgd291bGQgYmUgcmVhbGx5IGNv b2wgaWYgc2VhcmNoIGZ1bmN0aW9ucyBjb3VsZCBkaXNjYXJkIGxpbmUtYnJlYWtzDQo+Pj4+IHdo ZW4gc2VhcmNoaW5nIGZvciBzdHJpbmdzLg0KPj4+Pg0KPj4+PiAtLS0NCj4+Pj4NCj4+Pj4+IC0g MTc6ICJsb29raW5nIHRvIGRlcGxveSBJQ0UiIGlzIGEgYml0IGNvbmZ1c2luZyAtIGRvIHlvdSBt ZWFuDQo+Pj4+PiAibG9va2luZyB0byBiZSBuaWNlIHRvIElDRSI/IE15IGFzc3VtcHRpb24gaXMg dGhhdCBlbmRwb2ludHMgZGVwbG95DQo+Pj4+PiBJQ0UgYWdlbnRzIGJ1dCBuZXR3b3JrIG9wZXJh dG9ycyBkb24ndCwgdGhvdWdoIHRoZXkgbWlnaHQgZGVwbG95DQo+Pj4+PiBTVFVOL1RVUk4gc2Vy dmVycyBJIGd1ZXNzLiBCdXQgbWF5YmUgSSdtIHRoaW5raW5nIHRvbyBtdWNoIGFib3V0DQo+Pj4+ PiBXZWJSVEMgdGhlcmUuDQo+Pj4+DQo+Pj4+IFBlcmhhcHMgc29tZXRoaW5nIGxpa2U6DQo+Pj4+ DQo+Pj4+ICJUaGlzIHNlY3Rpb24gZGlzY3Vzc2VzIGlzc3VlcyByZWxldmFudCB0byBvcGVyYXRv cnMgb3BlcmF0aW5nDQo+Pj4+IG5ldHdvcmtzIHdoZXJlIElDRSB3aWxsIGJlIHVzZWQgYnkgZW5k cG9pbnRzLiINCj4+Pj4NCj4+Pj4gLS0tDQo+Pj4+DQo+Pj4+PiAtIDE4OiBJIHdvbmRlcmVkIGlm IHRoaXMgaXMgc3RpbGwgbmVlZGVkLCBnaXZlbiB0aGF0IDUyNDUgYWxyZWFkeQ0KPj4+Pj4gc2Fp ZCBpdCAoSSBkaWRuJ3QgY2hlY2sgaWYgdGhlIHRleHQgaGFzIGJlZW4gdXBkYXRlZCkuIFNheWlu ZyB0aGlzDQo+Pj4+PiBvbmNlIHdvdWxkIHNlZW0gc3VmZmljaWVudCB0byBtZSBhbnl3YXkuIEkg Z3Vlc3MgbGVhdmluZyBpdCBpbiBpcw0KPj4+Pj4gdGhlIGVhc2llciBwYXRoLg0KPj4+Pg0KPj4+ PiBJJ2xsIGxlYXZlIGl0IDopDQo+Pj4+DQo+Pj4+IC0tLQ0KPj4+Pg0KPj4+Pj4gLSAxOTogcy9E TlMtU0VDL0ROU1NFQy8gd291bGQgYmUgbW9yZSBjb21tb24NCj4+Pj4NCj4+Pj4gSSB3aWxsIGZp eCBhcyBzdWdnZXN0ZWQuDQo+Pj4+DQo+Pj4+IC0tLQ0KPj4+Pg0KPj4+Pj4gLSAxOS40LjE6IDFz dCBzZW50ZW5jZSBpZiBtaXNzaW5nIGEgIlQiIC0gcy9oZS9UaGUvDQo+Pj4+DQo+Pj4+IEkgd2ls bCBmaXggYXMgc3VnZ2VzdGVkLg0KPj4+Pg0KPj4+PiAtLS0NCj4+Pj4NCj4+Pj4gUmVnYXJkcywN Cj4+Pj4NCj4+Pj4gQ2hyaXN0ZXINCj4+Pj4NCj4+Pg0KPj4+IC0tIA0KPj4+IFBHUCBrZXkgY2hh bmdlIHRpbWUgZm9yIG1lLg0KPj4+IE5ldy1JRCA3QjE3MkJFQTsgb2xkLUlEIDgwNUY4REEyIGV4 cGlyZXMgSmFuIDI0IDIwMTguDQo+Pj4gTmV3V2l0aE9sZCBzaWdzIGluIGtleXNlcnZlcnMuDQo+ Pj4gU29ycnkgaWYgdGhhdCBtdWNrcyBzb21ldGhpbmcgdXA7LSkNCj4+IA0KPj4gDQo+DQo+LS0g DQo+UEdQIGtleSBjaGFuZ2UgdGltZSBmb3IgbWUuDQo+TmV3LUlEIDdCMTcyQkVBOyBvbGQtSUQg ODA1RjhEQTIgZXhwaXJlcyBKYW4gMjQgMjAxOC4NCj5OZXdXaXRoT2xkIHNpZ3MgaW4ga2V5c2Vy dmVycy4NCj5Tb3JyeSBpZiB0aGF0IG11Y2tzIHNvbWV0aGluZyB1cDstKQ0KDQo= From nobody Wed Jan 31 16:22:13 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C01C12EBCE; Wed, 31 Jan 2018 16:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piXWRDZ5Aosz; Wed, 31 Jan 2018 16:22:08 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B175B12708C; Wed, 31 Jan 2018 16:22:08 -0800 (PST) Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w110M7Cm011382 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 31 Jan 2018 18:22:08 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_2AAF1A78-96B8-401F-9B3C-E52B606DB553"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 31 Jan 2018 18:22:06 -0600 In-Reply-To: Cc: "ice@ietf.org" To: "draft-ietf-ice-rfc5245bis.all@ietf.org" , drat-ietf-ice-trickle.all@ietf.org References: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Ice] ice-options in draft-ietf-ice-rfc5245bis and draft-ietf-ice-trickle X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 00:22:10 -0000 --Apple-Mail=_2AAF1A78-96B8-401F-9B3C-E52B606DB553 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi I just noticed something in my AD review of ice-trickle that I think = also bears on 5245bis. Both documents make normative statements about = the use of the ice-options attribute. (Section 13 in 5245bis and section = 2 in ice-trickle). Given the loosening of the coupling to SDP since = RFC5245, does this still make sense? Thanks! Ben. --Apple-Mail=_2AAF1A78-96B8-401F-9B3C-E52B606DB553 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpyXa4ACgkQgFZKbJXz 1A3yhg/7BoCX8LcQDgR8y7qiSMmzvgWBIJ/gjYDUth2M0d3unDw8efTsHaBlkBBO lHb1Qafv6VDhZEI+n3nv6lsoC2A9bwN8L3NnZMKLShf6RSV3dt4NfCEp5uiQZtVS wm2C4LgbjomDGRN5byq8qQLBoflPuuzA6Ifa2zItncV2+Mfyikkb5L0rP9tKXz8D HkINacBIg211ENtAXHfO49ORX+qBxvzYH6JjtTXq/idlpd1jFzcxZ6WhizY9sWBJ sH+zEJWBfC7yCpYv0/dONr1sI2iS8cuoOPMfRxc8ZNuidIyF9O0V0NBfKpU4rI1/ jN0MctbGQxTZZrrt/7axWcCsfk8Do+/LZq2mJ3JpccMfOSWEIQLDz28TJeC7cENL cSOy0dEGyIJvgMLVBUeev4Vi5K+qLBEGm9X3dEQSjgjXCzkZgVjWZs4xOU7832BS rcfoDzONOq4r3f4ae5MugG3uyhYG8sQXda+nWN1KjH8UIxfCoBOXjwltiT8526up VYTP0pjy1l8dwpzcg2lA2ioB+GJmbW+tlIVFptxLwM7YE9L1ShzI46UOBp4/ZslC XTyxEYlq4KvYjKiEMDnry/kf7ugu8Oz55gqc4mzD6Q3RnhOBL3aFblJBdxkwLIJO DjoU/p/H09ibcezhB1oUACXaOtk+zqbWUO+zUAF9sG+RzOAYe78= =5cIP -----END PGP SIGNATURE----- --Apple-Mail=_2AAF1A78-96B8-401F-9B3C-E52B606DB553-- From nobody Wed Jan 31 16:28:26 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6717B12FABE; Wed, 31 Jan 2018 16:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPnmlBp7CFqX; Wed, 31 Jan 2018 16:28:23 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C465A130FDA; Wed, 31 Jan 2018 16:28:19 -0800 (PST) Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w110SI3n012124 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 31 Jan 2018 18:28:19 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F070CF71-7CB9-4F87-9001-5F9CF956027C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 31 Jan 2018 18:28:17 -0600 In-Reply-To: Cc: "ice@ietf.org" To: "draft-ietf-ice-rfc5245bis.all@ietf.org" , draft-ietf-ice-trickle.all@ietf.org References: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Ice] ice-options in draft-ietf-ice-rfc5245bis and draft-ietf-ice-trickle X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 00:28:25 -0000 --Apple-Mail=_F070CF71-7CB9-4F87-9001-5F9CF956027C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 (Oops, resending. I mistyped the alias for draft-ietf-ice-trickle.all as = =E2=80=9Cdrat-ietf=E2=80=A6=E2=80=9D. I have comment about hiddin = meanings there :-) ) Hi I just noticed something in my AD review of ice-trickle that I think = also bears on 5245bis. Both documents make normative statements about = the use of the ice-options attribute. (Section 13 in 5245bis and section = 2 in ice-trickle). Given the loosening of the coupling to SDP since = RFC5245, does this still make sense? Thanks! Ben. --Apple-Mail=_F070CF71-7CB9-4F87-9001-5F9CF956027C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpyXyEACgkQgFZKbJXz 1A0YVQ//SS2hASOpmusTtuu3A76fsdmVZmXqnmsYG+uBtXF9pze9Tk3fijEqrxGF iK2efIc6OL80QOF4KwkckNK5FWM/1qbBFeWleLXtwyjx7h0gTbkf1nQY/X22W7vo XFYGUyBJ6f0Zue/YlBYYCKU+HKO3mQKV5yhAZUDlwq6+qsvk5J3dnw5Ev3f4iTMi qprFc3gKl3rzKjpmb9lrUqY22f0Yn/UZPWtZO7xs4Z3TjQPnAs36R9wf/OkbAOFe NJCXJ5hmyUVkXVJJBIKEMygPH9mZZYaRpsqrrCOj9oCgip8ATf3zIBUqSlLTGlyK pB/wpzAAO/s+gifv6Ir/DOwbudnqzix8ILdy2eDFHV3RdTbQn2efRnQf61PQ12RN YJogyZHKb/U+5bBjmUe0+tQ9YTYd1CqIEdASWlhmJ0wZwPY65Nbxq2ZnO4wuXetz E3POrSKFy3A16fsvEhl1zvobzzRiEDFruz6gLkATS3QHZl4v77bexVEUHEYE5t0C 9EsXhm6kWK35yYiCPjnkG7COTsirAUGplh47UstvwFWdf8Jhu8NJYCHVbzXCgjW/ lpqx40tYTTAO6KBG4auGfOpeK3dlz4fAOpSWBiZTmzvo2oSHqUsvdeNCfPZ4YMTm vmEs2DpmhHAq+Eq9xHN7ZS5l448QIU7IFlg8LlgcmYuURlFlntQ= =B/GS -----END PGP SIGNATURE----- --Apple-Mail=_F070CF71-7CB9-4F87-9001-5F9CF956027C-- From nobody Wed Jan 31 16:53:44 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3284B12FEEB; Wed, 31 Jan 2018 16:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGrbjBF9bEFP; Wed, 31 Jan 2018 16:53:41 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05DE112FB60; Wed, 31 Jan 2018 16:53:40 -0800 (PST) Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w110rdLZ015163 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 31 Jan 2018 18:53:40 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_597AD348-92D9-4962-8787-3FA155D5E265"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 31 Jan 2018 18:53:22 -0600 In-Reply-To: Cc: "ice@ietf.org" To: "draft-ietf-ice-rfc5245bis.all@ietf.org" , draft-ietf-ice-trickle.all@ietf.org References: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ice] ice-options in draft-ietf-ice-rfc5245bis and draft-ietf-ice-trickle X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 00:53:43 -0000 --Apple-Mail=_597AD348-92D9-4962-8787-3FA155D5E265 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 31, 2018, at 6:28 PM, Ben Campbell wrote: >=20 > (Oops, resending. I mistyped the alias for draft-ietf-ice-trickle.all = as =E2=80=9Cdrat-ietf=E2=80=A6=E2=80=9D. I have comment about hiddin = meanings there :-) ) >=20 > Hi >=20 > I just noticed something in my AD review of ice-trickle that I think = also bears on 5245bis. Both documents make normative statements about = the use of the ice-options attribute. (Section 13 in 5245bis and section = 2 in ice-trickle). Given the loosening of the coupling to SDP since = RFC5245, does this still make sense? By =E2=80=9Csection 2 in ice-trickle=E2=80=9D, I meant section 3. >=20 > Thanks! >=20 > Ben. >=20 --Apple-Mail=_597AD348-92D9-4962-8787-3FA155D5E265 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpyZQIACgkQgFZKbJXz 1A30MQ/9GD22VnN7CRJMUNhqpzFTuBSkkXPHj8zGAjrfvRKQRgEmg7LMfxEieDNp g/4a5/KRpZBWF7ZFXK00SMzOE+4qgkHg8D94YDEdVOyjpnGSzDt3m6t2Q1Ye0ZP3 1eRBTcQRptta0E3VgwuetpsXceWOt8tsPIJ+TAaD8CbkT+pAyBQ0k5otxOrw34YO mYdyJPZoLJ1kKXeSHxJdKWs/+V9sFYtgfnA8UBsHaz/UC5EtGRCBifq9cH/tsKu7 bugs4v1jzoZykWlCMsZMMmkskoK7WadMAdSIrSp3GrUxyHeqiBFbtPrTJbJMZeIJ LwmP0vqwzI20129q6w+clcMDx6/taDOxCM0nPNFYYXIxnK2If53RlavITPiz4LGD /EFZXn5r64ua4lwk6nd9soDXq4l+/CTROCQVNgtQ4D1x0AuQ10nlZuBI947lX1Go rE630jPZmc1yPyqRQ1jICSVKG90eDEKMED40a+OImfaZ8x2oTldIPvaqsCwJPeJW reLVpP6E70TiNzv7GDxamTAR0AzD/UwSXxgky3hodS8a6lBIAFZESdP06LW9pOrp a2IAwW4G+HLfBBmizdQsrk1Maf/8RNjYm1QM5gknY2WBGMkiV5m8T+W+IqQIIAWO u6ZIeZwn6L7uB1d/f8S7CibNX9GExYZh2oM4Se5FPyXdkHOQV78= =mAuR -----END PGP SIGNATURE----- --Apple-Mail=_597AD348-92D9-4962-8787-3FA155D5E265-- From nobody Wed Jan 31 18:25:56 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1276212EC1C; Wed, 31 Jan 2018 18:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=BovA7kGi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=A1WZe8gL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWJM5IiEn3Tk; Wed, 31 Jan 2018 18:25:53 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F109131772; Wed, 31 Jan 2018 18:25:28 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id ADF7820F35; Wed, 31 Jan 2018 21:25:27 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 31 Jan 2018 21:25:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=12FN7OfoJRLZT43XxPminhR7ZQ2BrlsaCYzE5XtgF34=; b=BovA7kGi 34c+Bg1o0r57yGSSftrJA5cbFcqZB2uf9mowmpaZM3/BuJMqeylxfgiqmidZ83BR IERmdu2Sf4MQRq/Ck4+VaYkN1xUe7lt0ZR6Yly4JXGu3/VO+PRd/YNBrgULqRUcr UA2njcMO0gEJSrLHq/ZB75Hx6EyLgFemCyxHgMcLK5EpVVBKtbKDxT9IhQn6JCjP B7Dkdwdm6YJPMDxcmVMiJZktv9ms/uqa049svWU1njBAHWua1azuQijSpoqNtSSx k0IP5i4gzhu53cMi8HeVRrVxyglrDCVhPu34YWmTwXx2aV5JwGVGi1RDJrUiGp/y bXwEuWAxA6+AeQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=12FN7OfoJRLZT43XxPminhR7ZQ2Br lsaCYzE5XtgF34=; b=A1WZe8gLOWpLlm3Jt27zZ+gnCS5g0hu4xpxfv4Rq7h2PC EmqLxjSYQugTocp9RNHT5XGJNz8pBcZYiwVgVQ1nPAdzx9AUkjUbuyiipZRMSRRI U06t+G2j8YJxOZOvtq6x90GmpZ/wsXZY+pe6zCl3Q4qUhN+RCWAG2uuFvv7RH6KT v5R7PPXJ23EYE1+GrJPngYdlUdiLmMjWiM6+7JBhnbQeB8mTm+4rLXOv0+nClrJM LBEwOP+mHE9zMIheVuna30bUDP2zzKA6HD+ueur6/+yLs2tqC2c6tnH6lxu8FHII J9QS/2N3Zsy8VdvDGLBfHN7kbgwBhWPwu2Q8yNX0A== X-ME-Sender: Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id D72AC7E664; Wed, 31 Jan 2018 21:25:26 -0500 (EST) To: Ben Campbell , "draft-ietf-ice-rfc5245bis.all@ietf.org" , draft-ietf-ice-trickle.all@ietf.org Cc: "ice@ietf.org" References: From: Peter Saint-Andre Message-ID: <85ba14f8-7062-6df1-343d-9431f4a57263@stpeter.im> Date: Wed, 31 Jan 2018 19:25:25 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9yWTUYZfrkxXqNXcU45kfqKsS4F55IBoV" Archived-At: Subject: Re: [Ice] ice-options in draft-ietf-ice-rfc5245bis and draft-ietf-ice-trickle X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 02:25:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9yWTUYZfrkxXqNXcU45kfqKsS4F55IBoV Content-Type: multipart/mixed; boundary="Tlz1cTTCXzs7ghvNtryK2fTQaCkHZqigK"; protected-headers="v1" From: Peter Saint-Andre To: Ben Campbell , "draft-ietf-ice-rfc5245bis.all@ietf.org" , draft-ietf-ice-trickle.all@ietf.org Cc: "ice@ietf.org" Message-ID: <85ba14f8-7062-6df1-343d-9431f4a57263@stpeter.im> Subject: Re: [Ice] ice-options in draft-ietf-ice-rfc5245bis and draft-ietf-ice-trickle References: In-Reply-To: --Tlz1cTTCXzs7ghvNtryK2fTQaCkHZqigK Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Ben, thanks for the careful review. Comments inline. On 1/31/18 5:28 PM, Ben Campbell wrote: > (Oops, resending. I mistyped the alias for draft-ietf-ice-trickle.all a= s =E2=80=9Cdrat-ietf=E2=80=A6=E2=80=9D. I have comment about hiddin meani= ngs there :-) ) >=20 > Hi >=20 > I just noticed something in my AD review of ice-trickle that I think al= so bears on 5245bis. Both documents make normative statements about the u= se of the ice-options attribute. (Section 13 in 5245bis and section 2 in = ice-trickle). Given the loosening of the coupling to SDP since RFC5245, d= oes this still make sense? Section 9 of 5245bis says: This section defines a new ICE option, 'ice2'. The ICE option indicates that the ICE agent that includes it (in an ice-options attribute) is compliant to this specification. For example, the ICE agent will not use the aggressive nomination procedure defined in [RFC5245]. An ICE agent compliant to this specification MUST inform the peer about the compliance using the 'ice2' ICE option. NOTE: The encoding of the 'ice2' ICE option, and the message(s) used to carry it to the peer, are protocol specific. The encoding for the Session Description Protocol (SDP) [RFC4566] is defined in [I-D.ietf-mmusic-ice-sip-sdp]. The intent is clear, but the text could be cleaned up a bit to enforce the separation between the ICE protocol and the SDP encoding. I suggest the following for the first paragraph: This section defines a new ICE option, 'ice2'. The ICE option indicates that the ICE agent that includes it is compliant to this specification. For example, the ICE agent will not use the aggressive nomination procedure defined in [RFC5245]. We need to do something similar in the trickle spec: OLD Even if a signaling protocol does not include a capabilities discovery method, a user agent can provide an indication within the ICE description that it supports Trickle ICE using a token of "trickle" in the ice-options attribute. This token MUST be provided either at the session level or, if at the media stream level, for every media stream (an agent MUST NOT specify Trickle ICE support for some media streams but not others). NEW Even if a signaling protocol does not include a capabilities discovery method, a user agent can provide an indication within the ICE description that it supports Trickle ICE by communicating an ICE option of 'trickle'. This token MUST be provided either at the session level or, if at the media stream level, for every media stream (an agent MUST NOT specify Trickle ICE support for some media streams but not others). NOTE: The encoding of the 'trickle' ICE option, and the message(s) used to carry it to the peer, are protocol specific. The encoding for the Session Description Protocol (SDP) [RFC4566] is defined in [I-D.ietf-mmusic-trickle-ice-sip]. Would that address your concern? Peter --Tlz1cTTCXzs7ghvNtryK2fTQaCkHZqigK-- --9yWTUYZfrkxXqNXcU45kfqKsS4F55IBoV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAlpyepUACgkQ6gakkSvF ralHbw//VxRDlXpCobygxMD2FBJr99izuEujKJ4rYmEHXXp7EIZXDFO5hpbcK7QT /gJMjDOkrz0E59ZNNm96I0uQf7g9IYOqA/IMRNnojdyKH/caUuRSzkVc+23VL60V wp3xbT9ndyxc9rF81LNFXIJvBk3IZiERXDNXDAcahq5jeoD/L+ZVfXxncRDNomzJ ppILpv5cIx9YNf/QLz9X68aPhsruboyZsVXKGGtT9wf+SXYrF8LDgYqt6d1I1Ux+ lMC397EGfHg0+8Py/r2VJYZXA5szc6fefT0Q+jJwH+Ugj0acmuF6JHd7jWg8g7FP 6ZSaP68cXTzRVgE1vvBAAXleBaipv+55kexapKIewBAVMX53mhcQdLVeZIOR3riu DYNZWzfHBHgFvi7hb/pK2Z/aEelgDhX1E0udA90AmeWpQ1JMX7/8zS0Q93DwMadK zSGqWQ25Z2HOJhGZZU1uj5NwhpAC6J9ynH8/ijD74JNG7n5R3KVo2yOPd03e4JDe WXSpm3mz3u71EtIUy/OSEr0tYrvwRb++gpc6ySqCT+C34DyOKXCSsOtHYUImAqdA HXksubjXGoJIh1AI4WxuMxBiWcIVQAw31MEh8kzFlABCZpMImXSQWVUy5IWtesVI OfGxc4Ka3Hm1ZvkmBVzSzIc9xEvPbKOcrZfaGIUn8WQ3WVGWbTM= =cOzV -----END PGP SIGNATURE----- --9yWTUYZfrkxXqNXcU45kfqKsS4F55IBoV-- From nobody Wed Jan 31 18:47:00 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDC2127201; Wed, 31 Jan 2018 18:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjIKNC6T6KWK; Wed, 31 Jan 2018 18:46:55 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF3012DA49; Wed, 31 Jan 2018 18:46:54 -0800 (PST) Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w112kr84028516 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 31 Jan 2018 20:46:54 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_10CF2A15-5822-497C-9988-EE151D6AD735"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 31 Jan 2018 20:46:51 -0600 In-Reply-To: <85ba14f8-7062-6df1-343d-9431f4a57263@stpeter.im> Cc: "draft-ietf-ice-rfc5245bis.all@ietf.org" , draft-ietf-ice-trickle.all@ietf.org, "ice@ietf.org" To: Peter Saint-Andre References: <85ba14f8-7062-6df1-343d-9431f4a57263@stpeter.im> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ice] ice-options in draft-ietf-ice-rfc5245bis and draft-ietf-ice-trickle X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 02:46:59 -0000 --Apple-Mail=_10CF2A15-5822-497C-9988-EE151D6AD735 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 31, 2018, at 8:25 PM, Peter Saint-Andre = wrote: >=20 > Hi Ben, thanks for the careful review. Comments inline. For the record, this was not my complete review of ice-trickle :-) I sent the issue separately since it also impacts 5245bis, which is past = IETF LC. >=20 > On 1/31/18 5:28 PM, Ben Campbell wrote: >> (Oops, resending. I mistyped the alias for draft-ietf-ice-trickle.all = as =E2=80=9Cdrat-ietf=E2=80=A6=E2=80=9D. I have comment about hiddin = meanings there :-) ) >>=20 >> Hi >>=20 >> I just noticed something in my AD review of ice-trickle that I think = also bears on 5245bis. Both documents make normative statements about = the use of the ice-options attribute. (Section 13 in 5245bis and section = 2 in ice-trickle). Given the loosening of the coupling to SDP since = RFC5245, does this still make sense? >=20 > Section 9 of 5245bis says: >=20 > This section defines a new ICE option, 'ice2'. The ICE option > indicates that the ICE agent that includes it (in an ice-options > attribute) is compliant to this specification. For example, the ICE > agent will not use the aggressive nomination procedure defined in > [RFC5245]. >=20 > An ICE agent compliant to this specification MUST inform the peer > about the compliance using the 'ice2' ICE option. >=20 > NOTE: The encoding of the 'ice2' ICE option, and the message(s) used > to carry it to the peer, are protocol specific. The encoding for = the > Session Description Protocol (SDP) [RFC4566] is defined in > [I-D.ietf-mmusic-ice-sip-sdp]. >=20 > The intent is clear, but the text could be cleaned up a bit to enforce > the separation between the ICE protocol and the SDP encoding. I = suggest > the following for the first paragraph: >=20 > This section defines a new ICE option, 'ice2'. The ICE option > indicates that the ICE agent that includes it is compliant to this > specification. For example, the ICE agent will not use the > aggressive nomination procedure defined in [RFC5245]. I think you are looking at an old version. That section (now section 10 = in version 16) does not mention ice-options. The text that triggered my = concern is in section 13: " First, ICE provides the ice-options attribute. Each extension or change to ICE is associated with a token. When an agent supporting such an extension or change triggers candidate exchange, it MUST include the token for that extension in this attribute. This allows each side to know what the other side is doing. This attribute MUST NOT be present if the agent doesn't support any ICE extensions or changes.=E2=80=9D It=E2=80=99s pretty clear that=E2=80=99s just some old (probably = pre-bis) text. But it does need to be fixed prior to publication. >=20 > We need to do something similar in the trickle spec: >=20 > OLD > Even if a signaling protocol does not include a capabilities > discovery method, a user agent can provide an indication within the > ICE description that it supports Trickle ICE using a token of > "trickle" in the ice-options attribute. This token MUST be provided > either at the session level or, if at the media stream level, for > every media stream (an agent MUST NOT specify Trickle ICE support = for > some media streams but not others). >=20 > NEW > Even if a signaling protocol does not include a capabilities > discovery method, a user agent can provide an indication within the > ICE description that it supports Trickle ICE by communicating an ICE > option of 'trickle'. This token MUST be provided either at the > session level or, if at the media stream level, for every media > stream (an agent MUST NOT specify Trickle ICE support for some media > streams but not others). >=20 > NOTE: The encoding of the 'trickle' ICE option, and the message(s) > used to carry it to the peer, are protocol specific. The encoding > for the Session Description Protocol (SDP) [RFC4566] is defined in > [I-D.ietf-mmusic-trickle-ice-sip]. >=20 > Would that address your concern? I think that would address my concern for ice-trickle. Thanks! Ben. --Apple-Mail=_10CF2A15-5822-497C-9988-EE151D6AD735 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpyf5sACgkQgFZKbJXz 1A3eTxAAii1D8uD9EJwTTINMUVJCISgiD7k6sLJlSZ6dHeM0Dk0s4Sh6Ff3atB/X wwA0wO/RkN33/caLuh8kT47/JP/dQEGtuqOQacwJvIrIrj4nFZjF3+5yz4Q5svhR af7Q9OCeuv4cc8em1IfM+t0N4p4+N88JWTHmtyLIK+m0lS7w0Lp3qIzrEinUSR3A YtInyjs37GGTx3+tToYgUYs0GFno/8TDnbpJ3Xt2uVwhTCKtg+Dv/eNsQv+r4KUo lxD+HdWkj8T1+9sjOfpV8G9pnKrKtJlkWSWmRGvDZ3yWDcyRCEkwudCNQjFD+a9l GU1NvZcmwX4NpBv7GwlZvByekwR+ynTKeU7AprCu6a0VjCP6Ind1eGzuYOezlmTY OJ9sBiR/XJgI7JhAfFXNzy5O+SxaNmpi62ddQKQbhlfkXsrCxtyxm7G3Qs/DuGQk dYZCbIn/0sj4dUqv7WWcuDHy3L4g0xFNk+MGr1Ny3+od/TyUfpAVF7OGhrhwwXo0 Jipxck+P5XrWOzT8ulmHzY0gnq4n4sRoVoNYOkPf0Ka5qWFDf+z6b7KKLwiN4lgf YnJ85pFqITZNtG8EjkIpk91PcS1jLsnhM5X9blbAVorXcsf/KGAvdtTdW8JP6Xyw MdyWK2BOq15tQrX4NP+J6+fewiubo59M0KcuTrk/jUe1RhMtya0= =jzWB -----END PGP SIGNATURE----- --Apple-Mail=_10CF2A15-5822-497C-9988-EE151D6AD735-- From nobody Wed Jan 31 18:52:29 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A3B131797; Wed, 31 Jan 2018 18:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=QG/xEtWs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QZcTztMw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UO-gHp5yW6l; Wed, 31 Jan 2018 18:52:23 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90F4127136; Wed, 31 Jan 2018 18:52:23 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E4AD320F30; Wed, 31 Jan 2018 21:52:22 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 31 Jan 2018 21:52:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=PnNmJoUcLoDWYaMtRw0MlmS7Dc598r1rjDYbqk/h8lY=; b=QG/xEtWs KDS+5wHi+AMVmThKKXuWSWqQdlSvn+6px+tXfgYP/Od5RO93jKZEKMkbCz391Hx9 78RuUZbfQ9NYm/0Y6I16KEghI35RswfElmsXL/KpINzTUXhqMQsooP3q8vkSn69l gfeeSLfkaWCTnWOU+IYusVFo2kkmoZLR1GClmqR29gN1rPJo0cquSEww0cdb4HVU e+qcW74ukmCYiwnR23GwlJeE9frBk1bHCV2StKMoU4j/+gbyqyh1bXXUNPZ8hqaS THGVXJbtIckzs6+bFQwUCwdqcMwHNxb/VsiYJ2tC5BMaLzSSSDCJ5Ql4HnWRFOOd 43EwhB7qq+vmlQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=PnNmJoUcLoDWYaMtRw0MlmS7Dc598 r1rjDYbqk/h8lY=; b=QZcTztMwogYPgleUCDdshp8wLFk+xAZj+GGKuULJX31Cb r71OWpaWU/4/+OtXDNIDrEV7GrQ0ETSgEWs17REKrns/4MLWJ/h5/fVHmbWTNrho Vuac3JLbUwmBwKahu33Z7pas3FjJMocy3IvbPi9t0eN9inM2UXFOSXEGbGAVcyJY l4uJ5jr5blyVh3EoewnOap/WGqpGNR7bMzOjCMEhv/pwDSRaVRngY6lKeyKZKqB0 PP3csCfJ6Gt98vom/ZNn7N1yloQovzUBMaDSqRXRwHbIhI0yUFkunu94ZqkWUSXl SJxUx1/jA3HywOSI+DQ3hImg+XCxgpabPDwD2dLgQ== X-ME-Sender: Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 0A41B7E1DE; Wed, 31 Jan 2018 21:52:21 -0500 (EST) To: Ben Campbell Cc: "draft-ietf-ice-rfc5245bis.all@ietf.org" , draft-ietf-ice-trickle.all@ietf.org, "ice@ietf.org" References: <85ba14f8-7062-6df1-343d-9431f4a57263@stpeter.im> From: Peter Saint-Andre Message-ID: Date: Wed, 31 Jan 2018 19:52:20 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="y2PSndXjZaFEoWyweXMCpGGeKW3AUi7hi" Archived-At: Subject: Re: [Ice] ice-options in draft-ietf-ice-rfc5245bis and draft-ietf-ice-trickle X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 02:52:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --y2PSndXjZaFEoWyweXMCpGGeKW3AUi7hi Content-Type: multipart/mixed; boundary="194mMdJ7WOJy5fIoOrav7RWWCQk0FaD0f"; protected-headers="v1" From: Peter Saint-Andre To: Ben Campbell Cc: "draft-ietf-ice-rfc5245bis.all@ietf.org" , draft-ietf-ice-trickle.all@ietf.org, "ice@ietf.org" Message-ID: Subject: Re: [Ice] ice-options in draft-ietf-ice-rfc5245bis and draft-ietf-ice-trickle References: <85ba14f8-7062-6df1-343d-9431f4a57263@stpeter.im> In-Reply-To: --194mMdJ7WOJy5fIoOrav7RWWCQk0FaD0f Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 1/31/18 7:46 PM, Ben Campbell wrote: >=20 >=20 >> On Jan 31, 2018, at 8:25 PM, Peter Saint-Andre wr= ote: >> >> Hi Ben, thanks for the careful review. Comments inline. >=20 > For the record, this was not my complete review of ice-trickle :-) Duly noted! :-) > I sent the issue separately since it also impacts 5245bis, which is pas= t IETF LC. >=20 >> >> On 1/31/18 5:28 PM, Ben Campbell wrote: >>> (Oops, resending. I mistyped the alias for draft-ietf-ice-trickle.all= as =E2=80=9Cdrat-ietf=E2=80=A6=E2=80=9D. I have comment about hiddin mea= nings there :-) ) >>> >>> Hi >>> >>> I just noticed something in my AD review of ice-trickle that I think = also bears on 5245bis. Both documents make normative statements about the= use of the ice-options attribute. (Section 13 in 5245bis and section 2 i= n ice-trickle). Given the loosening of the coupling to SDP since RFC5245,= does this still make sense? >> >> Section 9 of 5245bis says: >> >> This section defines a new ICE option, 'ice2'. The ICE option >> indicates that the ICE agent that includes it (in an ice-options >> attribute) is compliant to this specification. For example, the ICE= >> agent will not use the aggressive nomination procedure defined in >> [RFC5245]. >> >> An ICE agent compliant to this specification MUST inform the peer >> about the compliance using the 'ice2' ICE option. >> >> NOTE: The encoding of the 'ice2' ICE option, and the message(s) used= >> to carry it to the peer, are protocol specific. The encoding for th= e >> Session Description Protocol (SDP) [RFC4566] is defined in >> [I-D.ietf-mmusic-ice-sip-sdp]. >> >> The intent is clear, but the text could be cleaned up a bit to enforce= >> the separation between the ICE protocol and the SDP encoding. I sugges= t >> the following for the first paragraph: >> >> This section defines a new ICE option, 'ice2'. The ICE option >> indicates that the ICE agent that includes it is compliant to this >> specification. For example, the ICE agent will not use the >> aggressive nomination procedure defined in [RFC5245]. >=20 > I think you are looking at an old version.=20 Datatracker done me wrong. > That section (now section 10 in version 16) does not mention ice-option= s. The text that triggered my concern is in section 13: >=20 > " First, ICE provides the ice-options attribute. Each extension or > change to ICE is associated with a token. When an agent supporting > such an extension or change triggers candidate exchange, it MUST > include the token for that extension in this attribute. This allows= > each side to know what the other side is doing. This attribute MUST= > NOT be present if the agent doesn't support any ICE extensions or > changes.=E2=80=9D >=20 > It=E2=80=99s pretty clear that=E2=80=99s just some old (probably pre-bi= s) text. But it does need to be fixed prior to publication. Yep, I'll leave that to Christer. >> We need to do something similar in the trickle spec: >> >> OLD >> Even if a signaling protocol does not include a capabilities >> discovery method, a user agent can provide an indication within the >> ICE description that it supports Trickle ICE using a token of >> "trickle" in the ice-options attribute. This token MUST be provided= >> either at the session level or, if at the media stream level, for >> every media stream (an agent MUST NOT specify Trickle ICE support fo= r >> some media streams but not others). >> >> NEW >> Even if a signaling protocol does not include a capabilities >> discovery method, a user agent can provide an indication within the >> ICE description that it supports Trickle ICE by communicating an ICE= >> option of 'trickle'. This token MUST be provided either at the >> session level or, if at the media stream level, for every media >> stream (an agent MUST NOT specify Trickle ICE support for some media= >> streams but not others). >> >> NOTE: The encoding of the 'trickle' ICE option, and the message(s) >> used to carry it to the peer, are protocol specific. The encoding >> for the Session Description Protocol (SDP) [RFC4566] is defined in >> [I-D.ietf-mmusic-trickle-ice-sip]. >> >> Would that address your concern? >=20 > I think that would address my concern for ice-trickle. Excellent. Awaiting further feedback on that one... Peter --194mMdJ7WOJy5fIoOrav7RWWCQk0FaD0f-- --y2PSndXjZaFEoWyweXMCpGGeKW3AUi7hi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAlpygOQACgkQ6gakkSvF raknTA/+P90tvTO64H46zDvHhVWpVNpGeisyk+Snlh/ga0VHozJFSQ2WQBnWI1R2 yQkVGOsjAWjNCD0thf4LMCTbsmjbNJroGQ4GbMVSNmCDGYlGJ/kzHTJFToFjDAgC NCR9V5zDJ3jdueIxYZEwB61fjZO/RM6vuqQT94rjoeOL5IXWifWtzFJQLcNXYDYo KJ+IQqFkU2Sh6DKdCcdKNRUOtN1HBIdJO+z7/YKdu4ozYkYFOlyQF+20IsJYn+K/ wqBtj27V7dUtfQxMw+c53xrb0iWYBtTg11uF8WAdk+DWJQu4wM0cvOsgKMS4o9s7 yOvpRfGPe/bYq/CFQdj2OjcnKP1/8A5gMERSzaT0eAicjY4Ok12MvmSY4JA9ve5s wp2cfPJ/BuE2fhgThtllGesMr9g/hqJA/qL/IjZQuIrLObJCDEAic3JvC0pUZbBT H+agWh5ldoo7kAIfoe2QrTbMc2K6eEIDXuHF/ysjDZ5LzOieF1dvNbnOMorLbNV5 FZxECFPJCyVdp9X1a3G07XY0yXnwzXoGshnRJTBmr2DXIw7DOT3CUhgfTyg2wuC2 y95K+iAIkCiUe2NV/PpYs9lp1JyjJDGs9fpaeAPqYs1zKVrHnyQBVq4SGUfcQ8RE VtQS/fimiZZOeDzjDVmhOXx4o4UDedhpLOIn5R6XxzUYgAQcbaw= =uQhp -----END PGP SIGNATURE----- --y2PSndXjZaFEoWyweXMCpGGeKW3AUi7hi-- From nobody Wed Jan 31 20:47:08 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25541131795; Wed, 31 Jan 2018 20:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iDexwDfYrzI; Wed, 31 Jan 2018 20:47:04 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B42131501; Wed, 31 Jan 2018 20:47:04 -0800 (PST) Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w114l3D5042543 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 31 Jan 2018 22:47:03 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9C9B1A93-74E1-4239-A36B-7490671175C6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 31 Jan 2018 22:47:02 -0600 In-Reply-To: Cc: draft-ietf-ice-trickle.all@ietf.org, "ice@ietf.org" , Peter Saint-Andre To: "draft-ietf-ice-rfc5245bis.all@ietf.org" References: <85ba14f8-7062-6df1-343d-9431f4a57263@stpeter.im> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ice] ice-options in draft-ietf-ice-rfc5245bis and draft-ietf-ice-trickle X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 04:47:07 -0000 --Apple-Mail=_9C9B1A93-74E1-4239-A36B-7490671175C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for your quick response, Peter; this discussion was = helpful=E2=80=94partially by bringing up a separate but related question = (more for 5245bis than for ice-trickle): Section 13 of 5245bis talks about a series of tokens for = =E2=80=9Cice-options=E2=80=9D. But since the ice-options SDP attribute = in no longer defined in 5245bis, did we lose the text that says that the = ICE option needs to be able to carry multiple tags, whatever the = signaling protocol is? Am I missing text somewhere in 5245bis that says what to do if you get = some tags you understand and some you do not? (e.g. a 5245bis = implementation getting =E2=80=9Cice2 trickle=E2=80=9D.) I think I know = what we expect but am not sure where (or if) it is written down, = especially for non-SDP applications. (I=E2=80=99m sure I=E2=80=99m missing something obvious.) Thanks! Ben. > On Jan 31, 2018, at 8:52 PM, Peter Saint-Andre = wrote: >=20 > On 1/31/18 7:46 PM, Ben Campbell wrote: >>=20 >>=20 >>> On Jan 31, 2018, at 8:25 PM, Peter Saint-Andre = wrote: >>>=20 >>> Hi Ben, thanks for the careful review. Comments inline. >>=20 >> For the record, this was not my complete review of ice-trickle :-) >=20 > Duly noted! :-) >=20 >> I sent the issue separately since it also impacts 5245bis, which is = past IETF LC. >>=20 >>>=20 >>> On 1/31/18 5:28 PM, Ben Campbell wrote: >>>> (Oops, resending. I mistyped the alias for = draft-ietf-ice-trickle.all as =E2=80=9Cdrat-ietf=E2=80=A6=E2=80=9D. I = have comment about hiddin meanings there :-) ) >>>>=20 >>>> Hi >>>>=20 >>>> I just noticed something in my AD review of ice-trickle that I = think also bears on 5245bis. Both documents make normative statements = about the use of the ice-options attribute. (Section 13 in 5245bis and = section 2 in ice-trickle). Given the loosening of the coupling to SDP = since RFC5245, does this still make sense? >>>=20 >>> Section 9 of 5245bis says: >>>=20 >>> This section defines a new ICE option, 'ice2'. The ICE option >>> indicates that the ICE agent that includes it (in an ice-options >>> attribute) is compliant to this specification. For example, the = ICE >>> agent will not use the aggressive nomination procedure defined in >>> [RFC5245]. >>>=20 >>> An ICE agent compliant to this specification MUST inform the peer >>> about the compliance using the 'ice2' ICE option. >>>=20 >>> NOTE: The encoding of the 'ice2' ICE option, and the message(s) = used >>> to carry it to the peer, are protocol specific. The encoding for = the >>> Session Description Protocol (SDP) [RFC4566] is defined in >>> [I-D.ietf-mmusic-ice-sip-sdp]. >>>=20 >>> The intent is clear, but the text could be cleaned up a bit to = enforce >>> the separation between the ICE protocol and the SDP encoding. I = suggest >>> the following for the first paragraph: >>>=20 >>> This section defines a new ICE option, 'ice2'. The ICE option >>> indicates that the ICE agent that includes it is compliant to this >>> specification. For example, the ICE agent will not use the >>> aggressive nomination procedure defined in [RFC5245]. >>=20 >> I think you are looking at an old version. >=20 > Datatracker done me wrong. >=20 >> That section (now section 10 in version 16) does not mention = ice-options. The text that triggered my concern is in section 13: >>=20 >> " First, ICE provides the ice-options attribute. Each extension or >> change to ICE is associated with a token. When an agent supporting >> such an extension or change triggers candidate exchange, it MUST >> include the token for that extension in this attribute. This = allows >> each side to know what the other side is doing. This attribute = MUST >> NOT be present if the agent doesn't support any ICE extensions or >> changes.=E2=80=9D >>=20 >> It=E2=80=99s pretty clear that=E2=80=99s just some old (probably = pre-bis) text. But it does need to be fixed prior to publication. >=20 > Yep, I'll leave that to Christer. >=20 >>> We need to do something similar in the trickle spec: >>>=20 >>> OLD >>> Even if a signaling protocol does not include a capabilities >>> discovery method, a user agent can provide an indication within the >>> ICE description that it supports Trickle ICE using a token of >>> "trickle" in the ice-options attribute. This token MUST be = provided >>> either at the session level or, if at the media stream level, for >>> every media stream (an agent MUST NOT specify Trickle ICE support = for >>> some media streams but not others). >>>=20 >>> NEW >>> Even if a signaling protocol does not include a capabilities >>> discovery method, a user agent can provide an indication within the >>> ICE description that it supports Trickle ICE by communicating an = ICE >>> option of 'trickle'. This token MUST be provided either at the >>> session level or, if at the media stream level, for every media >>> stream (an agent MUST NOT specify Trickle ICE support for some = media >>> streams but not others). >>>=20 >>> NOTE: The encoding of the 'trickle' ICE option, and the message(s) >>> used to carry it to the peer, are protocol specific. The encoding >>> for the Session Description Protocol (SDP) [RFC4566] is defined in >>> [I-D.ietf-mmusic-trickle-ice-sip]. >>>=20 >>> Would that address your concern? >>=20 >> I think that would address my concern for ice-trickle. >=20 > Excellent. Awaiting further feedback on that one... >=20 > Peter --Apple-Mail=_9C9B1A93-74E1-4239-A36B-7490671175C6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpym8YACgkQgFZKbJXz 1A3BxhAAr40oeKDMbnUF0kPtgo/e++GT8EpVqGXqnCCf1YVFjkXbVErtWmaU1Fmm A+fTgTtuiwc8Xlm3JbzQ0mxR1hzNH/7+ondIpCKUtqjS+RCJXXwHhVvQil3rKgET 0y5wQJyh//pjECw6jrfB/SJJhkvMjexUc5/U9OZvtRc2JmG2MbfodHJ1nfGkycj7 E2u+5XgRgulRRiXD2oMo0rMrDBNLKLyTUkb7WJTHLg7amWNDPzJS9i+BqIWnarPT 9Z++iBLzgBTbZC0rKGsIA4BnIPKFeE+oI4DCENifY/KWqQajs6oqtgM5dmAD4b01 mJFwoUMZag76geUn4ZhdnFPyAsIPWJPUaxoh8lzzMnWuFbKwVW70QQFwK860ZBgQ lhVa+DhkVofP/e1tPr/Evwkpy5NLPnP9tjTxPEsiPh3qygA/WHshBNld+uEmsdcl 2Kz/iMF3OdXdgDuLoQgQmfBDOaG8THPqUpAw5rL9mplGAPzPZIbMZjBHURxafAYe 0cFdl5JicfaPXZqPKALxIMYgaeeACXfHqzjYRvi2A2gCeWxK1kQuAXlKrw8UnF0z 1Xbd6lJLxIO4DUccm3UxxUSxU+TaDAFmULYhPJuhV5gKQU/qluMqXA2ahWhUAUbq Wqo+7Oy97JYJiK8OaqJozdSNqbU9Ooar6IMI+oHvzJr6Avjc2ZE= =gO0G -----END PGP SIGNATURE----- --Apple-Mail=_9C9B1A93-74E1-4239-A36B-7490671175C6-- From nobody Wed Jan 31 21:38:24 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DA412F28A; Wed, 31 Jan 2018 21:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVMALx0lxItD; Wed, 31 Jan 2018 21:38:21 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30671275FD; Wed, 31 Jan 2018 21:38:20 -0800 (PST) Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w115Vq5x047801 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 31 Jan 2018 23:31:53 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105] From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_2B609A85-1B60-4E3C-908E-2B422416BC21"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <879BAF1F-8DC5-4850-A7CB-711EC85DE282@nostrum.com> Date: Wed, 31 Jan 2018 23:31:51 -0600 Cc: ice@ietf.org To: draft-ietf-ice-trickle.all@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Ice] AD Evaluation of draft-ietf-ice-trickle-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 05:38:23 -0000 --Apple-Mail=_2B609A85-1B60-4E3C-908E-2B422416BC21 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, This is my AD evaluation of draft-ietf-ice-trickle-16. The document is general well written and easy to follow. I have a few = comments and questions I=E2=80=99d like to address prior to IETF LC. Thanks! Ben. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94 - section 3, 2nd to last paragraph: [Note: I already brought this up in a separate email, and Peter = suggested a fix. I=E2=80=99m including it here for completeness] This paragraph is written in terms of the SDP ice-options attribute. It = should talk about the generic ICE option described in section 10 of = 5245bis. - 4, last sentence: =E2=80=9Cearly as possible=E2=80=9D seems a bit = subjective for use with the SHOULD, especially since that will be very = application depended. I imagine developers trying to decide if they = should send an initial offer the second a user hovers over a contact = (which may or may not be a good idea.) Please consider restating this = without the 2119 SHOULD. - 5, 2nd to last paragraph, last sentence: Should =E2=80=9Cfallback to = [RFC3264]=E2=80=9D be =E2=80=9Cfallback to non-ICE processing rules=E2=80=9D= ? -13, first sentence: "Either agent MAY convey subsequent candidate = information at any time allowed by the signaling protocol in use.=E2=80=9D I=E2=80=99m a little confused by this, since previous text said you MUST = NOT keep trickling after sending end-of-candidates. =46rom the context = of the section, I assume this is talking about future exchanges (e.g. a = new offer) , not trickling as a result of a previous change, but the = words seem ambiguous. -16, 2nd paragraph: "Therefore a candidate for a specific component MUST = NOT be conveyed prior to candidates for other components within the same = foundation.=E2=80=9D I=E2=80=99m confused by this sentence; it seems like a deadlock where no = component candidates can be conveyed first. Should =E2=80=9Cother = components=E2=80=9D be =E2=80=9Cearlier components=E2=80=9D? -16, paragraph after the SDP example: This seems to be an explanation of = the example, not a normative statement. Please consider stating without = the 2119 keywords. -18: Please consider using the IESG (iesg@ietf.org) as the contact. I = know we=E2=80=99ve had individual contacts for these in the past, but = the iesg address is (hopefully) more stable than individual or WG = addresses. -19, 2nd paragraph: Stephen=E2=80=99s SecDir review[1] of 5245bis asked for a stronger = statement about the application=E2=80=99s ability to control control = which network interfaces are exposed in ICE candidates.. It may be that = having such a statement in 5245bis is enough, but don=E2=80=99t be = surprised if it comes up in IETF LC or IESG review. [1] = https://mailarchive.ietf.org/arch/msg/ice/fyhuRfrMJqdnCJnE6MJ_0peMFsw --Apple-Mail=_2B609A85-1B60-4E3C-908E-2B422416BC21 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpypkcACgkQgFZKbJXz 1A13Cw//bV+ADR5NXyL0LleF0SUlcf2pDdOwWbxSImWtOghGCEf0b7SlXztDtdNo Ak2CJDJzItM5rhpJ0j/bQOhgMB2T2s+3rqJsLjBeHg/sXW03oxGm/NZFL/P/XnwW 7GK8Diuri8Xi0auJw3CivAfvAKb6PQkJueiT12CN/fLb3DKL50c1l66xJh3lVTvq SWVhm5ux3/NFvVGEyl0o9/ZWvuOaSC1Qgm97nRIRLyZTzDXCDLzWbIGd+7nDvqbW SQlvvJgCA4q0+iMU42qeyjfmhNGg0k3CTSgutHi1/sHlhH2QdoEwWnhpIylNr0hZ UY364h0f7tOrIMxpsEPeue9oxX4GQ6m3Ade0lsJkngCaSOQLcT8Rq4fH3kr5zpdw +E2JI2FbOG289LmOosYjRkaf/bI3KzSV2EpnkxBQyeUHfBZPuV1riwFUhVI9WJ8f RHZJQB6HnnnCSZVmweMS4PHu7rCWFHHRbDvEqz5svTLWbBY17rGEJuYKcJIsW4ky K0EA5OiGrd1KWEa/k/R3Dy1DUUsKIkXBP/TzB3TtuHCryuqMuYh0JoyvX5AdsNXS YtT44W6GmpTsBUSs/Q8eE5N1AbZU7bUFL7gZ2EWwPzI3VO3mIzrQVWxH0W+svPCP 8q3U5St2+UYZHbWRKyrCE78EI59gRcXHRNMf7QLqcL2UoAJL1u0= =kGwo -----END PGP SIGNATURE----- --Apple-Mail=_2B609A85-1B60-4E3C-908E-2B422416BC21--