> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Cullen Jennings
>
> I asked some folks on this thread a few years ago for an example of a
> real deployment where it would not be possible to use 4474 as long as
> the SBC implemented 4474. I'm still waiting for an example of where it
> actually is broken.
If the From is an E.164, then you're right transit providers can re-sign it
anew, changing the From domain to their own. There are several problems with
this, though:
a) It has a deployment problem; we'd need all intermediaries which
change anything signed by 4474 to all support 4474 re-signing, for 4474 to be
deployable. Otherwise the signature will constantly fail. If it constantly
fails, no one will try to use it. If no one tries to use it, the
intermediaries have no reason to implement re-signing. Ergo, Catch-22.
b) It changes the From URI. Of course many intermediaries already do
that for other reasons, but it's not like we should *require* them to do it if
the only reason they would need to is to re-sign a message.
c) We shouldn't *want* to force the intermediaries to re-sign. It just
makes it hop-by-hop trust. Unless of course you believe the things being
changed by the intermediaries are such that they MUST NOT be changed by
intermediaries for the purposes of identity, because they are inherent to the
meaning/value of "Identity". For some things I don't believe you or anyone
really feel that - for example call-id and cseq. The questionable one would be
SDP.
d) Re-signing is expensive; it's both validating the received one, and
signing it again. The transit provider business is about low cost. So they'll
just delete the identity headers rather than resign, if they even do anything.
> Hadriel hypothesized a type of situation where it
> could be broken. That was the case where service provider A passed
> call to B who passed call C and they were not using E.164 numbers but
> were using email style addresses and the one in the middle wanted to
> do media steering or restrict what codecs where allowed.
Well, to be fair the one in the middle could have any number of reasons for
changing things which would break the signature. Call-id obfuscation, CSeq
number re-writing due to various b2bua functions, changing SDP for transcoding
or dtmf interworking, etc. You or your company knows all the reasons as well
as I do. :)
-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
