On Sat, Apr 4, 2009 at 6:22 PM, Christian Huitema <[email protected]> wrote: >> 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. >
Hmmm. I'm not sure what you're counting here. In -06 the algorithm discussion runs from page 8 to 16 and the normative attribute and behavior discussion runs from 16 to 24. The algorithm section used to be shorter, but people kept asking for qualifiers and more precision in what they did and didn't do. I'm really hesitant to shorten it significantly given that it's as long as it is because people have asked for it to be that long. I don't really think 8 pages is that long, do you? >> 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. > It's not possible to do any lifetime or other timeout tests without XOR-RESPONSE-TARGET. The CACHE-TIMEOUT mechanism prevents the attack you describe. It's described at the beginning of Section 5 and in Section 7.8 among other places. Group consensus was that since there is no amplification attack, Section 7.8 only gives SHOULD level to requiring the server to only respond to XOR-RESPONSE-TARGET when there is a current cached request for the target address, and rate-limits XOR-RESPONSE-TARGET when CACHE-TIMEOUT is not used. Obviously that decision is up for debate, but there were conversations both on the mailing list and face to face that led to the current text. TURN is overkill for this application. Bruce > -- Christian Huitema > > > > _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
