On Fri, Feb 20, 2009 at 10:24 PM, Dale Worley <[email protected]> wrote:
Hi Dale, Thank you very much for your feedback. I've integrated all your comments into my working -01 draft, with some additional comments here (i'll reply to your other thoughts separately): > On page 3, you do an accounting for the level of amplification and total > 22 responses for a spoofed INVITE. But of course, if the spoofed call > can be directed to a UA that will answer (voicemail, anyone?), there can > be far more than 22 RTP packets generated. absolutely! i'll elaborate on this more in -01, although i'm trying to be careful not to imply that this particular draft is attempting to solve RTP sink or in-dialog route/contact verification and only "drive by shooting" you can do with UDP - i've started a draft that documents that side of things (and a proposed solution) and will try to submit a -00 over the weekend. > More importantly, such a value-less parameter does nothing > useful: If the client will accept requests without cookies, a request > without the parameter will be accepted. If the client will not accept > requests without cookies, a request without the parameter will elicit a > 4XX response, which can be used to resend the request. A server could behave differently when it receives a request without a cookie in it, for example require authentication, redirect the user statelessly to another transport, or something we've not thought of just yet :-) It's also useful for diagnostic purposes for deployment: how will we know when adoption is so widespread it would be safe to require support for it for a request to proceed? > In regard to reusing the branch parameters of the initial request in the > resent request -- please do not do that. agreed - i'd already removed from my current rev. It was about 4am when i wrote that, and didn't think it through to well :-) ~ Theo _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
