Subject: [MMUSIC] Part 4 of questions/comments on draft-ietf-mmusic-ice-08

From: Philip Matthews <[email-masked]>
Date: Wed, 3 May 2006 09:32:55 -0400

Jonathan:

Here are some more comments and questions about this draft.
Hope they help.
These are probably the last comments I will have time to send before
the WGLC closes.

And, BTW, it is clear that you have put a HUGE effort into this work.
Many thanks for all this!!
I think this stuff we be very useful.

- Philip

Technical questions and comments
============================

1) Perhaps I am just dense, but I am finding it difficult to  
determine which portions of
     the procedures specified in the new STUN draft (draft-ietf- 
behave-rfc3489bis-03)
     actually apply when ICE is used. When I sat down to try to write  
some pseudo-code
     to handle the receipt of a STUN request, I found I had to weave  
back and forth
     between the two documents and take some guesses as to which  
paragraphs in
     rfc3489bis to ignore. For example, section 9.1.1 of rfc3489bis  
says that a server
     should include a NONCE attribute in certain error responses, but  
I am guessing
     that statement does not apply for ICE.
     Would it be possible to give somewhere, perhaps in an appendix,  
an integrated
     description of the STUN procedures for ICE (that is, an  
integration of the procedures
     specified in rfc3489bis, plus sections 7.7 and 7.8 for sending  
and receiving STUN requests
     for ordinary candidates, and sections 7.10.1 and 7.10.2 for  
sending and receiving
     STUN requests for peer-reflexive candidates)?

2) In section 7.10.1, the document says
         The comparison of the source IP and port of the Binding  
Request and
         the IP address and port of the remote transport address in the
         matching transport address pair may indicate inequality.  In  
that
         case, the source IP and port of the Binding Request (and  
again, for
         relayed transport address, this refers to the source IP  
address and
         port of the packet when it arrived at the relay) are  
compared to the
         IP address and ports across the transport address pairs in  
*all*
         remote candidates.
    When you say "*all*" here, do you mean all candidates for the  
same media stream
    which have the same transport protocol?

3)  In section 7.10.1, the document talks about passing a "Get Req"  
event to the state machine
     of the (local candidate, peer-reflexive candidate) pair.
     Is this in addition to the event passed to the state machine of  
the (local candidate, generating candidate) pair,
     or instead of?  The last paragraph of section 7.10 suggests that  
this is in addition to,
     but it is not clear to me why the state machine for (local  
candidate, generating candidate) should get this event.

4)  In section 7.10.1, the document says
       "The agent SHOULD select the candidate
         pair corresponding to the combination of the alternate remote
         candidate and the native candidate from the original matching
         candidate pair."
     When you say SHOULD here, do you mean that the agent might  
select a different candidate pair,
     or that the agent might elect not to send the "Get Req" to this  
pair?
     Would you explain why agent might choose to do something different?

5)  Is the timer described in section 7.13 "Sending Media" the same  
as the timer
     for promoting a candidate to active (section 7.9)? The wording  
used is almost identical.

6) In section 7.6, the document says
           "If, while in the Testing state, the agent receives a  
Binding Request
            matching that transport address pair, and this Binding  
Request
            generates a successful response, the transport address  
pair moves
            into the Send-Valid state.  In addition, the agent  
retransmits a
            Binding Request for the transaction in progress."
     How is this retransmission relate to the STUN client state  
machine for this address pair?
     Section 7.1 of draft-ietf-behave-rfc3489bis-03 talks about  
sending a total of 9 requests
     at exponentially increasing intervals. Does the above paragraph  
mean that the retransmit
     timer simply expires early? Or does this transmission have no  
effect on the retransmit
     timer and the retransmission count (thus potentially sending a  
total of 10 requests)?

Editorial comments
===============

Section 7.6:

-   Perhaps I am missing something, but aren't the names for the Send- 
Valid and Recv-Valid states reversed?
     That is:
           - In Send-Valid, the local agent knows it can _receive_   
on that transport address pair
           - In Recv-Valid, the local agent knows it can  _send_      
on that transport address pair

-  Does an otherwise valid STUN request generate a success response  
when received in any state?
    As I stated in a previous message, I think it shouldn't in the  
Invalid state, but whatever is decided,
    perhaps a clear statement on this issue would be helpful?

Section 7.7
-     "ransport" should be "transport"?
-     "reflesive" should be "reflexive"?
-     "neccesarily" should be "necessarily"?
-     "oferrer" should be "offerer"?

-    Specify processing of other error codes listed in draft-ietf- 
behave-rfc3489bis?
      Specifically: 300, 434, 435, 436, 437 are presumably all errors  
because none of them are applicable
      to this usage of STUN?

-       " ... to launch DoS attacks Section 13.4.2"
      Formatting:
         "... to launch DoS attacks (see Section 13.4.2)."

-         "... contains a reflexive or relayed candidate derived from  
a local candidate with that local transport address."
      This is true for any derived  candidate, not just reflexive or  
