Re: Comment on DERIVE and B2BUAs

 

> -----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