> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Elwell, John > > SBCs modify SDP (and perhaps other signed information in SIP requests). > One of the reasons is NAT traversal (should not be applicable with ICE, > but I don't think we can always assume that ICE is used). Other reasons > are topology hiding, media shaping, etc.. Such modification breaks RFC > 4474 signatures.
Not that it's germane to the issue, but SBC's don't change SDP due to NAT traversal, or rather that is not the primary or even secondary reason they do so typically. (and you don't have to take my word for it - SBCs were first deployed in peering interconnects, before NAT traversal was even a feature, and yet they modified SDP back then too) It is a common misconception in the IETF, for some reason. I believe our marketing group categorizes NAT traversal as #4 or 5 on the list in terms of popular reasons for media relay, but other vendors may have different views. (and obviously this could be due to the kind of customers we sell to, vs. other SBCs) The SBCs change SDP to make media flow a certain direction, based on the call signaling path and certain policies. The common reasons are, in no specific order: VPN interconnection/crossing (where even the provider core itself is one or more "VPNs"), traffic engineering, topology hiding, privacy, QoS measurement, QoS marking, transcoding, transrating, NAT traversal, Firewall traversal (which is not the same as NAT traversal, btw), policing/fraud-prevention, rfc2833 interworking, lawful interception, unlawful interception, media format/content inspection, IPv4/v6 conversion, SRTP termination, IPSEC tunnel termination relay, and I'm sure I'm forgetting a couple. Thus ICE removing the need for the SBC to modify SDP is highly improbable. Even if the SBC were the TURN server itself it wouldn't work, because the address it has to give out depends on where the SIP call goes, and is not knowable before-hand except in the simplest of cases. > I would like to hear views on the following: > - The degree to which this is a problem. Well, that depends. For calls within a service provider or domain, or between two service providers directly peering, SBCs should pose no problem, since the rfc4474 signing/verifying can be done by the last/first SBCs of the two domains. Unfortunately, that is a use case rfc4474 provides virtually no benefit for, imho. The primary motivation for using rfc4474 would be when it crosses transit providers/domains - when there's an actual chain of trust greater than 1. So personally I think rfc4474 not working in those scenarios is a problem. > - Existing solution proposals: > o draft-wing-sip-identity-media-02 > o draft-fischer-sip-e2e-sec-media-00 > - Other solution proposals. [tongue-in-cheek] Have the originating UAC generate an INVITE without SDP (i.e., a delayed offer). Therefore there will be no SDP to sign and become invalidated. The SDP offer comes in the 2xx, which luckily is unsignable, and the ACK would presumably rarely be signed. Or make the authenticator a 3PCC box, so that the SDP removal happens without the UAC even knowing it. ;) -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
