> So most people miss this, which may mean it needs to be clarified more > somehow, but the algorithm section is actually not normative. Maybe, but the draft starts with 20 pages of algorithm discussion, and follows with 3 pages of attribute description. I would be much more supportive if the draft could be summed up as "this draft defines 6 STUN attributes and 2 response codes that can be used when characterizing the attributes of NAT. It gives examples of possible algorithms that justify the allocation of the attributes. It provides security guidelines that prevent misuse of the attributes." You probably don't need more than 5-6 pages for that. > I believe the authentication and CACHE-TIMEOUT mechanisms in the draft > are sufficient for preventing DoS, and there was consensus for that > the last time the change was made and presented a few meetings ago, > but welcome any further comments on the issue. Actually I have a comment there. The XOR-RESPONSE-TARGET attribute has a high potential for abuse, since it allows clients to instruct servers to send packets to arbitrary targets. I understand that requiring authentication helps, but that leaves the door open for failures to implement authentication properly in servers, or failures to secure credentials properly in clients. Again, I would be much more supportive if this attribute definition was removed from the draft. In fact, I believe that XOR-RESPONSE-TARGET is not needed. Most of the tests can be performed using the CHANGE-ADDRESS attribute, which does not have the same potential for abuse. Besides, if you really want to send packets from outside the local network towards arbitrary destinations, you can use TURN. -- Christian Huitema _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf