Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-turn (Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)) to Proposed Standard

From: Philip Matthews <[email-masked]>
Date: Wed, 4 Feb 2009 22:31:35 -0600

[Brian sent his comments as an attachment. I have taken the liberty to  
paste them into this message so they can be read without needing to  
open up an attachment.]

Brian:

Thanks for your comments. My apologies for being slow in responding.

See my detailed reponses inline.

- Philip

On Mon, 19-Jan-09, at 18:49 , Brian E Carpenter wrote:
> I have been selected as the General Area Review Team (Gen-ART)  
> reviewer
> for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-behave-turn-12.txt
> Reviewer: Brian Carpenter
> Review Date: 2008-01-20
> IETF LC End Date: 2009-01-27.
> IESG Telechat date: (if known)
>
> Summary: In good shape, a few issues raised.
> --------
>
> Comments:
> ---------
>
> I don't normally post my Gen-ART reviews to the main IETF list, but  
> will do so
> in this case since there are some issues of principle mentioned below.
> In general it is a well written and clear draft and I trust the WG  
> consensus
> that the TURN protocol exchanges are technically sound. I have not  
> reviewed
> the protocol details in sections 6 through 16.
>
> Major issues:
> -------------
>
> > 19.  IAB Considerations
> >
> >    The IAB has studied the problem of "Unilateral Self Address  
> Fixing",
>
> I don't know whether the IAB has considered this draft, but IMHO they
> should probably do so. It is extremely hard** to qualify TURN as a
> short-term fix for a specific problem (IAB criterion #1) or to agree
> that a realistic exit strategy is: "will no longer be needed once  
> there
> are no longer any NATs" (IAB criterion #2). I'm not saying that TURN
> shouldn't be standardised - obviously, we need a solution in this  
> space,
> and TURN is the one that has gathered consensus. But it's a bit  
> hypocritical
> to publish it without saying honestly that its lifetime is  
> indefinite and
> the first two IAB criteria cannot realistically be satisfied in this  
> case.
>
> ** For example, the Introduction says:
> >    TURN was originally invented to support multimedia sessions  
> signaled
> >    using SIP.
> >    ...However, care has been taken to
> >    make sure that TURN is suitable for other types of applications.
>

I agree with you that it seems very unlikely that the need for TURN  
will go away soon. Though ICE endeavors to find a direct path whenever  
this is possible, the nature of NATs means that there will be corner  
cases where TURN is needed for a long time. For that reason, I don't  
see TURN going away until NATs themselves go away. And I think that  
NATs will be around for a long time, especially as we are now  
considering using NATs as a core part of our IPv4-to-IPv6 transition  
story.

I view this comment as being directed more towards the IAB than the  
authors of TURN. Or do you have specific suggestions on how the text  
in this section should be reworded?

>
> > 2.6.  Other Features
> ...
> >    Note that, because the
> >    server does not relay ICMP messages, the client will have to  
> use a
> >    Path MTU discovery algorithm based on the one in [RFC4821].
>
> This seems like a major point, not just a note. Doesn't it impose a  
> rather
> large and novel requirement on client implementations? Is it in fact  
> a hidden
> normative requirement for a TURN client?

Support for ICMP relaying was in a earlier version of the draft, but  
was removed because it was felt to be too immature and because none of  
the current TURN implementations were interested in supporting it.  
Right now, no one is really interested in this because most  
applications using TURN use small packets anyway, and a TURN server  
supporting ICMP relaying is much harder to implement.

Do you have some suggested wording change?

>
> > 17.1.5.  Impersonating a Server
> ...
> >    This attack is prevented through the digest authentication  
> mechanism,
> >    which provides message integrity for responses in addition to
> >    verifying that they came from the server.
>
> I'm no expert, but is this subject to the sort of vulnerability
> discussed in RFC4169, if an attacker has observed previous traffic
> and is capable of spoofing the server's IP address?

I am no expert either, but I understand that changing the nonce  
regularly (which TURN allows) solves this problem.

>
> > 18.  IANA Considerations
>
> I'm surprised there is no registry for the channel numbers,  
> especially since:
>
> > 0x8000 through 0xFFFF: These values are reserved for future use.

Channel numbers are not codepoints in the usual meaning of this word,  
so I didn't think one was appropriate. However, you are the second  
person to make this comment, so I have asked with WG for their opinion  
on this question.

>
>
> Minor issues:
> -------------
>
> > 1.  Introduction
> ...
> >    The client does this by allocating an IP address and port on the
> >    server, called the relayed-transport-address.
>
> This reads rather strangely, as if the client was able to pick any
> address and port that it likes, which is clearly impossible. (The
> description in section 2.2 is fine.)
> Maybe s/allocating/obtaining/

OK. I went with "obtaining".

>
> > 2.  Overview of Operation
> ...
> >    The client learns the server's transport
> >    address through some unspecified means (e.g., configuration),
>
> Other protocols involving relays, for example 6to4, have got into  
> operational
> trouble in this area, especially when using anycast addresses. While  
> this
> probably shouldn't be a topic for the base spec, I'd appreciate a  
> pointer
> to work on this topic, or at least a warning that it conceals  
> serious operational
> issues. (The TURN authentication and permissions mechanisms don't  
> address this
> issue, since they apply after a client has decided which relay to  
> use.)

Due to some recent requests by one or two WG participants, the design  
of the protocol has been recently tweaked so that anycast location of  
servers should be possible. However, no draft on how to put the pieces  
together into a workable anycast solution has appeared yet.

>
> > 2.1.  Transports
> >
> >    TURN as defined in this specification always uses UDP between the
> >    server and the peer.  However, this specification allows the  
> use of
> >    any one of UDP, TCP, or TLS over TCP to carry the TURN messages
>
> Is there a reason that SCTP is not mentioned? Of course SCTP has its  
> own
> issues with NATs, but it would be a useful clarification to say either
> that it is definitely not supported or that it is left for future  
> work.

The initial motivation for TURN was to allow a client behind non- 
BEHAVE-compliant NATs to communicate with a peer that is also behind a  
non-BEHAVE-compliant NAT. Because the NAT is non-BEHAVE-compliant, it  
seems highly unlikely that the NAT would support SCTP traffic. Yes, I  
can invent deployment scenarios where TURN is needed even with BEHAVE- 
compliant NATs, but this is not the current driver for this work.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Feb 2009 10:29:54 +1300

On 2009-02-05 17:31, Philip Matthews wrote:
> paste them into this message so they can be read without needing to open
> up an attachment.]

