[MMUSIC] [Technical Errata Reported] RFC5245 (3619)

[RFC Errata System <[e-mail]>]

The following errata report has been submitted for RFC5245,
"Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5245&eid=3619

--------------------------------------
Type: Technical
Reported by: Ashish Kundu <[e-mail]>

Section: Section 4, 5

Original Text
-------------
Missed candidate pair in ICE standard

Corrected Text
--------------
Scenario: X is caller, Z is callee. X is behind a non-full-cone (such as symmetric) NAT, Z is behind a full-cone NAT. 

ICE standard: Section 2.1 of RFC5245 describes the addresses that are collected as candidate addresses: (local address, server-reflexive address, TURN relay address).  For X: (X:x, X1:x1, Yx:yx), and for Z: (Z:z, Z1:z1, Yz:yz). 

Missed candidate pair in ICE standard: 
1. X:x sends a connection check message to the Z1:z1 (as part of the process in Section 2.2 of the standard) 
2. Since X is behind a non-full cone NAT such a symmetric one, NAT of X maps X:x to X2:x2, sends the message to Z1:z1
3. Z is behind a full-cone NAT, so packets received at Z1:z1 address is forwarded to Z:z by the NAT

Since X is behind a non-full cone NAT such a symmetric one and Z is behind a full-cone NAT, connection from X:x to Z1:z1 would be via a server-reflexive address X2:x2 of X, which is not a candidate address for X as specified by ICE. X2:x2 should be a candidate address of X, which however can only be determine when X sends a message to Z. The pair (X2:x2, Z1:z1) provides a direct connection option between X and Y.

Conditions on which X2:x2 is a valid candidate address:
1. One of the peers (Z) is behind a full-cone NAT, else step 3 above does not succeed.
2. X2:x2 is unique, i.e., different from X1:x1 (already covered by Section 2.1) if and only if one of the peers is  behind a non-full-cone NAT.

So I think there should be two stages in the candidate collection process:
A: Section 2.1 -- candidate addresses independent of the other clients
B: collection of the candidate pairs with respect to the peer, such as X2:x2 and Z2:z2, if any. 

B consists of the following steps including 1, 2, and 3:
4. Z:z determines if X2:x2 from which it received the message is a different address than in the candidate set of X.
5. If 4 is true, then send an OK message to X2:x2 that it received the message with X2:x2 XOR-encoded.
6. X:x receives the OK message in 4, then X:x determines X2:x2 as its new candidate address.

If X:x decides to establish the connection via X2:x2, it sends ACK message to Z2:z2.

Notes
-----
This feedback for improvement of ICE candidate gathering and decision process was   sent to Dr. Rosenberg on Nov 09, 2012. However, since I have not received any response from him over my next two followups and this e-mail, I thought it should be reported via this method. 

This is not an error mesage, but a method to improve the candidate gathering and decision process of ICE.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5245 (draft-ietf-mmusic-ice-19)
--------------------------------------
Title               : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols
Publication Date    : April 2010
Author(s)           : J. Rosenberg
Category            : PROPOSED STANDARD
Source              : Multiparty Multimedia Session Control
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG