< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] ACL, StaticRoute and federated SIP use case


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@xxxxxxxxxxxxx> 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@xxxxxxxxxxx tid=24615e5859b99974 cseq=1 INVITE
contact=daniel@192.168.1.105:49590 / 1 from(wire) tlsd=sip5060.net

Helper.cxx:373 | Helper::makeResponse(SipReq:  INVITE
+41xxxxxx@xxxxxxxxxxx tid=24615e5859b99974 cseq=1 INVITE
contact=daniel@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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel