Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-08.txt

From: Philip Matthews <[email-masked]>
Date: Thu, 3 Jul 2008 14:09:09 -0400

Marc:

Thanks very much for your detailed review and comments. I have  
included my replies inline.

- Philip

On Sat, 28-Jun-08, at 17:35 , Marc Petit-Huguenin wrote:
> I finished updating my TURN server code, so here's a partial review of
> turn-08:
>
> - Section 4, paragraph 3:  "The server's administrator MAY choose..."
>
>
> I am not sure to understand why this sentence is here.  Should be
> removed or moved in a non-normative section.

I put this sentence here because it contains normative text, because  
the paragraph that it is in discusses authentication, and because this  
question has come up a few times in the past 6 months. I agree that it  
could be argued that this is not really normative text, but there is  
no obvious non-normative place to put it right now.

>
>
> - Section 4, paragraph 12:  "Subsequent requests on an allocation use
> the same username and password..."
>
> They use the same username but can use a different password.

I assume you are referring to the possibility of changing the password  
while the allocation is active. We have previously discussed this  
topic, and Rohan suggested at that time that the spec simply be silent  
on this point, since other specs are equally silent. I have adopted  
Rohan's suggestion for now because it is quick and easy. However, if  
people feel strongly about this issue, then we can re-open it.

>
>
> - Section 6.2, bullet 4:
>
> There is no way for a client to know which bit in the REQUESTED-PROPS
> triggered the 508 response.  I suggest to send back the REQUESTED- 
> PROPS
> attribute with the bits set for properties that the server understand.
> This way the client can retry an allocation by clearing some of the  
> bits.

I have adopted your suggestion. The spec now says:

    4.  The server checks if the request contains a REQUESTED-PROPS
        attribute.  If yes, then the server checks that it understands
        and can satisfy all the flags that are set to 1.  If a flag is
        not understood, or if the server cannot satisfy the request,  
then
        the server rejects the request with a 508 (Insufficient Port
        Capacity) error.  The server includes in its error response a
        REQUESTED-PROPS attribute with all the flags the server
        understands set to 1 and all others set to 0.  Note that the
        combination (E=0, R=1) MUST be treated as unsupported.

