> > Cullen said transitive trust of the entire SIP network for > > Identity was fine > > Uh, I don't think I exactly said that but if I did, I like to > contradict myself now :-) Actually if I thought this, it seems that > the From header would be fine and we would have no need for 4474 or > 3325.
RFC4474 and RFC3325 are useful and valuable and necessary. I have not said otherwise. Thing is, their applicability on the SIP networks being designed and deployed is limited, much as SIP's early design had UACs sending SIP directly to UASs and slowly proxies became necessary due to NATs, firewalls, network-provided QoS (via SDP snooping), and so on. I'm not sure why you removed ", and RFC4474 was sufficient even with SBCs in the network" from my sentence, as it was relevant to the meaning of my statement. As I explained in Chicago in the last timeslot in SIP, RFC4474 doesn't work if the Invite traverses SBCs that are not owned by the originating domain's authentication agent. SIP networks deployed and operating today have SBCs that aren't operated by the originating domain's authentication agent. Thus, I don't see how we get identity in a network with SBCs, except via transitive trust: I trust my provider to have validated the signature they received, who trusts the upstream provider to have validated the signature they received, and so on. This has security properties identical to using P-A-I between those domains. draft-ietf-sip-answermode is only one example of the significant need for identity in SIP. Without identity that works across SIP networks being built today, we can't provide the foundation for its necessary authorization mechanism. -d _______________________________________________ Sip mailing list https://www1.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
