-------- Original Message -------- Subject: Gen-ART LC review of draft-ietf-behave-turn-12.txt Date: Tue, 20 Jan 2009 12:44:36 +1300 From: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> Organization: University of Auckland To: General Area Review Team <gen-art@xxxxxxxx> CC: behave-chairs@xxxxxxxxxxxxxx, draft-ietf-behave-turn@xxxxxxxxxxxxxx, Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>
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. > 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? > 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? > 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. 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/ > 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.) > 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.
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf