13 jan 2011 kl. 01.46 skrev Iñaki Baz Castillo: > 2011/1/12 Olle E. Johansson <[email protected]>: >> Chapter 10 of RFC 3261 describes the way to process REGISTER requests. >> >> There's no description of any screening of the Contact header uri. >> >> It's now very common to compare it with an ACL to disallow URLs that is >> considered dangerous, like URLs pointing to internal servers in a service >> provider's network. > > IMHO the solution is very easy, but such solution would be never > documented in a RFC: > > - The registrar server could save the REGISTER Contact URI just in > case such REGISTER comes from a trusted address or client (i.e. after > authentication). > > - In case the REGISTER comes from an untrusted address/client then the > Contact URI could be ignored (an instead use the real source address > as location URI). Or the registrar could compare the source address of > the REGISTER with the Contact URI and reject the request if they don't > match. > > - In case there is an intermediary proxy between client and registrar > (i.e. an outbound proxy) such proxy could perform the above checks. Or > maybe the registrar could do it by taking the second Via address > (;received if present) from the REGISTER request. For the last case, > the registrar must know the network topology and this si something > that would be never documented in a RFC. > > > IMHO there is not a "magic" or "academic" solution for this security > issue. This is a common problem in any application level protocol > carrying information about IP/TCP/UDP layer.
YOu're talking about "reject the request" - how do we reject the request based on policy after a successful authentication? The RFC indicates to me that if the syntax is correct and we have authenticated that the request is authorized to bind to the AOR in the To: header (and follows the rules about SIPS) then we should save the contact regardless. Is there a way to say "Yes, you are authorized to this AOR but you are not allowed to use this Contact" ? ...in a way so that the client UAC understands what's going on and can log a proper error. /O _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
