[reSIProcate] ACL, StaticRoute and federated SIP use case
Scott Godin
sgodin at sipspectrum.com
Thu Aug 2 16:35:01 CDT 2012
Static Routes are followed if the request is deemed to be destined to a
domain we are responsible for. Requests to be forwarded to other domains
are picked off by the Am I Responsible monkey. Since the request is to an
entity within our domain it is challenged as matter of policy (unless it's
from a machine/domain on the ACL list). This is fine for routing requests
from users of our domain, but not helpful for routing requests from unknown
users. The Static Routes really ought to specify in the web page
configuration if they are to be challenged or not - perhaps a setting that
allows the following: Challenge Always (same as today), Don't Challenge
MTLS peers, Never Challenge, etc... The commented out code was intended
to provide a place holder for this capability. Ideally this would be per
route, but a global setting would work as a band aid as well.
Scott
On Thu, Aug 2, 2012 at 2:29 PM, Daniel Pocock <daniel at pocock.com.au> wrote:
>
>
>
>
> I'm trying to pass a call between two repro instances, one serves
> pocock.com.au, the other sip5060.net
>
> The intention is that sip5060.net should accept calls from any arbitrary
> domain, provided the `From' URI domain matches the peer's cert
>
> However, the StaticRoute monkey doesn't allow this.
>
> Calls go through fine if I add `pocock.com.au' to the ACL. I can see
> that all TLS code is happy. It is just StaticRoute monkey that tries to
> challenge if there is no ACL entry:
>
> monkeys/StaticRoute.cxx:37 | Monkey handling request: StaticRoute;
> reqcontext = numtrans=1 final=0 req=SipReq: INVITE
> +41xxxxxx at sip5060.net tid=24615e5859b99974 cseq=1 INVITE
> contact=daniel at 192.168.1.105:49590 / 1 from(wire) tlsd=sip5060.net
>
> Helper.cxx:373 | Helper::makeResponse(SipReq: INVITE
> +41xxxxxx at sip5060.net tid=24615e5859b99974 cseq=1 INVITE
> contact=daniel at 192.168.1.105:49590 / 1 from(wire) tlsd=sip5060.net
> code=407 reason=
>
> RequestContext.cxx:921 | tid of orig req: 24615e5859b99974
> RequestContext.cxx:956 | Ensuring orig tid matches tid of response:
> 24615e5859b99974 == 24615e5859b99974
> RequestContext.cxx:963 | Sending final response.
> SipStack.cxx:554 | SEND: SipResp: 407 tid=24615e5859b99974 cseq=1 INVITE
> / 1 from(tu)
>
> ProcessorChain.cxx:93 | RequestProcessor aborted all chains: StaticRoute
>
>
>
> Can anyone elaborate on the intented duties of the StaticRoute monkey,
> whether or not this is what is expected?
>
> If I tweak StaticRoute to allow any SIP message with `From' header
> matching the peer cert, is that reasonable? Or should such behavior
> depend on config?
>
> Reading the comments in the code (copy below), it appears that an even
> less restrictive StaticRoute was envisaged, but then the code was
> commented out - so I'm a bit wary of changing this again if there is
> some history to this.
>
> The intended logic for checking the `From' address is already present in
> the new CertificateAuthenticator monkey
>
>
>
> https://svn.resiprocate.org/viewsvn/resiprocate/main/repro/monkeys/StaticRoute.cxx?revision=9647&view=markup
>
> Here is the relevant code from StaticRoute.cxx:
>
> bool requireAuth = false;
>
>
> if(!context.getKeyValueStore().getBoolValue(IsTrustedNode::mFromTrustedNodeKey)
> &&
> msg.method() != ACK && // Don't challenge ACK and BYE requests
> msg.method() != BYE)
> {
> requireAuth = !mNoChallenge;
> //for ( RouteStore::UriList::const_iterator i = targets.begin();
> // i != targets.end(); i++ )
> //{
> // !rwm! TODO would be useful to check if these targets require
> authentication
> // but for know we will just fail safe and assume that all
> routes require auth
> // if the sender is not trusted
> // requireAuth |= !mNoChallenge;
> //}
> }
>
> if (requireAuth && context.getDigestIdentity().empty())
> {
> // !rwm! TODO do we need anything more sophisticated to figure out
> the realm?
> Data realm = msg.header(h_RequestLine).uri().host();
>
> challengeRequest(context, realm);
> return Processor::SkipAllChains;
> }
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20120802/9bcd6bbb/attachment.htm>
More information about the resiprocate-devel
mailing list