[I do that with Gen-ART reviews, since they are detached and added to
the Gen-ART archive of reviews.]

>> I have been selected as the General Area Review Team (Gen-ART) reviewer
>> >    The IAB has studied the problem of "Unilateral Self Address Fixing",
>>
>> that a realistic exit strategy is: "will no longer be needed once there
>> shouldn't be standardised - obviously, we need a solution in this space,
>> to publish it without saying honestly that its lifetime is indefinite and
>> >    TURN was originally invented to support multimedia sessions signaled
>> >    using SIP.
> I agree with you that it seems very unlikely that the need for TURN will
> go away soon. Though ICE endeavors to find a direct path whenever this
> is possible, the nature of NATs means that there will be corner cases
> where TURN is needed for a long time. For that reason, I don't see TURN
> going away until NATs themselves go away. And I think that NATs will be
> around for a long time, especially as we are now considering using NATs
> as a core part of our IPv4-to-IPv6 transition story.
> 
> authors of TURN. Or do you have specific suggestions on how the text in
> this section should be reworded?

No, I really wanted to avoid the IAB saying later that they
weren't happy with this document. Having made my point on the IETF
list, I'm done.

> 
> 
> 
>>
>> > 2.6.  Other Features
>> ...
>> >    Note that, because the
>> >    server does not relay ICMP messages, the client will have to use a
>> large and novel requirement on client implementations? Is it in fact a
>> hidden
> Support for ICMP relaying was in a earlier version of the draft, but was
> removed because it was felt to be too immature and because none of the
> current TURN implementations were interested in supporting it. Right
> now, no one is really interested in this because most applications using
> TURN use small packets anyway, and a TURN server supporting ICMP
> relaying is much harder to implement.
> 

Well, 'will have to' sounds very close to 'MUST' to me. I would
suggest either making it a MUST or toning it down to
'may need to'; otherwise it's ambiguous whether it's normative
or not.

> regularly (which TURN allows) solves this problem.

OK, maybe add a sentence saying that?

> 
> 
>>
>> > 18.  IANA Considerations
>>
>> I'm surprised there is no registry for the channel numbers, especially
>> since:
>>
> Channel numbers are not codepoints in the usual meaning of this word, so
> I didn't think one was appropriate. However, you are the second person
> to make this comment, so I have asked with WG for their opinion on this
> question.

Sure, whatever the consensus is.

>> Minor issues:

I leave these up to you; none of them were intended as blocking
comments.

Thanks
    Brian

>> trouble in this area, especially when using anycast addresses. While this
>> probably shouldn't be a topic for the base spec, I'd appreciate a pointer
>> to work on this topic, or at least a warning that it conceals serious
>> operational
>> issue, since they apply after a client has decided which relay to use.)
> 
> Due to some recent requests by one or two WG participants, the design of
> the protocol has been recently tweaked so that anycast location of
>> >    server and the peer.  However, this specification allows the use of
>> Is there a reason that SCTP is not mentioned? Of course SCTP has its own
>> that it is definitely not supported or that it is left for future work.
> 
> 
> The initial motivation for TURN was to allow a client behind
> non-BEHAVE-compliant NATs to communicate with a peer that is also behind
> a non-BEHAVE-compliant NAT. Because the NAT is non-BEHAVE-compliant, it
> can invent deployment scenarios where TURN is needed even with
> BEHAVE-compliant NATs, but this is not the current driver for this work.
> 
> 
> 
> 
> 
> 
>

---

From: Philip Matthews <[email-masked]>
Date: Thu, 5 Feb 2009 18:29:06 -0600

On Thu, 5-Feb-09, at 15:29 , Brian E Carpenter wrote:

>> open
>> will

OK.

> 'may need to'; otherwise it's ambiguous whether it's normative

It is not a normative requirement, so I changed it to "may need to".

> OK, maybe add a sentence saying that?

Since I am not at all an expert on security, I have e-mailed Jonathan  
(who wrote the security section) to see if he can comment. Any other  
security experts are welcome to comment as well ...