>
>
> - Section 6.2, bullet 5:
>
> This contradicts paragraph 14 of section 6.1.  I suggest to use the  
> text
> in section 6.1, because some future properties can be meaningful  
> with a
> RESERVATION-TOKEN (and it's perhaps the case for the Preserving bit).

Good catch. Section 6.1 is correct. I have updated bullet 5 to read:

    5.  The server checks if the request contains a RESERVATION-TOKEN
        attribute.  If yes, and the request also contains a REQUESTED-
        PROPS attribute with the E and R flags set to any combination
        other than E=0 and R=0, then the server rejectes the request  
with
        a 400 (Bad Request) error.  Otherwise it checks to see if the
        token is valid (i.e., the token is in range and has not expired,
        and the corresponding relayed transport address is still
        available).  If the token is not valid for some reason, the
        server rejects the request with a 508 (Insufficient Port
        Capacity) error.

>
>
> - Section 6.2, paragraph 13:
>
> I still think that the right thing to do is using turn-ipv6 (i.e.
> explicitly ask for an IPv6 allocation).

Let's discuss this on a separate thread.

>
>
> - Section 6.2, paragraph 15:
>
> I think that this paragraph should say something about
> draft-ietf-tsvwg-port-randomization.

Though this draft is interesting, I am not sure what could be said  
about it in the TURN spec. As I see it, the TURN server would ask the  
port allocation routines in the underlying OS for a port number. If  
those routines implement port randomization, then good; if they do  
not, then there is not much the TURN server can do.

What sort of text did you have in mind?

>
>
> - Section 6.2, paragraph 18:
>
> Should the server reject an Allocate with a RESERVATION-TOKEN that was
> reserved from a different protocol (i.e. if the first port is  
> allocated
> from a UDP connection, should the server reject the RESERVATION-TOKEN
> allocate if it is on a TCP connection?)

It is indeed a very unusual case, and I suspect that many  
implementations would not handle it correctly. but I don't see a  
reason to require the server to reject this case. It seems to be that  
this is a situation where "Be liberal in what you accept, but  
conservative in what you send" applies.

Do you see a reason for mandating that the server reject this? Or are  
you suggesting that the spec explicitly mention this case?

>
>
> - Section 8, paragraph 5:  "The default permission lifetime MUST be  
> 300
> seconds"
>
> Either "default" or "MUST" is redundant.

I want to make it clear that the default permission lifetime is must  
be 300 seconds, since that value is used whenever no lifetime is  
explicitly included. So I don't really see the case for changing the  
wording here.

>
>
> - Section 10.4, paragraph 4:
>
> If the length is equal to 0, should an empty packet be sent (like when
> Send contains an empty DATA attribute) or does it just refresh the
> permission?

I don't have a strong opinion on this subject, but for now I have  
added words to clarify that the UDP datagram is still formed and sent.  
This is at least consistent with the behavior for a Send indication  
with a DATA attribute containing 0 bytes.

>
>
> - Section 10.7, paragraph 7:
>
> This paragraph is nearly identical to section 9.3.  I suggest to add
> another section between 10 and 11 that merge the two texts.

I didn't create a new section, but I re-arranged and rewrote some  
text. The stuff about checking permissions is now covered only in  
section 9.3, and section 10.7 now says roughly 'if section 9.3 says a  
ChannelData message should be sent, then do this'.
>
>
> - Section 13:
>
> As I said in a previous email, the codepoint and definition for the  
> ICMP
> attribute are missing.
>
This has been fixed.
The code point is 0x0030 and the attribute definition now reads:

13.9.  ICMP

    This attribute is included by the server in a Data indication to
    indicate that the Data indication contains information from an ICMP
    message that was received by the server.  The attribute has the
    following format:
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |     Code      |           MUST be 0           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The Type and Code fields of the attribute are taken from the Type  
and
    Code fields in the ICMP message received by the server.

Text elsewhere has been updated to clearly distinguish the case where  
the attribute is included vs. when it is not included.

>
>
> Some nits:
>
> - Section 2.5, paragraph 3:  "... from the peer DOES NOT refresh ..."
>
> "DOES NOT" is not defined by RFC 2119.  Besides this section is
> non-normative.
>
>
> - Section 5, paragraph 11:  "... EXCEPT an Allocate request..."
>
> "EXCEPT" is not defined by RFC 2119.
>
> - Section 6.1, paragraph 5:  "...note that this is NOT the..."
>
> "NOT" is not defined by RFC 2119.

In the three above cases, the use of bold is only for emphasis.

>
>
> - Section 6.1, paragraph 6:  "...the field to less tha the default  
> value."
>
> s/tha/than/

Fixed.

>
>
> - Section 7.2, paragraph 2:  "...but the allocation is NOT deleted..."
>
> "NOT" is not defined by RFC 2119.

See above.

>
>
> - Section 11.2, paragraph 13:  "...SHOULD relay as all ICMP..."
>
> s/as all/all/

Fixed.
>
>
> - Section 11.2, paragraph 13:  "...and MUST relay at at least..."
>
> s/at at/at/

Fixed.

>
>
> - Section 13.7, paragraph 3:  "...and MUST be ignores on receiption."
>
> s/receiption/reception/

Fixed.

>
>
> -- 
> Marc Petit-Huguenin           [                                 ]
> Home: [email-masked] [RFC1855-compliant space for rent ]
> Work: [email-masked]            [                                 ]
> [                                                               ]
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Thu, 3 Jul 2008 14:11:52 -0400

On Mon, 30-Jun-08, at 12:29 , Eilon Yardeni wrote:
>
> - Section 9.4.  Receiving a Data Indication
>
> This section should mention the ICMP attribute that can be included in
> the Data Indication. If it is included, the client shouldn't just
> deliver the DATA attribute content to the application.

Thanks for your comment. The text for this section now reads:

9.4.  Receiving a Data Indication

    When the client receives a Data indication, it checks that the Data
    indication contains both a PEER-ADDRESS and a DATA attribute, and
    discards the indication if it does not.

    The client then checks for the presence of the ICMP attribute.  If  
it
    is present, the Data indication contains an ICMP message as  
described
    in Section 11.

    If the Data indication does not contain an ICMP attribute, the  
client
    delivers the data octets inside the DATA attribute to the
    application, along with an indication that they were received from
    the peer whose transport address is given by the PEER-ADDRESS
    attribute.

- Philip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 03 Jul 2008 11:31:18 -0700

Philip Matthews wrote:
> Marc:
> 
> Thanks very much for your detailed review and comments. I have included
> my replies inline.
> 
> - Philip
> 

[...]

> while the allocation is active. We have previously discussed this topic,
> and Rohan suggested at that time that the spec simply be silent on this
> point, since other specs are equally silent. I have adopted Rohan's
> suggestion for now because it is quick and easy. However, if people feel
> strongly about this issue, then we can re-open it.

It is fine to keep the spec silent about this, but in this case the text
should simply say "Subsequent requests on an allocation use the same
username..."

> Though this draft is interesting, I am not sure what could be said about
> it in the TURN spec. As I see it, the TURN server would ask the port
> allocation routines in the underlying OS for a port number. If those
> routines implement port randomization, then good; if they do not, then
> there is not much the TURN server can do.

The randomization algorithm can be implemented in TURN.

> What sort of text did you have in mind?

Just one line stating that a TURN implementation on top of an OS that
does not do port randomization should implement it itself.

>> reserved from a different protocol (i.e. if the first port is allocated
> implementations would not handle it correctly. but I don't see a reason
> to require the server to reject this case. It seems to be that this is a
> situation where "Be liberal in what you accept, but conservative in what
> you send" applies.
> 

I think that a TURN server should accept this and that the spec should
explicitly mention it.

Thanks.

---

From: Philip Matthews <[email-masked]>
Date: Fri, 4 Jul 2008 02:28:16 -0400

On Thu, 3-Jul-08, at 14:31 , Marc Petit-Huguenin wrote:
>> topic,

OK. I have removed the "and password" part.
>> about

How about the following text:

Some servers may choose to pre-allocate a number of ports from the  
underlying OS and then later assign them to allocations; for example,  
a server may choose this technique to implement the E and R flags in  
the REQUESTED-PROPS attribute. If a server operates in this manner  
then it SHOULD do port randomization [ref draft-ietf-tsvwg-port- 
randomization] when assigning ports to allocations.
>> reason

Do you have a scenario in mind which needs this?

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 04 Jul 2008 07:09:01 -0700

[...]
> underlying OS and then later assign them to allocations; for example, a
> server may choose this technique to implement the E and R flags in the
> REQUESTED-PROPS attribute. If a server operates in this manner then it
> SHOULD do port randomization [ref draft-ietf-tsvwg-port-randomization]
> when assigning ports to allocations.

This is one scenario I didn't think of.  But more generally if the OS
does not use randomization, the TURN server should do it.

> Do you have a scenario in mind which needs this?

No.  It's just that an implementation can choose one way or the other
and it can be a problem when in the future somebody finds an usage for this.

Thanks.

---

From: Philip Matthews <[email-masked]>
Date: Fri, 4 Jul 2008 11:56:51 -0400

> does not use randomization, the TURN server should do it.

I am leery of adding of adding an additional normative dependency to  
TURN, since this would become a normative dependency for ICE. So I  
have added the following text to TURN to address your concern and to  
call attention to the port randomization work, while avoiding a  
normative dependency.

      NOTE: The IETF is currently investigating the topic of randomized
      port assignments to avoid certain types of attacks (see
      [I-D.ietf-tsvwg-port-randomization]).  It is recommended that a
      TURN implementor keep abreast of this topic and, if appropriate,
      implement a randomized port assignment algorithm.  This is
      especially applicable to servers that choose to pre-allocate a
      number of ports from the underlying OS and then later assign them
      to allocations; for example, a server may choose this technique to
      implement the E and R flags in the REQUESTED-PROPS attribute (see
      below).

> and it can be a problem when in the future somebody finds an usage  

OK. I have added the following note to the text:

      NOTE: The port N+1 reservation is a global reservation and is not
      specific to a particular allocation, since the Allocate request
      containing the RESERVATION-TOKEN will use a different 5-tuple and
      will create a different allocation.  The 5-tuple for the
      subsequent Allocate request can be any allowed 5-tuple; the
      subsequent Allocate request can use a 5-tuple with a different
      client IP address and port, a different transport protocol, and
      even different server IP address and port (provided, of course,
      that the server IP address and port is one that the server is
      listening for TURN requests on).

I briefly considered adding restrictions on what the subsequent 5- 
tuple can be, but decided to leave it wide-open for now.

- Philip