> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of [EMAIL PROTECTED] > Sent: 29 October 2008 02:37 > To: [email protected] > Subject: Re: [Sip] Comment on DERIVE and B2BUAs > > > From: "Elwell, John" <[EMAIL PROTECTED]> > > An interesting draft addressing a known problem space. Dan Wing has > already pointed out similarities with draft-wing-sip-e164-rrc (now > expired). I fear the present draft will not work in the presence of > B2BUAs along the path of the INVITE request, since these tend to > change things like call-ID, to-tag and from-tag. Since B2BUAs, and > SBCs in particular, are the main reasons why RFC 4474 will not > work, any solution has to be able to work through these devices. > > However... If we change the sequence of operations a bit, so that the > UAS sends a 183 with a Contact carrying a specific header parameter > carrying a crypto-random value, and we get B2BUAs to pass it through > (attaching it to the Contact they use in the 183 they emit on the > other side), then if the UAS does a non-filtered dialog event > SUBSCRIBE, it can check the returned NOTIFY to see if it carries the > Contact header parameter that it created. That's a reasonably good > test that the UAC of the INVITE can be reached via the From value that > the UAS received. [JRE] Unless a B2BUA fails to play according to the rules and acknowledges the SUBSCRIBE without carrying out the same test on the next hop. That is why we really need a cryptographic solution, so that we can see for sure which domain is asserting that the identity is correct.
John _______________________________________________ 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