relayed candidates.
      Suggest  rewording as follows:
               "... contains a  candidate derived from that local  
transport address."

-         "If the USERNAME was not valid, the agent generates a 430."
    Do you perhaps mean 436 (Unknown Username) rather than 430 (Stale  
Credentials)?
    Also, suggest changing "was" to "is" for consistency (in verb  
tense) with the surrounding sentences.

Section 7.8:
-    "The first is generation ..., and the second ICE-specific"
       Suggest adding an "is" after "second" for consistency.

-      "An agent will continue to receive periodic STUN connectivity  
checks
          on a local transport address as long as it had listed that  
transport
          address, or one derived from it, in an a=candidate  
attribute in its
         most recent offer or answer, the state machine for that  
transport
         address is in the Recv-Valid or Valid states, and the transport
         address is for UDP."
     I think it is possible to continue to receive them even when the  
local state machine
     is in other states, for example, the Invalid state. See my  
previous message
     on this subject.

Section 7.9 "Promoting a Candidate to Active"

-  Since the retry interval for STUN is initially 100 milliseconds,  
perhaps the default value for
    timer Tws should be 120 milliseconds (rather than 100  
milliseconds) to allow time for a
    retry to complete for the candidate pair that is two earlier in  
the check sequence?
   Or perhaps even larger, if candidate pairs from different m/c  
lines are combined in a single
   candidate pair check ordering.

- Perhaps the document should specify some relationships that should  
hold between the various timer intervals?

-     "When the agent behind such a NAT sends a Binding Request to  
the other agent (assuming it is reachable) ..."
    For clarity, suggest replacing "it" by "the other agent".

Section 7.10.1

-     " ... sees if a transport address with
        that same component ID exists in the peer reflexive  
candidate.  If
        not (and it shouldn't),..."
   There might be a remote transport address with the same tid if the
   local agent had previously received a STUN Request for the same  
USERNAME.

-      "   Newly created or not, the agent extracts the component ID  
from the
             matching transport address pair, and sees if a transport  
address with
             that same component ID exists in the peer reflexive  
candidate.  If
             not (and it shouldn't), the agent adds a transport  
address to the
             peer reflexive candidate.  This transport address is  
equal to the
             source IP address and port from the incoming STUN  
Binding Request
            (and in the case of a relayed transport address, the one  
seen by the
            relay).  It is assigned the component ID equal to the  
component ID in
            the matching transport address pair.  This transport  
address will
            have a tid, equal to the concatenation of the candidate  
ID for this
            new candidate, and the component ID, separated by a colon."
    Presumably, the transport protocol and qvalue of the peer  
reflexive candidate
    are the same value as the corresponding values of the generating  
candidate,
    and the rules for setting the various optional (extension-attr-name,
    extension-attr-value) pairs are specific to the transport protocol
    (with none currently defined for UDP).

Section 7.11.1 Sending of a Subsequent Offer

-     "o  If the candidate in the m/c-line is valid, all other  
candidates
            SHOULD be removed.  This has the effect of stopping  
connectivity
            checks of other candidates.  This SHOULD would not be  
followed if
            an agent wanted to keep a candidate ready for usage  
should, for
            some reason, the active candidate later become invalid."
    If the candidate in the m/c line is a low priority candidate  
(e.g., a STUN relay candidate)
    and the connectivity checks for higher priority candidates have  
not yet finished,
    then removing the other candidates would be bad.
    This situation could occur if the subsequent offer was triggered  
for reasons
    other than ICE processing.

Section 7.11.2  Receiving the Offer and Sending the Answer

-   When talking about removing candidate pairs, the spec says
            "3.  If the agent receives a STUN Binding Request for  
that candidate
                  pair, the agent SHOULD generate a 430 response."
     The document currently states in section 7.8 that a STUN  
response is generated
     based on just a prefix match on the USERNAME. The above sentence  
seems
     incompatible with this.
     (I suggested in a previous message that the STUN Response should  
be based on an exact match
     of the USERNAME, which would be consistent with this sentence).

Section 8    Guidelines for Usage with  SIP

-       "Two latency of figures are of particular interest."
     Perhaps you mean the following??
           "Two latency values are of particular interest."

Section 11.1
-      "In this example, the NAT has the address and port independent  
mapping property
          and the address dependent permission property".
     I believe the BEHAVE terminology is "endpoint-independent  
mapping" and
     "address-dependent filtering".

- Is there is an error in the SDP for the first example?
        v=0
        o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP
        s=
        c=IN IP4 $STUN-PUB-1.IP
        t=0 0
        a=ice-pwd:$LPASS
        m=audio $STUN-PUB-1.PORT RTP/AVP 0
        a=rtpmap:0 PCMU/8000
        a=candidate $L1 1 UDP 1.0 $L-PRIV-1.IP $L-PRIV-1.PORT
        a=candidate $L2 1 UDP 0.7 $NAT-PUB-1.IP $NAT-PUB-1.PORT
    Should the address and port in the m/c line be NAT-PUB-1.IP and  
NAT-PUB-1.PORT?

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