> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam > Roach > > Yes, the authors of RFC 3168 analyze what happens when a router is > acting outside of specification, potentially with malice. But is TSV > actively engaged in specifying how to duplicate information in a > different part of the message in the hope that these non-conformant, > potentially malicious intermediaries won't find it? > > No, they aren't. Because that would be patently ridiculous. Recognizing > the potential for an attack doesn't necessarily force the definition of > comically[1] ill-conceived and easily defeated countermeasures. > > Assume the draft on the table is published and implemented. How long > before someone decides that their SBC "needs" to modify the > "P-Original-To" header field? And when they do, will we just define > another header field to squirrel away yet another copy of this > information? (Should we go ahead and define "P-Original-P-Original-To" > right now?)
This implies I'm trying to hide/tunnel the information from intermediaries to get around their policies. I'm not. SBC's (and others) modify the From/To URI for a bunch of reasons. One of those reasons is relationship hiding, and for any such policy there is clearly no point in trying to avoid/bypass it, as they'll just go delete or modify any new headers as you point out. There is nothing we can do for such cases, imho. But for a lot of cases they're not modifying To/From for that reason - they're modifying it to either "fix" them for specific interop reasons, or to hide topology (ie, when it contains IP Addresses or hostnames). Those are the cases I'm trying to get the information through. -hadriel _______________________________________________ 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
