[OpenSIPS-Devel] [ opensips-Patches-3496382 ] TM: No Retransmissions For 407/401

[SourceForge.net]

Patches item #3496382, was opened at 2012-03-02 11:59
Message generated for change (Settings changed) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3496382&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.7.x
Status: Open
Resolution: None
>Priority: 7
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: TM: No Retransmissions For 407/401

Initial Comment:
Currently if a transaction exists before proxy_challenge() from the auth module is used, then the 407 is sent statefully. At the moment this means that OpenSIPs will send retransmissions of the 407 if no ACK is received.

According to RFC 3261, retransmitting 407s/401s is probably a bad idea:

26.3.2.4 DoS Protection

<snip/>

   UAs and proxy servers SHOULD challenge questionable requests with
   only a single 401 (Unauthorized) or 407 (Proxy Authentication
   Required), forgoing the normal response retransmission algorithm, and
   thus behaving statelessly towards unauthenticated requests.

      Retransmitting the 401 (Unauthorized) or 407 (Proxy Authentication
      Required) status response amplifies the problem of an attacker
      using a falsified header field value (such as Via) to direct
      traffic to a third party.

   In summary, the mutual authentication of proxy servers through
   mechanisms such as TLS significantly reduces the potential for rogue
   intermediaries to introduce falsified requests or responses that can
   deny service.  This commensurately makes it harder for attackers to
   make innocent SIP nodes into agents of amplification.

The attached patch checks if the status code is 401 or 407 before starting the retransmissions timer. It's a simple patch against 1.7.1.

Thanks!
- David

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2012-03-06 09:26

Message:
That sounds correct. Thank you for clarifying.

- David

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-03-06 00:52

Message:
Hi David,

In an A->B->C chaining, retransmissions are done hop-by-hop, not end-2-end
; so there will be a different set of retransmissions between A and B and
another one between B and C.

Now, what I was saying is that B, acting as proxy, it will receive a 407
from C and forward the reply to A, In this case, if ACK lacks from A, B
still should not do retransmission of 407 to A.

Regards,
Bogdan

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: David Sanders (dmsanders)
Date: 2012-03-05 16:29

Message:
Hi Bogdan,

Accidentally posted this patch without being logged in at the time, hence
the 'nobody' submission.

I believe your reading of the RFC is correct, yes. In a case where A -> B
-> C, if C insisted on retransmitting 407s, and B was an OpenSIPs proxy,
then OpenSIPs would want to absorb the retransmissions and send nothing
back to A. Is this what you were getting at?

That being said, our use case only needed to worry about locally generated
replies, hence the small scope of the patch.

- David

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-03-05 10:27

Message:
Hi David,

I see your patch addresses only the case when the 407/401 is locally
generated, while allowing retransmissions for the received 407/401 - and as
I read the RFC, this behaviour affects also the UAs and the proxies .
Is my understanding correct ?

Thanks and regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3496382&group_id=232389